«Чистый код» Роберт Мартин. Конспект. Как писать понятный и красивый код?

[Almet]

Конспект хороший, но книга интересней :)

[AGregory]

Спасибо. Я, естественно, не считаю, что мой конспект лучше книги Мартина ) Она же своего рода классика. Вдруг кто-то не читал ее, а прочитав конспект решит это сделать.

[Almet]

Для новичков обязательно нужен контекст, а в конспекте этого нет. А для тех кто в теме, это очевидные вещи.

[dss_kalika]

Не все догмы чистого кода стоит использовать.
Не все догмы чистого кода которые стоит использовать стоит использовать всегда.
Все догмы чистого кода которые всё-же используете стоит использовать с умом, оглядкой и в согласовании с командой.
Чистый код и похожие методики надо внедрять на уровне код-ревью и стандартов программирования в проекте/программе.

[AGregory]

В самом начале книги Мартин пишет о субъективности своего же подхода. Это его видение этих вопросов, которое он назвал «Школой Чистого кода».

[dss_kalika]

Ну это я так.
Напомнить просто, что к любым таким рекомендациям надо подходить с умом, а не слепо. =)
Да и в статье об этом не написано.

[aromatov]

Ну вот, например, можно использовать один switch, а можно сбацать фабрику с абстрактными методами и реализовать их в подклассах. И всё это только ради того, что switch в коде нам глаз мозолит и «нарушает принципы». Из одной функции мы получаем несколько классов. Я бы подумал над разумностью плодить ещё несколько классов в проекте, где их и так тысячи. Здесь 3 класса, там еще 10… и так для каждого switch. О скорости сборки, производительности и даже банальной навигации по исходникам тоже не стоит забывать (я сейчас не только про этот случай).

[Kunokput]

А как вы себе представляете внедрение этих методик на уровне код-ревью?
Большая часть принципов, описанных здесь, являются лишь симптомами проблем, связанных с неправильным выбором архитектурных решений.
Методы больше 20 строк, switch операторы, наличие или отсутствие контекста — все это следствие неправильно выбранных границ модулей или неправильный абстракций.
Так может на код-ревью лучше следует смотреть на правильность реализации бизнес логики и правильность выбора архитектурных решений, а не на эти принципы?
Если подходить к этим принципам, как к симптомам возможных проблем, то их можно использовать, но использовать их в код ревью как аргументы, я бы не стал.

Конечно можно на уровне команды вынести конвенции по именам классов, методов, переменных и т.п., польза от этого правда очень незначительна. Хотя, если это конечно поможет не называть переменные
a1, a2 и т.п., то уже хорошо.

Так же некоторые принципы можно отнести к странным решениям:

1. Вместо assertEquals использовать assertExpectedEqualsActual
2. Изолировать блоки try/catch
3. Использовать префиксы get/set

[sankarsana]

И где же найти это видео?

[sankarsana]

Ссылки здесь нельзя выкладывать?

[TotalAMD]

Чё такое "кодированные имена"???