Стиль если: к вложенному множеству или не к вложенному множеству
У моего коллеги и я была дискуссия о следующей проблеме лучшей практики.
Большинство функций/методов запускается с некоторой проверки параметра.
Я защищаю следующий стиль, который избегает вложения.
if (parameter one is ugly) return ERROR;
if (parameter two is nonsense || it is raining) return ERROR;
// do the useful stuff
return result;
Он, кто происходит из более функциональной среды / фона логического программирования, предпочитает следующее, потому что он сокращает количество точек выхода от функции.
if (parameter one is ok) {
if (parameter two is ok && the sun is shining) {
// do the useful stuff
return result
}
}
return ERROR;
Какой Вы предпочли бы и почему?
9 ответов
Я предпочитаю делать всю проверку входных параметров в начале функции и только там делать return. Поэтому в большинстве случаев я предпочитаю первый подход. Если есть только один уровень вложенности, то я могу выбрать второй вариант.
Я предпочитаю первый. 5298529357 уровней отступов просто действует мне на нервы.
Добавьте к этому тот факт, что когда вы сразу возвращаетесь, очевидно, что (параметр один - уродливый) - это ошибка.
Я лично предпочитаю первый стиль, так как считаю, что он обеспечивает некоторое логическое разделение между тем, что мы можем назвать «случаями ошибок» и «логикой метода». В начале метода есть четко определенный блок, который оценивает и обрабатывает любые ошибки во входных данных, а затем остальная часть метода посвящена тому, что метод должен делать на самом деле.
Думаю, это своего рода разделение проблем на микроуровне.
Наиболее читаемый стиль:
if (parameter one is ok)
{
if (parameter two is ok && the sun is shining)
{
// do the useful stuff
return result
}
else
{
// do other things
}
}
return ERROR;
По крайней мере, для меня :)
РЕДАКТИРОВАТЬ: Извините, неправильно понял вопрос. Голосую за первого, не люблю глубокого вложения.
Наш внутренний стиль - избегать множественных возвращаемых точек, а также ограничивать количество вложений, поэтому я, вероятно, объединю ваши проверки работоспособности предварительных условий и сделайте что-нибудь вроде:
result_t result = OKAY;
// Sanity checks
if ((parameter_one == ugly) || (parameter_two == nonsense) || (weather == raining))
{
result = ERROR;
}
else
{
// do the useful stuff
}
return result;
Если стиль согласован во всей кодовой базе, мне подойдет любой из этих двух стилей.
В случае двух проверок любая из них действительно подходит, как только вы добавите еще, вариант 1 быстро станет все более и более желательным!
Второй вариант, который я обычно предпочитаю, , если только все тело функции не будет заключено в число X операторов if . Если так, я бы выбрал первый вариант.
На мой взгляд, это зависит только от типа проверки ошибок, которая вам нужна.
Если, например, первый параметр - уродливый , но в следующем коде вам удастся изменить его состояние на довольно , предпочтительнее второй метод.
Однако, если ошибка фатальная и не может быть обработана, вы должны немедленно вернуться.
Здесь есть третий вариант, которому больше всего подходит второй стиль, и это когда вы хотите собрать все ошибки в одно связное сообщение об ошибке.
Второй стиль должен сначала проверять не валидность, а недействительность.
Что касается личных предпочтений, я был бы намного счастливее с первым стилем.