Цитата:
Что можно сказать о плохом коде?
[list][*]ничего не понятно[*]непонятные переменные[*]огромные методы[*]неочевидные алгоритмы[*]хаки, нарушения инкапсуляции[*]высокая сложность и запутанность[*]изменения приводят к сюрпризам[*]ничего не понятно
Я недаром дважды указал один и тот же момент. Действительно, практически все сводится к тому, что программист не может разобраться с неким кодом.
...
Все, что можно отделить и назвать — должно быть отделено и названо.
...
Альтернативное мнение
Не все согласны с тем, что это — хорошая методика. Есть такое правило: выносить в отдельные методы только тот код, который может использоваться где-то еще. Если выносить все методы, то тогда возрастает когнитивная нагрузка из-за того, что программист вынужден будет ездить по файлу вверх-вниз в поисках нужного метода, вместо того, чтобы видеть все перед глазами.
Я считаю, что здесь нужна мудрость. Ни практика принудительной экстракции всех алгоритмов, ни упаковка кода в один метод не дадут читаемый код сами по себе. Здесь нужно выработать вкус и тонкое чувство наития, подсказывающее, где стоит выделять код, а где нет.
Один из способов решить этот конфликт выглядит следующим образом. Выносим все методы, какие только можно. В течении пары дней изменения не откатываем, терпим. Через дня три станет мучительно понятно, какие методы таки нужно вернуть обратно.
подробнее
http://habrahabr.ru/post/150868/
стоит отметить, что в аксапте методично применялся такой подход. по крайней мере в базовых классах (например, InventMovement и потомки. например, ledgerjournalengine).
и я бы не сказал, что методичное применение такого подхода сильно облегчило жизнь при чтении кода.
может быть, я чего не понимаю?
что думаете?