Всем привет, у нас с товарищем по работе возник спор.
есть функция:

мой вариант:


вариант коллеги:


он говорит, что его вариант лучше, т.к. в коде меньше вложенностей (т.е. отступов), а я говорю, что мой вариант лучше т.к. легче читается и легок при отладке, ведь если поставить break point на строку с print() и условие выполняться не будет, то на брэкпоинт никогда не попадешь и потратишь еще 1-2 часа на понятие почему (из моего опыта).

У кого какие мыслы по этому поводу ?

 Голосую за первый ибо нужно стремиться к максимальной простоте кода.
ЗЫ А вообще спор напоминает спор о расстановке фигурных скобок. И так же закончиться ничем ИМХО

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

Исходя из этого вариант:

Неприемлем (эту строчку можно просто не заметить в куче кода), хотя следующий код вполне приветствуемая практика:

Этот способ называется "сторожевые условия".


Резюмирую: лучше тот код, который проще читать!

StepS, в общем виде они равноправны. В некоторых случаях лучше первый, в некоторых второй.
В принципе, первый я использую чаще, потому что:
- однозначно, по возможности лучше иметь минимум точек выхода (return);
- позитивные условия (без отрицания) мне нравятся больше 

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

Первый вариант логически более правильный (проверяется прямое условие, соблюдаются принципы структурного программирования - см. Макконелл Совершенный код)



Второй вариант более читабелен (отсутствует дополнительное смещение большого? куска кода - см. Кериевски Рефакторинг с применением шаблонов).

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

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

Это сообщение отредактировал(а) adLucem - 17.5.2007, 15:11

я согласен что в начале метода можно его использовать (но я считаю, лучше этого избегать), а вот в середине метода - только в крайних случаях и никак не по причине уменьшения отспутов.
Нужно уменьшить число вложенности - пожалуйта: выносите в отдельные методы и будет вам счастье (ИМХО)

StepS, Совершенно согласен - вынесение логики в отдельный метод (composite method) - наиболее подходящее решение.

Но опять же не применимое при контроле входных данных и инвариантов.

ок. я понял, всем спасибо за дискуссию