Вопрос по правильному кодописанию. Столкнулся с такой задачей. Имеется множество ветвящихся условий. То-есть многоуровневая система IF-ов вложенных друг в друга. Код, естественно, совершенно нечитаем.

Вопрос естественный - что же делать? Как код написать "красиво"? Кто как делает?

Сам я пока придумал только одно улучшение. Писать множество вложенных приватных методов с осмысленными названиями. В каждом - один IF с обращением в двух ветвях к двум следующим методам. Но  проблема в том, что, с одной стороны, не всегда такому вложенному методу можно дать осмысленное название, с другой, все время приходится пеедавать чертову уйму параметров. Да и вообще не бог весть какое хорошее решение.

1. сделай отступ 1 пробел
2. больше каментов
например, в конце большого блока, если он не умещается на странице, надо делать такой камент:

3. делай "параграфы", "главы" выделяй их разным количеством пустых строк


Это сообщение отредактировал(а) leniviy - 5.8.2012, 16:44

leniviy, спасибо, но это, вроде, само собой разумеется. 

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

Роберт Мартин, "Чистый код" , глава 3


Это всё признаки гoвнокода!


Это сообщение отредактировал(а) Cheloveck - 5.8.2012, 18:05

А в чем проблема? Если вложенность больше 2 (3) - делаем extract method - самое лучшее решение.

Это сообщение отредактировал(а) Stolzen - 5.8.2012, 20:11

Что такое extract method? Я не в курсе  

Рефакторинг. К.О.
Разбивай метод на более простые и читабельные. Т.е. вместо одного метода с 10 if-ами, пусть лучше будет 10 маленьких методов с одним if-ом каждый. Опять же можно попробовать заменить if на switch. В любом случае универсального решения нет, надо смотреть по ситуации.

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



Это сообщение отредактировал(а) jk1 - 6.8.2012, 09:43

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

ЕСЛИ этот ветвящийся код описывает поведение одного объекта в зависимости от условий, то можно прибегнуть к одному из шаблонов проектирования: Strategy
Если нет, то либо что-то другое либо рефакторингом обходиться.

на самом деле это хороший способ в простых случаях


значит надо пересмотреть разделение на методы. осмысленному действию легче дать осмысленное название 

Очень помогает инвертировать условие:

Вместо:




Код становится одноуровневым и читабельным.

If c else выносить в отдельный метод с возвращаемым значением:
Вместо:



(Я упростил, естественно, в данном случае проще заменить на тернарный оператор, но суть примерно понятна)
Писать комментарии категорически не советую, особенно ерунду типа /* END if (1==1) */. Ни IDE, ни коллеги эти комметы поддерживать не будут, и через пару коммитов это станет неправдой + это вообще лишняя работа совершенно.


Это сообщение отредактировал(а) NoliX - 10.8.2012, 13:46

Спасибо. Подведу итого того, что понял.

Моя идея выносить каждый вложенный IF в отдельный метод была оценена как достойная. Даже умному назвнию  "extract method" Stolzen с LSD научили.

Полиморфизм, предложенный jk1 и jManiak я очень уважаю, а, в случае конечных автоматов, даже люблю. За высокий уровень инкапсуляции. Но здесь он "не окупится". Большинство классов будут имплементировать одну строчку кода.


Это, конечно, не массив, но любые данные можно превратить в объект. А вот как делать через конекст я не знаю. Как это?

NoliX, IF-ы с return-ами я объединяю практически всегда, когда возможно. ИМХО такой код гораздо читабельнее. Но здесь этим не обойдешься.

...................

Собственно, наверное стОит объяснить задачу.

Имеем много полей ввода разных типов. Некоторые значения некоторых полей открывают дополнительные поля ввода. Довольно обычный высоконагруженный пользовательский интерфейс. А вот дальше начинаются сложности. Данные должны попасть в БД. Но, при этом, должны делаться проверки как введенных данных, так и уже имеющихся в базе. Т.е. данные и отношения между ними могут создавать новые записи, а могут и дополнять имеющиеся. При этом от самих данных зависит "чья возьмет". Т.е. данные в БД могут иметь больший или меньший приоритет по сравнению с тем, что ввел пользователь. Собственно, логика простая, но подразумевающая множество проверок, специфических для различных комбинаций данных..... Понятней, надо понимать не стало    

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

данные объекта это и есть контекст



наоборот, стало. это имхо не if-ами должно решаться.

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