Имеются ли какие-либо исследования по вопросу о возможности сопровождения парадигмы «оператор защиты» и «точка выхода из одной функции»? - PullRequest
10 голосов
/ 19 февраля 2010

Мне интересно, проводились ли какие-либо исследования (как случайные, так и надежные) в отношении работоспособности проектов, в которых используется парадигма «оператор защиты» и парадигма «точка выхода из одной функции»?

Пример оператора охраны (в C #):

string GetSomeString()
{
    if(necessaryConditionFails) { return null; }
    if(!FunctionWithBoolReturn(someAttribute)) { return null; }
    //all necessary conditions have been met
    //do regular processing...
    return finalStringValue;
}

Пример точки выхода отдельной функции (в C #):

string GetSomeString()
{
    string valueToReturn = null;
    if(necessaryConditionPasses && FunctionWithBoolReturn(someAttribute)) 
    { 
        //all necessary conditions have been met
        //do regular processing...
        valueToReturn = finalStringValue;
    }
    return valueToReturn;
}

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

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

1 Ответ

10 голосов
/ 19 февраля 2010

У форсированных точек выхода есть свои проблемы.

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

Во-вторых, если вы используете исключения, вы вынуждены перехватывать все, если вам снова нужна единая точка выхода.

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

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