Элегантные способы справиться, если (если еще) еще

Это небольшая проблема, но каждый раз, когда мне приходится кодировать что-то вроде этого, повторение беспокоит меня, но я не уверен, что какое-либо из решений не хуже.

if(FileExists(file))
{
    contents = OpenFile(file); // <-- prevents inclusion in if
    if(SomeTest(contents))
    {
        DoSomething(contents);
    }
    else
    {
        DefaultAction();
    }
}
else
{
    DefaultAction();
}

• Есть ли название для такой логики?
• Я тоже чересчур ОКР?

Я открыт для злых предложений по коду, хотя бы ради любопытства ...

Распакуйте его в отдельную функцию (метод) и используйте returnоператор:

if(FileExists(file))
{
    contents = OpenFile(file); // <-- prevents inclusion in if
    if(SomeTest(contents))
    {
        DoSomething(contents);
        return;
    }
}

DefaultAction();

Или, может быть, лучше разделить получение содержимого и его обработку:

contents_t get_contents(name_t file)
{
    if(!FileExists(file))
        return null;

    contents = OpenFile(file);
    if(!SomeTest(contents)) // like IsContentsValid
        return null;

    return contents;
}

...

contents = get_contents(file)
contents ? DoSomething(contents) : DefaultAction();

Upd:

Почему бы не исключения, почему OpenFileне выдает исключения IO:
я думаю, что это действительно общий вопрос, а не вопрос о файловом IO. Такие имена, как FileExists, OpenFileмогут вводить в заблуждение, но если заменить их на Fooи Barт. Д., То будет понятнее, что они DefaultActionмогут вызываться так же часто, как и DoSomethingисключительный случай. Петер Тёрёк написал об этом в конце своего ответа

Почему существует троичный условный оператор во втором варианте:
если бы был тег [C ++], я написал бы ifзаявление с объявлением of contentsв его условной части:

if(contents_t contents = get_contents(file))
    DoSomething(contents);
else
    DefaultAction();

Но для других (C-подобных) языков if(contents) ...; else ...;это точно так же, как выражение выражения с тернарным условным оператором, но длиннее. Поскольку основной частью кода была get_contentsфункция, я просто использовал более короткую версию (а также опущенный contentsтип). Во всяком случае, это за пределами этого вопроса.

Если язык программирования, который вы используете (0), выполняет короткое замыкание двоичных сравнений (т.е. если не вызывает, SomeTestесли FileExistsвозвращает false) и (1) присваивание возвращает значение (результат OpenFileприсваивается, contentsа затем это значение передается в качестве аргумента to SomeTest), вы можете использовать что-то вроде следующего, но вам все равно советуют комментировать код, отмечая, что сингл =является преднамеренным.

if( FileExists(file) && SomeTest(contents = OpenFile(file)) )
{
    DoSomething(contents);
}
else
{
    DefaultAction();
}

В зависимости от того, насколько сложным является if, может быть лучше иметь переменную flag (которая разделяет тестирование условий успеха / неудачи с кодом, который обрабатывает ошибку DefaultActionв этом случае)

Более серьезным, чем повторение вызова DefaultAction, является сам стиль, потому что код написан не ортогонально (см. Этот ответ для веских причин написания ортогонально).

Чтобы показать, почему неортогональный код плох, рассмотрим оригинальный пример, когда вводится новое требование, чтобы мы не открывали файл, если он хранится на сетевом диске. Ну, тогда мы могли бы просто обновить код следующим образом:

if(FileExists(file))
{
    if(! OnNetworkDisk(file))
    {
        contents = OpenFile(file); // <-- prevents inclusion in if
        if(SomeTest(contents))
        {
            DoSomething(contents);
        }
        else
        {
            DefaultAction();
        }
    }
    else
    {
        DefaultAction();
    }
}
else
{
    DefaultAction();
}

Но также возникает требование, чтобы мы не открывали большие файлы более 2 ГБ. Ну, мы просто обновим снова:

if(FileExists(file))
{
    if(LessThan2Gb(file))
    {
        if(! OnNetworkDisk(file))
        {
            contents = OpenFile(file); // <-- prevents inclusion in if
            if(SomeTest(contents))
            {
                DoSomething(contents);
            }
            else
            {
                DefaultAction();
            }
        }
        else
        {
            DefaultAction();
        }
    else
    {
        DefaultAction();
    }
}
else
{
    DefaultAction();
}

Должно быть очень ясно, что такой стиль кода будет огромной проблемой обслуживания.

Среди ответов, которые написаны правильно ортогонально, есть второй пример Abyx и ответ Яна Худека , поэтому я не буду повторять это, просто укажу, что добавление двух требований в эти ответы будет просто

if(! LessThan2Gb(file))
    return null;

if(OnNetworkDisk(file))
    return null;

(или goto notexists;вместо return null;), не влияя ни на какой другой код, кроме этих добавленных строк . Например, ортогональный.

При тестировании общим правилом должно быть тестирование исключений, а не нормальный случай .

Очевидно:

Whatever(Arguments)
{
    if(!FileExists(file))
        goto notexists;
    contents = OpenFile(file); // <-- prevents inclusion in if
    if(!SomeTest(contents))
        goto notexists;
    DoSomething(contents);
    return;
notexists:
    DefaultAction();
}

Вы сказали, что вы открыты даже для злых решений, так что, используя злые счета Гото, нет?

Фактически, в зависимости от контекста, это решение может быть менее злым, чем зло, совершающее действие дважды, или злые дополнительные переменные. Я обернул его в функцию, потому что он точно не будет в середине длинной функции (не в последнюю очередь из-за возврата в середине). Но чем долго функция не в порядке, точка.

Когда у вас есть исключения, их будет легче читать, особенно если вы можете использовать OpenFile и DoSomething, просто генерирующие исключение, если условия не выполняются, поэтому вам вообще не нужны явные проверки. С другой стороны, в C ++, Java и C # создание исключения является медленной операцией, поэтому с точки зрения производительности goto все еще предпочтительнее.

Обратите внимание на «зло»: C ++ FAQ 6.15 определяет «зло» как:

Это означает , что такой- то , что вы должны избегать большинство времени, но не то , что вы должны избегать все время. Например, вы в конечном итоге будете использовать эти «злые» вещи, когда они являются «наименьшим злом из злых альтернатив».

И это относится к gotoэтому контексту. Структурированные структуры управления потоком лучше в большинстве случаев, но когда вы попадаете в ситуацию, когда они накапливают слишком много своих зол, например, присваивание по условию, вложение более чем на 3 уровня, дублирование кода или длительные условия, gotoможет просто закончиться быть менее злым.

function FileContentsExists(file) {
    return FileExists(file) ? OpenFile(file) : null;
}

...

contents = FileContentExists(file);
if(contents && SomeTest(contents))
{
    DoSomething(contents);
}
else
{
    DefaultAction();
}

Одна возможность:

boolean handled = false;

if(FileExists(file))
{
    contents = OpenFile(file); // <-- prevents inclusion in if
    if(SomeTest(contents))
    {
        DoSomething(contents);
        handled = true;
    }
}
if (!handled)
{
    DefaultAction();
}

Конечно, это делает код немного более сложным по-другому. Так что это во многом вопрос стиля.

Другой подход будет использовать исключения, например:

try
{
    contents = OpenFile(file); // throws IO exception if file not found
    DoSomething(contents); // calls SomeTest() and throws exception on failure
}
catch(Exception e)
{
    DefaultAction();
    // and the exception should be at least logged...
}

Это выглядит проще, однако это применимо только если

• мы точно знаем, каких исключений ожидать, и DefaultAction()подходит каждому
• мы ожидаем, что обработка файла будет успешной, а отсутствующий файл или сбой SomeTest()явно являются ошибочным условием, поэтому целесообразно создать для него исключение.

Это на более высоком уровне абстракции:

if (WeCanDoSomething(file))
{
   DoSomething(contents);
}
else
{
   DefaultAction();
} 

И это заполняет детали.

boolean WeCanDoSomething(file)
{
    if FileExists(file)
    {
        contents = OpenFile(file);
        return (SomeTest(contents));
    }
    else
    {
        return FALSE;
    }
}

Функции должны делать одно. Они должны делать это хорошо. Они должны это делать только.
Роберт Мартин в « Чистом коде»

Некоторые люди находят такой подход немного экстремальным, но он также очень чистый. Позвольте мне проиллюстрировать на Python:

def processFile(self):
    if self.fileMeetsTest():
        self.doSomething()
    else:
        self.defaultAction()

def fileMeetsTest(self):
    return os.path.exists(self.path) and self.contentsTest()

def contentsTest(self):
    with open(self.path) as file:
        line = file.readline()
        return self.firstLineTest(line)

Когда он говорит, что функции должны делать одно, он имеет в виду одно . processFile()выбирает действие, основанное на результате теста, и это все, что он делает. fileMeetsTest()сочетает в себе все условия теста, и это все, что он делает. contentsTest()передает первую строку firstLineTest(), и это все, что он делает.

Вроде бы много функций, но читается практически как прямой английский:

Чтобы обработать файл, проверьте, соответствует ли он тесту. Если это так, то сделайте что-нибудь. В противном случае выполните действие по умолчанию. Файл соответствует тесту, если он существует, и проходит проверку содержимого. Чтобы проверить содержимое, откройте файл и проверьте первую строку. Тест для первой строки ...

Конечно, это немного словесно, но учтите, что если сопровождающий не заботится о деталях, он может прекратить чтение только после четырех строк кода processFile(), и он все равно будет хорошо знать, что делает функция.

Что касается того, что это называется, он может легко превратиться в антишаблон со стрелками по мере того, как ваш код расширяется для удовлетворения дополнительных требований (как показано в ответе на https://softwareengineering.stackexchange.com/a/122625/33922 ) и затем попадает в ловушку огромных участков кода с вложенными условными выражениями, которые напоминают стрелку.

Смотрите ссылки, такие как;

http://codinghorror.com/blog/2006/01/flattening-arrow-code.html

http://lostechies.com/chrismissal/2009/05/27/anti-patterns-and-worst-practices-the-arrowhead-anti-pattern/

Об этом и других анти-паттернах можно найти еще много в Google.

Вот несколько замечательных советов, которые Джефф дает в своем блоге по этому поводу;

1) Заменить условия пунктами охраны.

2) Разложить условные блоки на отдельные функции.

3) Конвертировать отрицательные чеки в положительные чеки

4) Всегда как можно быстрее возвращайтесь из функции.

Посмотрите некоторые комментарии в блоге Джеффа относительно предложений Стива Макконнелса о досрочном возвращении;

«Используйте возврат, когда он улучшает читабельность: в некоторых подпрограммах, когда вы знаете ответ, вы хотите немедленно вернуть его в вызывающую подпрограмму. Если подпрограмма определена таким образом, что она не требует дополнительной очистки после ее обнаруживает ошибку, а не возврат немедленно означает, что вам нужно написать больше кода. "

...

«Минимизируйте количество возвратов в каждой подпрограмме. Труднее понять подпрограмму, когда, читая ее в нижней части, вы не знаете о вероятности ее возврата в другое место. По этой причине используйте возвраты разумно - только тогда, когда они улучшаются удобочитаемость

Я всегда подписывался на 1 вход / выход на теорию функций из-за того, что меня учили 15 лет назад или около того. Я чувствую, что это делает код намного проще для чтения и, как вы упоминаете, более понятным

Это соответствует правилам СУХОЙ, no-goto и no-множественный возврат, является масштабируемым и читаемым на мой взгляд:

success = FileExists(file);
if (success)
{
    contents = OpenFile(file);
    success = SomeTest(contents);
}
if (success)
{
    DoSomething(contents);
}
else
{
    DefaultAction();
}

Я бы извлек его в отдельный метод, а затем:

if(!FileExists(file))
{
    DefaultAction();
    return;
}

contents = OpenFile(file);
if(!SomeTest(contents))
{
    DefaultAction();
    return;
}

DoSomething(contents);

что также позволяет

if(!FileExists(file))
{
    DefaultAction();
    return Result.FileNotFound;
}

contents = OpenFile(file);
if(!SomeTest(contents))
{
    DefaultAction();
    return Result.TestFailed;
}

DoSomething(contents);
return Result.Success;            

тогда, возможно, вы могли бы удалить DefaultActionвызовы и оставить выполнение DefaultActionдля вызывающего:

Result OurMethod(file)
{
    if(!FileExists(file))
    {
        return Result.FileNotFound;
    }

    contents = OpenFile(file);
    if(!SomeTest(contents))
    {
        return Result.TestFailed;
    }

    DoSomething(contents);
    return Result.Success;            
}

void Caller()
{
    // something, something...

    var result = OurMethod(file);
    // if (result == Result.FileNotFound || result == Result.TestFailed), or just
    if (result != Result.Success)        
    {
        DefaultAction();
    }
}

Мне также нравится подход Жанны Пиндар .

Для этого конкретного случая ответ достаточно прост ...

Существует состояние гонки между FileExistsи OpenFile: что произойдет , если файл будет удален?

Единственный разумный способ справиться с этим конкретным случаем - пропустить FileExists:

contents = OpenFile(file);
if (!contents) // open failed
    DefaultAction();
else (SomeTest(contents))
    DoSomething(contents);

Это аккуратно решает эту проблему и делает код чище.

В общем: попробуйте переосмыслить проблему и найти другое решение, которое полностью исключает проблему.

Другая возможность, если вам не нравится видеть слишком много других, - это вообще отказаться от использования else и добавить дополнительный оператор return. Остальное является излишним, если вам не требуется более сложная логика, чтобы определить, существует ли более двух возможных действий.

Таким образом, ваш пример может стать:

void DoABunchOfStuff()
{
    if(FileExists(file))
    {
        DoSomethingWithFileContent(file);
        return;
    }

    DefaultAction();
}

void DoSomethingWithFileContent(file)
{        
    var contents = GetFileContents(file)

    if(SomeTest(contents))
    {
        DoSomething(contents);
        return;
    }

    DefaultAction();
}

AReturnType GetFileContents(file)
{
    return OpenFile(file);
}

Лично я не возражаю против использования предложения else , так как оно явно указывает, как должна работать логика, и, таким образом, улучшает читабельность вашего кода. Однако некоторые инструменты для улучшения кода предпочитают упрощать до одного оператора if, чтобы не допустить вложения логики.

Случай, показанный в примере кода, обычно сводится к одному ifвыражению. Во многих системах функция открытия файла возвращает недопустимое значение, если файл еще не существует. Иногда это поведение по умолчанию; в других случаях он должен быть указан через аргумент. Это означает, что FileExistsтест можно отменить, что также может помочь в условиях гонки, возникающих в результате удаления файла между тестом на существование и открытием файла.

file = OpenFile(path);
if(isValidFileHandle(file) && SomeTest(file)) {
    DoSomething(file);
} else {
    DefaultAction();
}

Это напрямую не решает проблему смешивания на уровне абстракции, поскольку полностью обходит проблему множественных, несвязанных тестов, хотя отказ от теста на существование файла не является несовместимым с разделением уровней абстракции. Предполагая, что недействительные файловые дескрипторы эквивалентны «false», и файловые дескрипторы закрываются, когда они выходят из области видимости:

OpenFileIfSomething(path:String) : FileHandle {
    file = OpenFile(path);
    if (file && SomeTest(file)) {
        return file;
    }
    return null;
}

...

if ((file = OpenFileIfSomething(path))) {
    DoSomething(file);
} else {
    DefaultAction();
}

Я согласен с frozenkoi, однако, для C # в любом случае, я думал, что это поможет следовать синтаксису методов TryParse.

if(FileExists(file) && TryOpenFile(file, out contents))
    DoSomething(contents);
else
    DefaultAction();

bool TryOpenFile(object file, out object contents)
{
    try{
        contents = OpenFile(file);
    }
    catch{
        //something bad happened, computer probably exploded
        return false;
    }
    return true;
}

Ваш код ужасен, потому что вы делаете слишком много в одной функции. Вы хотите обработать файл или выполнить действие по умолчанию, поэтому начните с того, что:

if (!ProcessFile(file)) { 
  DefaultAction(); 
}

Программисты на Perl и Ruby пишут processFile(file) || defaultAction()

Теперь иди напиши ProcessFile:

if (FileExists(file)) { 
  contents = OpenFile(file);
  if (SomeTest(contents)) {
    processContents(contents);
    return true;
  }
}
return false;

Конечно, вы можете пойти так далеко только в таких сценариях, но вот путь:

interface File<T> {
    function isOK():Bool;
    function getData():T;
}

var appleFile:File<Apple> = appleStorage.get(fileURI);
if (appleFile.isOK())
    eat(file.getData());
else
    cry();

Вы можете хотеть дополнительные фильтры. Затем сделайте это:

var appleFile = appleStorage.get(fileURI, isEdible);
//isEdible is of type Apple->Bool and will be used internally to answer to the isOK call
if (appleFile.isOK())
    eat(file.getData());
else
    cry();

Хотя это также может иметь смысл:

function eat(apple:Apple) {
     if (isEdible(apple)) 
         digest(apple);
     else
         die();
}
var appleFile = appleStorage.get(fileURI);
if (appleFile.isOK())
    eat(appleFile.getData());
else
    cry();

Который лучший? Это зависит от реальной проблемы, с которой вы сталкиваетесь.
Но вот что нужно отнять: вы можете многое сделать с композицией и полиморфизмом.

Что не так с очевидным

if(!FileExists(file)) {
    DefaultAction();
    return;
}
contents = OpenFile(file);
if(!SomeTest(contents))
{
    DefaultAction();
    return;
}        
DoSomething(contents);

Это кажется довольно стандартным для меня? Для такой большой процедуры, где должно случиться много мелочей, отказ любого из которых помешает последнему. Исключения делают его немного чище, если это вариант.

Я понимаю, что это старый вопрос, но я заметил образец, который не был упомянут; в основном, установка переменной для последующего определения метода (ов), который вы хотели бы вызвать (за исключением if ... else ...).

Это просто еще один угол зрения, чтобы облегчить работу с кодом. Это также позволяет вам, когда вы захотите добавить другой метод для вызова или изменить соответствующий метод, который необходимо вызывать в определенных ситуациях.

Вместо того, чтобы заменить все упоминания о методе (и, возможно, пропустить некоторые сценарии), все они перечислены в конце блока if ... else ... и их легче читать и изменять. Я склонен использовать это, когда, например, несколько методов могут быть вызваны, но внутри вложенного if ... else ... метод может быть вызван в нескольких совпадениях.

Если вы установите переменную, которая определяет состояние, вы можете иметь много глубоко вложенных параметров и обновлять состояние, когда что-то должно быть (или не должно быть) выполнено.

Это можно использовать, как в примере, заданном в вопросе, где мы проверяем, произошло ли «DoSomething», и, если нет, выполните действие по умолчанию. Или у вас может быть состояние для каждого метода, который вы хотите вызвать, установить, когда это применимо, а затем вызвать соответствующий метод за пределами if ... else ...

В конце вложенных операторов if ... else ... вы проверяете состояние и действуете соответствующим образом. Это означает, что вам нужно только одно упоминание метода вместо всех мест, где он должен применяться.

bool ActionDone = false;

if (Method_1(object_A)) // Test 1
{
    result_A = Method_2(object_A); // Result 1

    if (Method_3(result_A)) // Test 2
    {
        Method_4(result_A); // Action 1
        ActionDone = true;
    }
}

if (!ActionDone)
{
    Method_5(); // Default Action
}

Чтобы уменьшить вложенный IF:

1 / досрочное возвращение;

2 / сложное выражение (с учетом короткого замыкания)

Итак, ваш пример может быть изменен следующим образом:

if( FileExists(file) && SomeTest(contents = OpenFile(file)) )
{
    DoSomething(contents);
    return;
}
DefaultAction();

Я видел много примеров с «return», которые я тоже использую, но иногда я хочу избежать создания новых функций и использовать вместо этого цикл:

while (1) {
    if (FileExists(file)) {
        contents = OpenFile(file);
        if (SomeTest(contents)) {
           DoSomething(contents);
           break;
        } 
    }
    DefaultAction();
    break;
}

Если вы хотите писать меньше строк или ненавидите бесконечные циклы, как я, вы можете изменить тип цикла на «do ... while (0)» и избежать последнего «разрыва».

Как насчет этого решения:

content = NULL; //I presume OpenFile returns a pointer 
if(FileExists(file))
    contents = OpenFile(file);
if(content != NULL && SomeTest(contents))
    DoSomething(contents);
else
    DefaultAction();

Я сделал предположение, что OpenFile возвращает указатель, но это также может работать с возвращаемым типом значения, указав не возвращаемое значение по умолчанию (коды ошибок или что-то в этом роде).

Конечно, я не ожидаю каких-либо возможных действий с помощью метода SomeTest для указателя NULL (но вы никогда не узнаете), поэтому это также можно рассматривать как дополнительную проверку для указателя NULL для вызова SomeTest (содержимое).

Понятно, что наиболее элегантным и лаконичным решением является использование макроса препроцессора.

#define DOUBLE_ELSE(CODE) else { CODE } } else { CODE }

Который позволяет вам написать красивый код следующим образом:

if(FileExists(file))
{
    contents = OpenFile(file);
    if(SomeTest(contents))
    {
        DoSomething(contents);
    }
    DOUBLE_ELSE(DefaultAction();)

Может быть трудно полагаться на автоматическое форматирование, если вы часто используете эту технику, и некоторые IDE могут кричать вам немного о том, что, по ошибкам, ошибочно. И, как говорится, все является компромиссом, но я полагаю, что это неплохая цена, чтобы избежать зла повторяющегося кода.

Поскольку вы спросили из любопытства, и ваш вопрос не помечен конкретным языком (даже если ясно, что вы имели в виду императивные языки), возможно, стоит добавить, что языки, поддерживающие отложенную оценку, допускают совершенно иной подход. В этих языках выражения оцениваются только при необходимости, поэтому вы можете определять «переменные» и использовать их только тогда, когда это имеет смысл. Например, в вымышленном языке с ленивыми let/ inструктурами вы забыли о контроле потока и записи:

let
  contents = ReadFile(file)
in
  if FileExists(file) && SomeTest(contents) 
    DoSomething(contents)
  else 
    DefaultAction()