Комментарии 29
Мартина надо с осторожностью читать - многие его советы откровенная ерунда. Надо даже статьи пишет - It's probably time to stop recommending Clean Code и обсуждение на hacker news https://news.ycombinator.com/item?id=27276706
Регулярные потуги "отменить" Мартина за совет "функции должны быть короче" это прям отдельный жанр. Люди не замечают, что там в книге еще 400 страниц и куча реально полезных советов.
А как тогда поступать новичку, когда даже при трудоустройстве на работу в крупные компании рекомендуют читать книги Мартина? В статье я привёл пример только те компании, которые точно его используют (Точка, СКБ Контур). Разве рекомендация книги этими компаниями не является показателем того, что эту книгу можно считать как стандарт?
Стандарт для пары провинциальных компаний может не быть стандартом при устройстве в зарубежную компанию на удаленке, например.
Прочитать, как следует обдумать, а потом постараться понять, в каких случаях его советы применимы, а в каких нет. В принципе, первые шаги в этом направлении Вы уже сделали своей статьёй, поздравляю!
Это не стандарт.
Там даже где-то в предисловии сказано, что автор будет представлять многие суждения как абсолютные истины, но он просто так учит своему "искусству", а на самом деле единой правды нет, многие рекомендации будут спорными, и читатель может с чем-то не согласиться.
Но это полезная книга как пища для размышления.
Эти советы надо знать, я согласен. Но они порой очень детски наивные. На то он и совет, чтобы в общем прислушиваться, а в исключительных случаях игнорировать (вовсе не потому, что так захотелось -- на то должны быть веские основания)
Важно не забывать, что в разных языках разная специфика. Питонячий префикс "_" -- это только верхушка айсберга. В том же JS есть свои приколы, которые заставляют решать задачу сильно иначе
Вывод: думать надо своей головой
Очепятки в имени создателя Python, прошу прощения за оффтоп )
CamelCase по pep8 не используется ни для переменных, ни для функций. Только для классов. Есть оговорка про mixedCase для поддержки кода, который уже так написан, но это совсем не рекомендация к использованию.
Подчёркивание допустимо не только в качестве префикса, для обозначения приватности, но и как постфикс, в случае, если используется зарезервированное слово (да, лучше выбрать другое наименование, но если сильно нужно, то class_ лучше чем clss).
Константы – в верхнем регистре с подчёркиваниями. Об этом случае тоже стоит упомянуть.
Surround top-level function and class definitions with two blank lines. Method definitions inside a class are surrounded by a single blank line.
// Откуда же "4 пустых строки" в посте?
Длина строки это вообще отдельный холивар. Но стоит сделать скидку на время. Всё-таки в 2001 80 символов – необходимость.
Docstring это не совсем комментарий. Для блока комментариев pep8 говорит о "# " на каждой строке.
When catching exceptions, mention specific exceptions whenever possible instead of using a bare except: clause
"Конфликт имён класса и подкласса", это совсем не про чистый код. Тут одними префиксами не обойтись. Тем более, что ведущие подчёркивания используются не для разрешения конфликта имён.
Библиотеки Python явно нарушают рекомендацию clean code о не более чем трёх аргументах функции. Бывают функции с кучей именованных аргументов.
Наверное, ключевое слово здесь — именованные (ключ=значение).
Потому что из-за особенностей Python все именованные аргументы можно воспринимать как "объект с настройками", на которые Дядя Боб предлагает заменять лишние аргументы.
А больше трех неименованных не принято делать и в Python, если только это не какие-то самоочевидные для этой функции аргументы — (x1, x2, y1, y2), (r, g, b, a) и т.п.
Библиотеки пишутся не в ООП стиле, поэтому для библиотек многие правила неприменимы, об этом же в книге и говорит автор.
Да, PEP8 — самый популярный Code Style для Python. Но чтобы что-то называть «стандартом» одной популярности недостаточно.
И «Чистый код», который в статье тоже назван «стандартом», стандартом никак не является. Это всего лишь личный взгляд Мартина на то, как должен выглядеть идеальный код. Да, взгляд популярный. Но то, что какие-то компании используют подход Мартина — это лишь внутрикорпоративный Code Style, но никак не «стандарт».
N.B. Читать статьи Мартина ещё можно — там он хотя бы в объёме текста ограничен. Но книги — это кошмар: по десять раз повторяет одно и тоже, как дауну. Если вылить воду, толщина его книг уменьшится в несколько раз.
Сравнивать PEP8 (стандарт по code-style) и «чистый код» (рекомендации по организации кода), как сравнивать тёплое с мягким
Автор пишет код на языке Java. К слову сказать, я не нашёл в интернете какие-либо стандарты (вроде PEP8 в Python), которые могли бы подойти для написания качественного кода на той же Java.
Ну так PEP8 — это просто "style guide". Если хочется в таком духе, то можно и для Java найти (например, от Гугла).
А книга "Clean Code" про другое, ее можно почти к любому языку применить.
Имя Переменной - существительное, функции - глагол. Если переходить к конкретике, возьмём питон:
1) переменная называется is_red и содержит True или False
2) функция называется is_red и возвращает True или False
Что из них названо “неправильно”?
С точки зрения CleanCode "неправильным" будет первый вариант. Чтобы первую переменную верно интерпретировать согласно рекомендациям Мартина следует убрать префикс "is_".
Например, colorRed = True
В вашем случае, переменную называю isRed, а функцию – CheckForRed или CheckRed. Вопреки рекомендациям, называю функции не именем существительным, а глаголом.
Переменная должна быть color и содержать что-то типа enum, а функция isRed. Если по книжке, конечно же. А так это же рекомендации, а не четкие призывы к действию
Всё по стандарту, сначало сломя голову кинуться программировать, а потом переучиваться это делать правильно. Нахер себя приучать это делать с самого начала?
Публикации
Сравнение стандарта PEP8 и «Чистого кода» Роберта Мартина