Главный принцип хорошего кода

[mazzy]

Цитата:

Что можно сказать о плохом коде?
[list][*]ничего не понятно[*]непонятные переменные[*]огромные методы[*]неочевидные алгоритмы[*]хаки, нарушения инкапсуляции[*]высокая сложность и запутанность[*]изменения приводят к сюрпризам[*]ничего не понятно

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

...

Все, что можно отделить и назвать — должно быть отделено и названо.

...

Альтернативное мнение

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

Я считаю, что здесь нужна мудрость. Ни практика принудительной экстракции всех алгоритмов, ни упаковка кода в один метод не дадут читаемый код сами по себе. Здесь нужно выработать вкус и тонкое чувство наития, подсказывающее, где стоит выделять код, а где нет.

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

подробнее http://habrahabr.ru/post/150868/

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

может быть, я чего не понимаю?
что думаете?

[gl00mie]

Цитата:

Все, что можно отделить и назвать — должно быть отделено и названо.
Я считаю, что здесь нужна мудрость. Ни практика принудительной экстракции всех алгоритмов, ни упаковка кода в один метод не дадут читаемый код сами по себе. Здесь нужно выработать вкус и тонкое чувство наития, подсказывающее, где стоит выделять код, а где нет.
Таким рефакторингом можно заниматься...

Я бы сказал, статье недостает элемента новизны Вместо того, чтобы сперва бросаться в крайности, а потом призывать к мудрости и выработке вкуса "по бразильской системе", можно было бы для начала почитать того же Макконнела - у него в "Совершенном коде" созданию высококачественных методов посвящена целая глава почти на 30 страниц. Затем можно почитать "Рефакторинг..." Фаулера, где тонкому чувству наития противопоставляется расписанная до мелочей "поваренная книга" методов рефакторинга с четким указанием, какой, где, когда и как применять. "Все уже придумано до нас".

Цитата:

Сообщение от mazzy

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

Дык, помимо методичности нужна же мудрость! По-моему, InventMovement "слишком много на себя взял": это и механизм параметризации (методы-флажки canBeXX, mustBeXX), и поставщик разнообразных настроек разноски (accountXX, postingXX), и поставщик параметров проводки (transXX), и разного рода бизнес-логика (checkXX, updateXX). Класс должен выполнять четко очерченную роль, а не пытаться делать все и сразу. А LedgerJournalEngine мало того, что пытался заниматься всем подряд (как минимум, смешивал презентационную и бизнес-логику и в 3.0 зачастую не мог работать без ссылки на DS; в 2009-й хоть полегче стало), так еще и является "оберткой" для таблицы строк журналов с кучей полей и потому заведомо обречен на то, что численность его методов будет пропорциональна числу полей в LedgerJournalTrans. Тут уж не до облегчения жизни...

[ax_mct]

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

Когда просят писать точные спецификации с дизайном для индусов, я трачу больше времени чем бы запрограммировал сам.

[ax_mct]

Анекдот для знающих. Одно слово. "SettleNow". Не смешно но хочется сразу удавиться. И в индусском стиле кодирования такое случается черер раз. Все в один метод. Желательно на контроле. Мир плоский. На черепахе.

Поэтому я часто просто счастлив если виду хоть какое то ООП, бог с ним с идеальным выделением методов. Хотя очень часто приходиться вырезать чужой код в отдельный метод чтобы вызывать то же а не копировать. То есть то что может запускаться отдельно должно отделяться.