Книга чистый код: О книге Боба Мартина «Чистый код» / Хабр

Манифест Чистого Программиста или краткий конспект книги «Чистый Код» Роберта Мартина

Данная статья является конспектом книги «Чистый Код» Роберта Мартина и моим пониманием того, каким Чистый Код должен быть. Тут нет разделов о тестировании, TDD, о том какая должна быть архитектура и т.д. Здесь все только о том, каким должен быть Чистый Код.

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

Общее

Нет истинного пути и решения. Есть тот, который лучше всего подходит для решения конкретной задачи.

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

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

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

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

• Какие кейсы могут быть у задачи?
• Все ли я учел?
• Что может пойти не так?
• Что можно объединить?
• Есть ли похожий функционал?
• Что тут лишнее?
• Как сделать проще?
• Как сделать читабельнее?
• Как сделать понятнее?

Чистый Код

Как писать чистый и хороший код? Это похоже на написание книги. Сначала ты делаешь черновик и потом причесываешь его до того состояния, в котором тебе было бы приятно его читать. Всегда помни, что твой код должен рассказывать историю происходящего, чтобы читатель мог ее понять.

Под сущностью понимается — интерфейс, класс, метод, переменная, объект и т.д.

• Чистый код простой, выразительный и направлен на конкретную задачу.
• Чистый код читается легко, как проза. Если это не так, то его стоит рефакторить.
• Чистый код легко изменять. Он не должен быть жестко завязан на куче сущностей. Любую сущность можно легко изменить.
• Чистый код намного лучше проходит ревью. Если ревью проходит с огромным количеством комментариев, то он не чистый и его надо рефакторить.
• Чистый код всегда выглядит так, словно над ним очень долго трудились. Какие бы пути для его улучшения ты не искал, ты все равно придешь к тому, что этот код лучший. Соответственно, чистый код — продуманный до всех мелочей.
• Правило бойскаута: Оставь место стоянки чище, чем оно было до тебя. Это легко перекладывается и на программирование. Видишь грязный код? Сделай его чище, пока решаешь свою задачу. Не стоит увлекаться этим и если грязный код очень грязный, то стоит выделить отдельную задачу и время для его очистки.
• Не бойся делать изменений. Если ты хочешь их сделать, то значит у тебя есть на то причины, а значит ты сделаешь код лучше и чище. Тем более тесты покажут нет ли ошибок в твоем коде (при условии, что они вообще есть).
• Любая сущность должна отвечать за один функционал и только за него. И она должна выполнять его хорошо. Single Responsibility.
• Если сущность отвечает сразу за два и более действий, то её функционал нужно разделять.
• Код должен читаться сверху вниз.
• В хорошей и грамотной архитектуре внесение изменений обходится без значительных затрат и усилий.
• Удаляй мертвый код. Мертвый код это код, который не будет вызван ни при каких условиях или код, который нигде не используется.

Наименования и разделения

• Используй понятные и удобнопроизносимые имена для любых сущностей. Они должны описывать почему эта сущность существует, что она делает и как используется.
• Не бойся тратить время на выбор лучшего и понятного имени. Ты выиграешь в будущем при работе или чтении этого кода.
• Если название сущности не соответствует еë функционалу или по названию не понятно, что сущность делает, то еë надо переименовать в самое понятное название. Если этого сделать невозможно, то значит с еë функционалом что-то не так и еë надо рефакторить.
• Сущность, которая имеет в названии «And», «With» — нарушает Single Responsibility. Функционал такой сущности стоит разделять. Но этим правилом стоит иногда пренебрегать.
• Непонятные тексты, строки стоит выносить в переменные и давать им понятные названия.
• Названия методов должны содержать глагол, который описывает, что этот метод делает и ключевое слово с которым работает данный метод. Если в названии метода нет глагола, то эта сущность не должна быть методом или ему нужно дать правильное название.
• Нужно избегать одинаковых наименований для двух разных целей.
• Если сущность имеет схожее с другой сущностью название, то скорее всего их функционал очень сильно похож и их нужно объединить? Если нет, то их названия нужно менять так, чтобы они не были похожими.
• Если ты мысленно переименовываешь сущность, когда читаешь код, чтобы тебе было понятнее понимать её функционал, то переименуй её в это мысленное название.
• Выбери одно слово для одной концепции. Сложно будет понимать функционал, когда у тебя есть fetch, retrieve и get в названиях. Пусть лучше везде будет get.
• Длинное и понятное имя лучше, чем короткое, но непонятное.

Функции

• Функции должны быть короткими и компактными.
• Функции должны быть очень короткими и очень компактными.
• Приблизительный максимум 20 строк и 150 символов в одной строке, если не влезает, то нужно разделять.
• Функция должна выполнять только одну операцию.
  • Она должна выполнять её хорошо и ничего другого она делать не должна.
  • Если функция выполняет только те действия, которые находятся на одном уровне абстракции, то функция выполняет одну операцию.
  • Чтобы определить выполняет ли функция более одной операции, попробуй извлечь из нее другую функцию, которая не будет являться простой переформулировкой реализации.

• Любые условные операторы с длинными выборами через switch-case, if-else должны разделяться или объединяться без дублирования, возможно на классы с реализациями, а выбор реализации передать базовому классу, фабрике или еще кому-то.
• If, else, while и т.д. должны содержать вызов одной функции. Так будет читабельнее, понятнее и проще.
• Идеальное количество входных аргументов для функции = 0. Если входных аргументов больше трех, то стоит задуматься каким образом лучше от них избавиться, например, создать класс для этих аргументов.
• Чем больше входных аргументов, тем тяжелее понимается функция.
• Функция в которую передается аргумент-флаг, от которого зависит работа функции говорит о том, что функция выполняет более одной операции. Такие функции следует разбить на две и вызывать их уровнем выше.
• Функция, которая изменяет входной аргумент, должна отдавать ссылку на измененный объект, а не просто изменять без возврата. String transform(String text)
• Если функция, должна изменять входной аргумент, то пусть она изменяет состояние своего объекта-владельца.
• Если входной аргумент функции не должен меняться (и используется дальше в коде), то следует скопировать значение аргумента и внутри функции работать с копией.
• Вместо return null лучше использовать пустой объект — Collection.empty() или null-объект —EmptyObject().
• Всегда старайся использовать нестатические функции. Если это невозможно, то используй статические.
• Если есть код, который должен следовать один за другим, то передавай результаты первой функции во вторую, чтобы кто-нибудь не изменил последовательность вызовов.
• Используй полиморфизм вместо if/else или switch/case или when.
• Избегай отрицательных условий.

Комментарии

• Не используй комментарии, если ты можешь использовать функцию или переменную вместо этого.
• Не комментируй плохой код — перепиши его. Не стоит объяснять, что происходит в плохом коде, лучше сделать его явным и понятным.
• Комментарии можно использовать для передачи какой-то информации, предупреждения о последствиях, но не для объяснения того, как работает код.
• Используй TODO и FIXME в тех случаях, когда нужно пометить, что код нуждается в доработке, но сейчас нет ресурсов на это.
• Используй //region REGIONNAME //endregion REGIONNAME, а если используешь, то подумай можно ли разделить region на сущности.
• Документируй код, который является сложным, но чистым.
• Не оставляй старый закомментированный код. Ты можешь найти его в истории коммитов, если необходимо.
• Комментарии должны быть краткими и понятными. В комментариях с информацией не должно быть много информации. Все должно быть кратко и по делу.

Форматирование и правила

• Соблюдай codestyle, принятый на проекте.
• Соблюдай правила, принятые в команде.
• При соблюдении форматирования и codestyle код будет читаться проще и лучше. Ведь не зря книгу отдают на редакцию, перед тем, как её издавать.
• Нужно иметь автоматические средства, которые будут форматировать код за тебя.
• Файл с исходным кодом должен быть как газетная статья. Есть заголовок, краткое описание в виде параметров и содержание в виде функций. Если это не так, то стоит изменить форматирование.
• Сущности, связанные друг с другом, должны находиться рядом, например, в одном package, чтобы было проще навигировать по коду.
• Переменные(поля) класса должны находиться вверху класса.
• Переменные методов должны находиться ближе к своему месту использования.
• Функции должны находиться в порядке вызова. Если одна вызывает другую, то вызывающая функция должна находиться над вызываемой. C другой стороны, приватные функции более низкого уровня могут находиться внизу файла и не мешать пониманию кода высокого уровня. Но я предпочитаю первый способ.

Объекты и структуры данных

• Ты должен работать с абстракциями, чтобы реализацию можно было легко изменить.
• Ты должен работать с абстракциями, потому что клиент, использующий функционал, не должен знать о деталях реализации, он должен знать какую реализацию в каком случае использовать.
• Ты должен предоставлять API, с которым стоит работать и скрывать детали реализации, структуру. Так будет проще работать с такими сущностями и добавлять новые виды поведений, функционала и реализаций.
• DTO — Data Transfer Object. Класс, который содержит только данные и никакого функционала. Нужен для того, чтобы передавать какие-то данные. Объект такого класса должен быть неизменяемым.

Классы

• Классы должны быть компактными.
• Классы должны быть еще компактнее.
• Имя класса должно описывать его ответственности. Отсюда можно и вычислить размер класса.
• Функционал класса должен четко соответствовать и вписываться в название класса.
• Разделяй связанность на маленькие классы. Жесткой и обильной связанности не должно быть — это усложняет поддержку и развитие проекта.
• Помни о Single Responsibility. Сущность должна иметь одну и только одну причину для изменения.
• Соблюдай инкапсуляцию. Ослабление инкапсуляции всегда должно быть последней мерой.
• Обычно мы объявляем переменные и вспомогательные функции приватными, но иногда их нужно объявлять protected и иметь возможность обратиться к ней из теста.
• Если группа функций относится к определенному функционалу, то эту группу функций можно и нужно выделить в отдельный класс и использовать его экземпляр.

Обработка ошибок

• Используй Exceptions вместо возвращения кодов ошибок.
• Обработка ошибок — это одна операция. Если в функции есть ключевое слово try, то после блоков catch/finally ничего другого в функции быть не должно.
• Если у тебя есть enum, который перечисляет ошибки, то от него лучше избавиться и вместо него использовать исключения.
• Используй unchecked exceptions, чтобы явно указать на место в котором есть проблемы. Такие ошибки не нужно отлавливать, вместо этого нужно написать код так, чтобы этой ошибки никогда не было.
• Передавай достаточное количество информации вместе с выбросом исключения, чтобы потом пользователи твоего кода могли понять, что же действительно произошло.
• Вместо условных операторов с обработкой ошибок лучше выбрасывать исключения и обрабатывать их.
• Не передавай null куда-либо. Старайся этого максимально избежать.
• Обработка ошибок — это отдельная задача и не относится к основной логике программы.

Границы

• Мы всегда используем какие-либо библиотеки, которые чаще всего дают нам слишком широкий, слишком маленький функционал или конфликтуют с ожидаемым функционалом, что делает код грязнее в его конечном использовании. Избежать этого можно просто применив паттерны типа Decorator, Adapter, Facade или другие.
• Бывают ситуации, когда тебе нужно работать с функционалом, который находится в разработке или пока что не адаптирован для использования в продакшен коде. В этом случае стоит представить чего ты ждешь от библиотеки/этого функционала и написать свой интерфейс или создать сущность с которыми ты будешь работать в своем проекте так, как тебе нужно. Когда библиотека доделается и станет стабильной, ты адаптируешь её под свои готовые структуры и использовать уже готовый функционал.

Послесловие

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

пять ключевых моментов из обязательной к прочтению книги для программистов / Блог компании ГК ЛАНИТ / Хабр

Недавно я написал о «Пять книг, которые изменили мой стиль программирования». В комментариях несколько читателей рекомендовали «Чистый код» Роберта С. Мартина. В результате я прочитал книгу и нашел ее достойной углубленного обзора.

О книге

«Чистый код» был опубликован в 2008 году, и в последние годы он неизменно входит в пятерку самых продаваемых книг на Amazon. Автор, которого ласково называют «Дядя Боб», был одним из первых авторов Agile Manifesto и имеет некоторые серьезные полномочия. Книга получила средний рейтинг 4,4 на Goodreads из более чем 13 000 оценок. Достаточно сказать, что это одна из тех книг, которую должен прочитать каждый программист.

В этом обзоре я собираюсь сжать книгу до пяти основных мыслей.

1. Программирование — это прикладное искусство

Я часто думал, что архитектура и строительство — плохие метафоры для программирования. Мы не создаем полный проект, чтобы потом строить (по нему) от самого фундамента до полностью готового здания.

Скорее мы начнем с эскиза, постепенно добавляя детали. Мы пересматриваем, дорабатываем и расширяем — работаем на разных уровнях абстракции, пока программное обеспечение не заработает так, как нам нужно. Программное обеспечение никогда по-настоящему не закончено.

В этом и есть главная суть «Чистого кода». На протяжении всей книги автор проводит идею о том, что программное обеспечение является искусством и сродни живописи. 

Хороший код. Источник: xkcd

Но как перейти от простого написания кода к искусству программирования?

По словам Мартина, основными инструментами, которыми мы располагаем, являются непрерывный рефакторинг и разработка на основе тестирования (TDD). Они неотделимы друг от друга, как две стороны медали. Вот некоторые определения.

Рефакторинг — это процесс реструктуризации существующего программного кода без изменения его внешнего поведения.

Разработка через тестирование — это процесс, в котором требования превращаются в конкретные тестовые сценарии, а затем пишется код и проводится успешное тестирование.

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

1. Напишите тесты на еще не разработанную функциональность. Естественно, они не будут работать.
2. Реализуйте функциональность так, чтобы тесты выполнялись успешно. Пусть даже код сначала будет не самым хорошим.
3. Итеративно проводите рефакторинг кода не ломая тесты. С каждым разом ваш код будет становиться все более чистым. 

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

Таким образом, основная идея, представленная Мартином, заключается в том, что чистый код — это то, что возникает в процессе и практике разработки, а не создается за один раз.

2. Функции должны быть короткими!

«Первое правило функций — они должны быть маленькими. Второе правило функций заключается в том, что они должны быть еще меньше». 

Роберт С. Мартин

По словам Мартина, это означает две вещи.

1. Функции должны быть короткими — не длиннее 20 строк и в большинстве случаев менее 10 строк.
2. Функции должны иметь как можно меньше аргументов, желательно ни одного.

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

Автор книги делает аналогичное замечание о классах. По идее класс должен отвечать только за одну вещь. Это известно как принцип единственной ответственности (SRP).

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

3. Делай код самодокументирующимся

«Ясный и выразительный код с небольшим количеством комментариев намного лучше загроможденного и сложного кода с большим количеством комментариев». 

Роберт С. Мартин

В разделах, посвященных комментариям, осмысленным именам и форматированию, Мартин обосновывает необходимость самодокументирования кода. Пример этого приведен ниже:

После рефакторинга:

Примечания:

• Комментарий удален.
• Условная логика заключена в метод.
• Поскольку используется метод класса, то можно использовать переменные экземпляра и создавать методы вообще без параметров.
• Методу дается содержательное название, что очень облегчает понимание его назначения.

«Чистый код» включает в себя полную главу о присвоении имени, которая, по сути, является разработкой правил Тима Оттингера. 

Вот они.

• Используйте имена, раскрывающие намерения — например, int elapsedTimeInDays, а не int days …
• Используйте произносимые имена — например, Customer, а не DtaRcrd102
• Избегайте кодировок — не используйте префикс m_ и не используйте венгерскую нотацию.
• Выберите одно слово для каждой концепции — не используйте разные наименования типа fetch, retrieve, get для одной и той же операции по сути.

4. Абстракция важна

Абстракция. Источник: Abstruse Goose

Согласно «Чистому коду», если мы хотим убедиться, что наши функции выполняют только одну задачу, нам нужно убедиться, что все команды в каждой функции находятся на одном уровне абстракции.

Мартин иллюстрирует это следующим примером из FitNesse:

Это сочетание как минимум двух уровней абстракции. Первая — это высокоуровневая концепция рендеринга тега hr с заданным размером, вторая — это детали фактического синтаксиса низкоуровневого построения тега. Чтобы проиллюстрировать это, код реорганизован более чисто, как показано ниже:

Примечания:

• Функция render () теперь отвечает только за создание тега hr.
• Низкоуровневые детали построения тега теперь делегируются модулю HtmlTag.
• Форматирование размера абстрагировано в отдельную функцию.

По словам Мартина:

«Разделение уровней абстракции является одной из важнейших функций рефакторинга и одной из самых сложных для достижения успеха».

Теперь я буду уделять этому большее внимание при написании кода в будущем.

5. Чистый код — это тяжелая работа и соблюдение принципов

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

Скорее, у меня складывается впечатление, что Мартин уговаривает нас развить сильное чувство личных принципов и постоянно демонстрирует усилия и добросовестность, необходимые для того, чтобы сделать код из грязного чистым. В книге это называется «смыслом кода», то, что требует «дисциплинированного использования множества маленьких приемов, применяемых через тщательно приобретенное чувство чистоты».

«Чистый код пишется не по правилам. Вы не станете мастером программного обеспечения, изучив список приемов. Профессионализм и мастерство проистекают из ценностей, которые определяют дисциплину». 

Роберт С. Мартин

Лично я,  как человек, который страдает от недостатка уверенности, очень оценил этот акцент. Приятно знать, что даже дядя Боб твердо верит, что кодирование — сложное занятие и требует серьезной работы и дисциплины. Чтобы действительно стать профессионалами в написании чистого кода, нам нужно подходить к нашему развитию как программистов итеративно — так же как к написанию кода.

Заключение

Не каждая идея в «Чистом коде» принадлежит дяде Бобу, и он открыто признает это в разных местах книги. Во всяком случае, одна из вещей, которая делает книгу настолько успешной — это квинтэссенция мудрости из различных сообществ программистов, наполненная практическими примерами.

Если для меня и  есть один небольшой недочет, так это то, что  немного нарушен баланс между главами о деталях и с главами о концепциях более высокого уровня. Глава, посвященная системам, содержит всего 13 страниц, и почти половина посвящена комментариям. Тем не менее, я подозреваю, что автор специально уделил мало внимания системам, чтобы сохранить это обсуждение для его более поздней книги «Чистая архитектура», которая будет в моем списке литературы на 2021 год. Но все же, это одна из лучших книг по программированию.

P.s. Спасибо Zack Shapiro

В ЛАНИТ есть вакансии в области разработки. Те, кто ценит эту книгу, – милости просим к нам.

Рецензия на книгу “Чистый код. Создание, анализ и

“Чистый код прост и прямолинеен”

— Греди Буч​​​​​​

О «правильном» и «неправильном» коде

В современном мире последние десятилетия наблюдается постоянное увеличение “цифровизации” большинства сфер жизни, разрабатываемые проекты становятся более совершенными и сложными, над одним проектом может работать не один десяток разработчиков, где у каждого могут быть свои подходы к разработке. Из-за этого любой проект может превратиться в “солянку“ из кода. Поэтому одним из залогов успешного проекта является написание “правильного кода”, это позволит ускорить разработку, облегчит поддержку уже работающего проекта и сэкономит бюджет.  ”Неправильный код” может надежно работать, но на его поддержку и развитие по мере роста проекта, с каждым разом будет уходить больше сил, времени и денег. К “неправильному коду” можно отнести:

• Непонятно названные переменные, классы, методы;
• Использование “магических чисел”;
• Присутствие блоков кода с одними тем же функционалом;
• Отказ от использования общепринятых концепций применяющихся в других решениях;
• Запутанный код.

“Правильный код” исключает похожие ошибки. Поэтому для сохранения “правильности” кода сообщество разработчиков все время совершенствует и развивает стандарты и рекомендации для его написания. Об этих рекомендациях как раз рассказывает книга “Чистый Код”, автора Роберта Мартина.

Кому следует прочитать эту книгу?

Книгу стоит прочитать:

• Разработчикам, которые хотят повысить свою квалификацию;
• Лидерам команд, для создания единого правильного стиля разработки в команде;
• Менеджерам проектов, чтобы лучше понимать на что команды тратят время.

Книга не является библией чистого кода для разработчика, а считается сборником рекомендаций, которых следует придерживаться, для того, чтобы  проект не превратился в огромный снежный ком. Книга не подойдет новичкам, недавно начавшим получать опыт в разработке. Лучше всего она понятна и доступна разработчикам с опытом, которые могут трезво оценить советы автора, и максимально эффективно их использовать. В книге большое количество примеров на языке программирования Java. Автор сравнивает различные решения и разбирает их эффективность. Читателю неплохо было бы понимать что такое:

1. Параллельное выполнение задач в программе.
2. Автоматическое тестирование, юнит-тестирование.

Книга оформлена понятно и просто, каждую новую главу и вступление сопровождают рисунки. Единственным минусом может являться оформление листингов, иногда в тексте книги может быть вставлен листинг размером в десяток страниц, а это затрудняет понимание написанного. Ссылки и сноски хорошо раскрывают непонятные термины и вопросы, возникающие, по ходу чтения.

Оформление  глав:

Оформление листингов:

Основные идеи книги

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

Каждой проблеме посвящена отдельная глава, где подробно с примерами разбираются ошибки и даются рекомендации. Первая половина книги посвящена проблемам оформления кода таким как:

• Выбор имен для методов;
• Рекомендации к написанию функций;
• Рекомендации по использованию комментариев;
• Форматирование кода;
• Обработка исключений;
• Предоставление доступа к данным.

Вторая половина книги продолжает затрагивать проблемы оформления, но включает в себя также:

• Рекомендации по построению архитектуры приложения;
• Рекомендации по написанию юнит тестов;
• Взаимодействие со сторонним кодом;
• Рекомендации по реализации параллельного выполнения задач.

Положительные и отрицательные стороны книги

К положительным сторонам книги можно отнести:

• Описание проблем простым языком;
• Структурированность книги: одна проблема — одна глава;
• Множество советов, которые можно применить сразу;
• Много примеров;
• Подробная глава по многопоточности.

Отрицательные стороны:

• Очень большие листинги кода в книге, иногда занимают десяток страниц;
• Начинающим разработчикам будет тяжело понимать некоторые вещи;

Выводы

В итоге книга “Чистый Код” за авторством Роберта Мартина содержит в себе достаточно полезной информации, которую разработчик может применить в любой момент, чтобы сделать проект над которым он работает лучше. Книга не является легкой в прочтении и потребует от читателя усилий. Представленные примеры и сравнения заставят покопаться в поисках ошибок, но полученные навыки впоследствии пригодятся в работе. Также над “правильностью” написания кода могут помочь книги:

• «Рефакторинг с использованием шаблонов». Джошуа Кериевски;
• «Рефакторинг. Улучшение существующего кода». Джейн Робертс;
• «Эффективная работа с унаследованным кодом». Майкл К. Физерс;
• «Совершенный код». Стив Макконнелл.

Чистый код. Роберт Мартин

Эту книгу я читал два года назад. Но единственное, что помню из неё, что мне не понравился перевод. Поэтому в этот раз я решил прочесть её в оригинале и заодно собрать годные мысли в заметках. Сегодня рассмотрим первые 4 главы.

Глава 1. Чистый код

В первой главе автор даёт определение чистому коду. Если собрать все описания в один список, то чистый код:

• элегантный и производительный;
• простой и недвусмысленный;
• читаемый и поддерживаемый;
• тестируемый и с минимально необходимым API.

Глава 2. Названия

Коротко:

• названия должны быть понятными и последовательными;
• в них не должно быть двусмысленности;
• аббревиатуры в названиях — плохо.

Используйте названия, объясняющие, что вы хотите сделать.

// плохо
let d; // elapsed time in days

// хорошо
let elapsedTimeInDays;

Избегайте двусмысленных названий. Не стоит называть переменную accountList если это не список. Не используйте названия, которые отличаются одним-двумя символами, чтобы не путать их.

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

// плохо
let genymdhms;
class DtRec102 = { /* ... */ };

// хорошо
let generationTimestamp;
class Customer = { /* ... */ };

Переменная с хорошим названием быстро считывается и легко ищется. Использовать i, j, k стоит только для счётчиков. Названия функций и методов должны быть глаголами или начинаться с них. Геттеры, сеттеры и предикаты лучше называть с префиксами: get, set, is, has и т. д.

Прим. автора поста: думаю, в конвертирующих функциях глагол можно опустить: convertIntToStr →intToStr.

Используйте одно и то же слово для одного и того же понятия. Если в разных классах схожие методы называются по разному: fetch, get, load — то трудно запомнить, когда какой вызывать.

Глава 3. Функции

Коротко:

• короткие функции лучше громоздких;
• чем меньше аргументов, тем лучше;
• флаги лучше заменять на объект с настройками.

Функции не должны быть большими. Лучший размер для функции — 2–3 строки. (Прим. автора поста: про размер — спорно.) Каждая функция должна выполнять только одно действие. Но будьте аккуратнее с определением того, что такое «одно действие». Какие-то части можно вынести в отдельные функции, умейте останавливаться в правильный момент.

Названия должны полно описывать, что функции делают. Они должны быть консистентными, и недвусмысленными.

Больше, чем 3 аргумента использовать не стоит. Флаги лучше заменить на объект с настройками.

// плохо
const initPopup = (
  node,
  closeOnEsc=false,
  closeWithAnimation=false
) => {
  /* ... */
}

// хорошо
const initPopup = (node, options={}) => {
  const {
    closeOnEsc=false,
    closeWithAnimation=false
  } = options
  /* ... */
}

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

Глава 4. Комментарии

Коротко:

• комментарий не должен дублировать код;
• и должен сообщать дополнительные сведения, которых нет в коде.

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

// плохо
// if the employee is eligible for full benefits
if ((employee.flags.includes(HOURLY_FLAG)) && (employee.age > 65)) { /* ... */ }

// хорошо
if (employee.isEligibleForFullBenefits()) { /* ... */ }

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

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

В следующий раз

В главах 5–8 обсудим:

• форматирование, зачем оно нужно;
• структуры данных, абстракции;
• обработку ошибок и исключения.

Что такое «чистый код» в 2020-м? / Блог компании JUG Ru Group / Хабр

^{«Чистый код» и чистый кот}

Разработчиков хлебом не корми, дай поспорить о чистоте кода: например, недавно шумиху навёл пост Дэна Абрамова «Goodbye, Clean Code».

Но при этом у самого понятия «чистый код» нет чёткого определения. Главная книга по этому вопросу — «Clean Code», где Роберт «Дядюшка Боб» Мартин сразу заявляет: «сколько программистов, столько и определений». Впрочем, из этого он делает не вывод «говорить об этом бесполезно», а вывод «стоит сравнить разные определения». Поэтому в книге он привёл мнения нескольких выдающихся программистов о том, что такое чистый код.

Нам стало интересно: в 2020-м представления человечества о чистом коде остались теми же, или с выхода книги как-то изменились? Различаются ли мнения у разных айтишников: может, бэкендеры видят всё с одного ракурса, а тестировщики с другого?

В апреле Дядюшка Боб прилетит в Петербург выступить на трёх наших конференциях, и они как раз по трём разным направлениям (про .NET-разработку, про тестирование и про JavaScript). Поэтому мы спросили нескольких спикеров этих конференций, что такое чистый код для них, чтобы сравнить мнения экспертов индустрии в 2020-м.

А поскольку тема холиварная, наверняка кто-то из вас окажется не согласен с какими-то из мнений. В таком случае айда спорить в комментариях, это тоже весело!

UPD: Когда мы писали эту статью, Роберт планировал приехать на наши конференции. К сожалению, ситуация изменилась. Также из-за запрета на проведение массовых мероприятий мы перенесли конференции на другие даты. Следите за обновлениями на сайте конференции. 13 марта мы обновили этот пост, чтобы он не содержал некорректную информацию.

DotNext

Джон Скит

Джон — легенда Stack Overflow, автор книги «C# in Depth» и один из самых известных дотнетчиков планеты. Он дал нам такое определение:

«Для меня чистый код — это скучный код, с точки зрения имплементации. Единственный сюрприз в нём — это то, насколько он лишён сюрпризов. Я должен чувствовать „Да, я бы мог такое написать”, даже если бы на самом деле я и не мог — по тому, насколько хорошо он спроектирован.

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

Упомянутое отсутствие сюрпризов позже переносится и на использование: когда я пишу код, используя хорошо спроектированный API, мой код тоже становится очевидным и скучным».

Андрей Акиньшин

Посетителям DotNext не нужно представлять Андрея, но для остальных расскажем, что он известен своей работой над IDE Rider, библиотекой BenchmarkDotNet, яркими докладами и книгой «Pro .NET Benchmarking».

Когда мы спросили, что он думает про чистый код, Андрей сослался на два своих старых хабрапоста: «Совершенный код и реальные проекты» и «Комментировать или не комментировать». И мы выбрали для вас пару абзацев оттуда, с которыми кто-то наверняка захочет поспорить:

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

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

Дилан Битти

Хабрачитатели могут помнить Дилана по его вдумчивому и яркому докладу про работу с легаси-кодом: для Хабра мы делали его расшифровку. И когда мы обратились к Дилану по поводу чистого кода, он написал такой развёрнутый и продуманный текст, что его хоть отдельным постом публикуй:

«Для меня интересно, что понятие «чистый код» распространилось далеко за пределы круга людей, читавших книгу Роберта Мартина. Я общался с многими, многими разработчиками, которые слышали слова «clean code», но не читали книгу. Я даже встречал их в кодревью: «Тут всё довольно хорошо, но можешь немного почистить?» — и такая просьба может быть раздражающе неточной, если неочевидно, что «чистый» означает в данном конкретном контексте.

В английском есть слова, которые часто встречаются вместе — «clean», «tidy», «organised», «neat» — и для меня как носителя английского они все означают немного разные вещи. Я думаю, что полезно рассмотреть некоторые коннотации этих слов применительно к разработке софта.

Представим, например, кухню ресторана. У слова «clean» в этом контексте будут очень конкретные коннотации. Всё вымыто, стерилизовано, нет никакой угрозы заражения из-за сырых продуктов, и тому подобное.

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

А теперь представим деревообрабатывающий цех. В этом месте грязь тоже может вызывать проблемы, но здесь у вас совсем не такое определение «чистоты», как на кухне. Вы можете начищать зубило, пока оно не начнёт сверкать, но вы всё равно вряд ли стали бы резать им сосиски. Так что слово «clean» может быть очень субъективным.

Но для меня слова вроде «tidy» и «organised» работают и таких контекстах, где «clean» не очень хорошо подходит. «Organised» означает, что кто-то как следует подумал, как расположить элементы конкретного рабочего места, а «tidy» означает, что эти элементы действительно находятся на отведённых им местах. Как говорится в старой поговорке, «всему есть своё место и всё на своём месте».

Возможно, в случае с кодом нам стоит думать о словах «clean», «tidy» и «organised» как о трёх разных понятиях. «Clean» означает, что вы смотрите на составные части кодовой базы — методы, функции, интерфейсы — и не видите никаких причин для беспокойства. В именовании придерживаются конвенций; названия переменных и методов написаны без ошибок; в деталях вроде отступов и скобок придерживаются единого стиля; куда ни посмотри, видишь подтверждения того, что на базовом уровне этим заправляют люди, подходящие к делу серьёзно. Это противоположность «грязного кода» — такого, где в названиях куча опечаток, фигурные скобки и отступы захотичны, несоответствующие названия файлов. Это те вещи, которые магически оказываются исправлены, когда вызываешь инструмент «code cleanup» в чём-то вроде ReSharper.

«Organised» — это про архитектуру. Это о том, что можно нырнуть в незнакомую кодовую базу и найти вещи там, где ожидаешь их увидеть. Интерфейсы и доменные границы помогают, а не мешают; методы и переменные названы не просто корректно названы с точки зрения языка, но и отражают единый язык бизнеса, с которым работаешь.

А «tidy» — это про уважение локальных конвенций… кодовая база, в которой можешь найти нужные вещи в соответствующих им местах, даже если конкретная организационная модель вам в этот момент не слишком понятна.

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

Heisenbug

Это «конференция по тестированию не только для тестировщиков»: она на стыке тестирования и разработки. Поэтому многие её спикеры понимают специфику обоих этих миров сразу.

Иван Крутов и Анна Чернышева

Иван и Анна работают в разных компаниях, но кое-что их объединяет: оба много знают про Selenium. Мы общались с ними одновременно, так что получилось совместное определение:

Иван: «Для меня самое простое определение чистого кода — это код, который понятен без комментариев, «самодокументирующийся». Код, который завален комментариями, которые пытаются объяснить, что он делает — это не чистый код».

Анна: «У меня похоже: это код, в котором можно быстро разобраться, исправить баг, легко расширить его, дополнить».

Иван: «Ещё можно сказать, что это «код, за который не стыдно». Вообще говорят, что если ты смотришь код, который написал полгода назад, и не ужасаешься, то ты не развиваешься. Получается, что с каждым годом твой код должен становиться всё чище».

Себастиан Дашнер

Себастиан — Lead Java Developer Advocate в IBM, и его часто можно увидеть на Java-конференциях. Но поскольку сейчас он прилетает на Heisenbug, мы спросили его о чистом коде именно в контексте тестирования, и он ответил:

«По моему опыту, качество кода важно не только в случае продакшн-кода, но и для наших тестов. В тестах чистым кодом, правильными абстракциями и делегацией часто пренебрегают, что приводит к такому коду тестов, который не поддержишь. Когда мы рефакторим продакшн-код и меняем его поведение, становится видно, хорошую работу ли мы проделали над моделированием и имплементацией наших тестов».

Андрей Лушников

Андрей работает над инструментом для браузерной автоматизации Playwright, о котором мы недавно писали. Его определение оказалось самым лаконичным:

«Чистый код — это тупой, очень понятный код. И чем тупее, тем лучше».

Александра Сватикова

Александра — эксперт по информационной безопасности в Одноклассниках, которая «начинала в IT как Java-разработчик, но свернула не туда». Её определение оказалось таким:

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

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

HolyJS

Андрей Мелихов

Андрей известен многим по проекту «Девшахта». Неудивительно, что человек, постоянно формулирующий свои мысли в «Девшахта-подкасте», и свою позицию сформулировал чётко:

«Роберт «Дядя» Мартин тремя своими главными книгами («Clean Code», «The Clean Coder» и «Clean Architecture»), как мне кажется, пытается для себя ответить на вопросы: кто, что и как должен писать. Можно поспорить о корректности некоторых его выводов, но вот что, неоспоримо — эти книги построены на богатом личном опыте и здравом смысле. И в рамках этой идеи я могу сказать, что для меня чистый код — это код, который написал бы человек, споткнувшийся о немалое количество подводных камней в своей жизни и в этом болезненном процессе научившийся идти осторожной походкой, позволяющей этих камней избегать.

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

Чистый код — это код, который легко читается, легко поддерживается и легко расширяется. Именно эти три аспекта закладывают прочный фундамент под приложениями, которым предстоит жить годами в условиях изменчивости внешних требований. А именно такие приложения мы пишем в крупных компаниях»

Александра Калинина

Александра состоит в программном комитете HolyJS, у неё большой опыт в программировании — и, хотя она не с Heisenbug, с тестами она тоже знакома не понаслышке (unit, integration, E2E, B2B). Вот её текст:

«Clean code — сейчас это простое понятие, но понять его довольно трудно. Мне кажется, что чистый код может получиться при соблюдении следующих правил:

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

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

— код должен иметь понятную структуру. Т.е. должна быть понятна причина, по которой тот или иной кусочек кода находится в проекте.

— каждая строчка кода должна быть обоснована с точки зрения бизнеса»

Nicolò Ribaudo

Николо, будучи ещё студентом, стал одним из ключевых разработчиков компилятора Babel (об этом мы его уже расспрашивали отдельно). Его вариант оказался таким:

«Чистый код — это код, который можно легко разделить на маленькие атомарные составляющие.

«Атом кода» — это наименьший возможный набор инструкций, обладающий самостоятельным смыслом, не зависящие излишне от окружающего контекста: имена переменных и операций достаточно описательные, чтобы читающему их не требовалось выделять в голове дополнительную память для хранения их значений и возможных модификаций, а также не требовалось смотреть ещё куда-то в коде, чтобы понять, что означает результат этого «атома». Чем меньше атомы, тем проще понять, что делает код.

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

Заключение

Наконец, когда мнения были собраны, мы показали их самому Дядюшке Бобу и спросили, хочется ли ему что-то сказать. Ответ оказался таким:

«Я полностью поддерживаю комментаторов выше. Я бы добавил только одну вещь, которую когда-то сказал Майкл Фезерс: “Чистый код всегда выглядит так, будто его писал человек, которому не всё равно”».

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

• «Акиньшин пишет: „Пользователю важен не красивый код, а чтобы проект хорошо работал”. Но ведь в книге Боба ясно сказано, что чистый код нужен не просто для красоты, а из практических соображений: с запутанным и кривым кодом скорость разработки новых фич стремится к нулю. То есть чистый код и нужен как раз для того, чтобы проект хорошо работал и пользователь был доволен!»
• «Какое ещё „очень тупой и понятный код”? С „понятным” не спорю, но выбирать правильные названия — это целое искусство, требующее немало интеллектуальных усилий, и называть результат этой умственной работы „тупым” — оскорбительно!»
• «Слова „вы можете набивать свои шишки, пока остальные будут смотреть с недоумением” звучат уничижительно, как будто так только дураки делают. Но ведь всё лучшее и инновационное появляется, когда набиваешь свои шишки и понимаешь их причины, а не просто следуешь старым книжкам!»

UPD 12 марта: Хоть Дядюшка Боб и не сможет к нам прилететь, вряд ли наши петербургские конференции (для .NET-разработчиков, тестировщиков и JavaScript-разработчиков) обойдутся без споров о чистом коде. На сайтах конференций — всегда актуальные версии программ. Следите за обновлениями, а также подписывайтесь на наши рассылки — раз в неделю будем рассказывать об изменениях.

Как писать чистый и красивый код / Блог компании RUVDS.com / Хабр

Каким должен быть качественный код? Роберт Мартин выразил это невероятно точно, когда сказал: «Единственная адекватная мера качества кода — это количество восклицаний «какого чёрта!» в минуту».

Позвольте мне пояснить эту идею.

Каждый раз, когда я читаю чужой код, вот какие мысли приходят мне в голову:

• Какого чёрта! (с отвращением) — когда в некоем фрагменте кода нет необходимости.
• Какого чёрта! (с восхищением) — когда программист сделал что-то очень удачное.
• Какого чёрта! (с раздражением) — когда я не могу понять тот ужас, который находится у меня перед глазами.

Итак, что формирует первое впечатление от кода? Это то, насколько он чист и красив. Подобный код является признаком высокого профессионализма того, кто его написал.

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

Короче говоря, обучение написанию чистого кода — это тяжёлая работа. Вы должны вложить в неё немало сил. Вам нужна практика. Причём, на этом пути будут моменты, когда дело стопорится, когда ничего не получается, но это вас останавливать не должно — шаг за шагом вы будете приближаться к совершенству, повторять всё снова и снова до тех пор пока всё не окажется таким, каким должно быть. Обходных путей здесь нет.

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

Имена

Кендрик Ламар как-то сказал: «Если я соберусь рассказать настоящую историю, я начну её с моего имени».

В мире программ мы встречаем имена буквально повсюду. Мы даём имена функциям, классам, аргументам, пакетам, да чему угодно. Имена придумывают для файлов с программным кодом, для папок, и для всего, что в них находится. Мы постоянно изобретаем имена, и поэтому имена часто становятся тем, что загрязняет код.

Имя, которое вы даёте сущности, должно раскрывать её предназначение, намерение, с которым вы её используете. Выбор хороших имён требует времени, но позволяет сэкономить гораздо больше времени, когда страсти накаляются. Поэтому уделяйте внимание именам, а если вам удаётся найти имя, которое лучше справляется с возложенной на него задачей — замените им то, что вы уже используете. Любой, кто читает ваш код, будет вам благодарен за ваше внимательное отношение к именам.

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

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

Одна функция — одна задача

Луис Салливан однажды сказал замечательную вещь: «Форма следует функции».

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

Есть всего два правила написания чистых функций:

• Они должны быть маленькими.
• Они должны решать лишь одну задачу и должны делать это хорошо.

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

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

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

Код и комментарии

Вот интересное наблюдение, которое сделала Винус Уильямс: «Все делают собственные комментарии. Так рождаются слухи».

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

Комментарии, в лучшем случае — это необходимое зло. Почему? Они не всегда — зло, но в большинстве случаев это так. Чем старше комментарии — тем сложнее становится поддерживать их в актуальном состоянии. Многие программисты запятнали свою репутацию тем, что их комментарии, в ходе развития проектов, перестали согласовываться с кодом.

Код меняется и развивается. Блоки кода перемещаются. А комментарии остаются неизменными. Это — уже проблема.

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

Важность форматирования

Роберт Мартин однажды очень точно подметил: «Форматирование кода направлено на передачу информации, а передача информации является первоочередной задачей профессионального разработчика».

Полагаю, нельзя недооценивать эту идею. Внимание к форматированию кода — это одна из важнейших характеристик по-настоящему хорошего программирования.

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

Если вы думаете, что самое главное для профессионального разработчика — это «сделать так, чтобы программа заработала», это значит, что вы очень далеки от истины. Функционал, созданный сегодня, вполне может измениться в следующем релизе программы, но читаемость кода — это то, что оказывает воздействие на всё то, что с ним происходит, с самого начала его существования.

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

Учитывайте то, что вы запомнитесь тем, кто читает тексты ваших программ, по вашему стилю и аккуратности, и очень редко — по функционалу, реализованного в коде. Поэтому уделяйте внимание форматированию, например, придерживаясь правил, которые приняты в вашей организации.

Сначала — try-catch-finally, потом — всё остальное

Жорж Кангилем сделал верное наблюдение, когда сказал: «Человеку свойственно ошибаться, упорствовать в ошибке — дело дьявола».

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

Многие программы сверх меры перегружены конструкциями обработки ошибок. В результате полезный код оказывается беспорядочно разбросанным по этим конструкциям. Подобное ведёт к тому, что то, что составляет цель программы, практически невозможно понять. Это — совершенно неправильно. Код должен быть чистым и надёжным, а ошибки надо обрабатывать изящно и со вкусом. Подобный подход к обработке ошибок — признак программиста, отлично знающего своё дело.

Один из способов качественной обработки ошибок заключается в правильном использовании блоков try-catch-finally. В них включают потенциально сбойные места, и с их помощью организуют перехват и обработку ошибок. Эти блоки можно представить себе как выделение изолированных областей видимости в коде. Когда код выполняется в блоке try, это указывает тому, кто читает код, на то, что выполнение в любой момент может прерваться, а затем продолжиться в блоке catch.

Поэтому рекомендуется выделять блоки try-catch-finally в самом начале работы над программой. Это, в частности, поможет вам определить, чего от кода может ждать тот, кто будет его читать, при этом неважно, выполнится ли код без ошибки, или во фрагменте, заключённом в блок try, произойдёт сбой.

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

Итоги

Как выразить, буквально в двух словах, всё то, о чём мы говорили? Ответ на это вопрос — термин «чувство кода». Это, в мире программирования, эквивалент здравого смысла.

Вот что говорит об этом Роберт Мартин: «Чтобы написать чистый код, необходимо сознательно применять множество приёмов, руководствуясь приобретённым усердным трудом чувством «чистоты». Ключевую роль здесь играет чувство кода. Одни с этим чувством рождаются. Другие работают, чтобы развить его. Это чувство не только позволяет отличить хороший код от плохого, но и демонстрирует стратегию применения наших навыков для преобразования плохого кода в чистый код». По мне — так это золотые слова.

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

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

В завершение нашего разговора о чистом коде вспомним слова Гарольда Абельсона: «Программы должны писаться, в первую очередь, для того, чтобы их читали люди, и лишь во вторую — для выполнения машиной».

Уважаемые читатели! Какие приёмы вы используете для повышения качества собственного кода?

Книги по программному коду / Блог компании Издательский дом «Питер» / Хабр

Привет Хаброжители!
Издательство Питер решило вспомнить о хороших, но забытых книгах по чистому коду:

1. Чистый код: создание, анализ и рефакторинг. Библиотека программиста — Р. Мартин

2. Идеальный код — Э. Орам, Г. Уилсон

3. Читаемый код, или Программирование как искусство — Д. Босуэлл, Т. Фаучер

Чистый код: создание, анализ и рефакторинг. Библиотека программиста

Аннотация: даже плохой программный код может работать. Однако если код не является «чистым», это всегда будет мешать развитию проекта и компании-разработчика, отнимая значительные ресурсы на его поддержку и «укрощение». Эта книга посвящена хорошему программированию. Она полна реальных примеров кода. Мы будем рассматривать код с различных направлений: сверху вниз, снизу вверх и даже изнутри. Прочитав книгу, вы узнаете много нового о коде. Более того, вы научитесь отличать хороший код от плохого. Вы узнаете, как писать хороший код и как преобразовать плохой код в хороший. Книга состоит из трех частей. В первой части излагаются принципы, паттерны и приемы написания чистого кода; приводится большой объем примеров кода. Вторая часть состоит из практических сценариев нарастающей сложности. Каждый сценарий представляет собой упражнение по чистке кода или преобразованию проблемного кода в код с меньшим количеством проблем. Третья часть книги — концентрированное выражение ее сути. Она состоит из одной главы с перечнем эвристических правил и «запахов кода», собранных во время анализа. Эта часть представляет собой базу знаний, описывающую наш путь мышления в процессе чтения, написания и чистки кода.

Идеальный код

Аннотация: в этой уникальной книге самые авторитетные разработчики программного обеспечения делятся опытом оригинального решения задач, которые вставали перед ними при реализации крупных IT-проектов. С помощью этого издания читатель получит возможность оказаться на месте ведущих программистов, увидеть собственными глазами проблемы, возникавшие при реализации разнообразных проектов, и пройти увлекательный путь их преодоления. Авторские статьи отобраны Грегом Уилсоном, редактором журнала «Dr. Dobb’s Journal», одного из самых авторитетных IT-изданий в мире, а также редактором издательства O’Reilly Энди Орамом. Один лишь только список авторов делает эту книгу настоящим бестселлером — здесь вы найдете материалы, написанные такими признанными профессионалами, как Чарльз Петцольд, Джон Бентли, Тим Брэй, Брайан Керниган, и еще тридцатью четырьмя экспертами в области разработки программного обеспечения.

Читаемый код, или Программирование как искусство

Аннотация: любому программисту доводилось видеть код, который настолько неаккуратен и так пестрит ошибками, что от его чтения начинает болеть голова. За пять лет авторы этой книги проанализировали сотни примеров «плохого» кода (в основном — собственного), пытаясь определить, чем плох тот или иной код и как его можно улучшить. К какому выводу они пришли? Необходимо писать такой код, который читатель сможет понять максимально быстро, причем, даже если этот читатель — сам создатель этого кода. В данной книге рассматриваются базовые принципы и практические методы, которые можно применять всякий раз при написании кода. В каждой главе на примере несложных образцов кода, написанного на разных языках программирования, изучается отдельный аспект создания кода и демонстрируется, как сделать код простым для понимания.

Для Хаброжителей скидка 20% на всю категорию «Чистый код» — 87bdd2ae6c884881

Роберт К. Мартин: «Руководство по гибкому разработке программного обеспечения»

Даже плохой код может работать. Но если код не чист, он может поставить компанию-разработчика на колени. Каждый год из-за плохо написанного кода теряется бесчисленное количество часов и значительные ресурсы. Но так быть не должно.
Известный эксперт по программному обеспечению Роберт С. Мартин представляет революционную парадигму с Clean Code: A Handbook of Agile Software Craftsmanship . Мартин объединился со своими коллегами из Object Mentor, чтобы обобщить их лучшую гибкую практику очистки кода на лету в книгу, которая привит вам ценности мастера программного обеспечения и сделает вас лучшим программистом, но только если вы над этим будете работать.
Какую работу вы будете выполнять? Вы будете читать много кода. И вам будет предложено подумать о том, что в этом коде правильно, а что — нет. Что еще более важно, вам будет предложено переоценить свои профессиональные ценности и приверженность своему делу.
Чистый код разделен на три части. Первый описывает принципы, шаблоны и практики написания чистого кода. Вторая часть состоит из нескольких тематических исследований возрастающей сложности.Каждое тематическое исследование — это упражнение по очистке кода для преобразования базы кода, в которой есть некоторые проблемы, в надежную и эффективную. Третья часть — результат: одна глава, содержащая список эвристик и запахов, собранных при создании тематических исследований. Результатом является база знаний, которая описывает то, как мы думаем, когда пишем, читаем и очищаем код.
Читатели уйдут от этой книги и поймут

Как отличить хороший код от плохого Как написать хороший код и как преобразовать плохой код в хороший код Как создать хорошие имена, хорошие функции, хорошие объекты и хорошие классы Как форматировать код для максимальной читаемости Как реализовать полную обработку ошибок, не скрывая логику кода Как проводить модульное тестирование и практиковать разработку через тестирование Эта книга необходима любому разработчику, инженеру-программисту, менеджеру проекта, руководителю группы или системному аналитику, проявляющему интерес в создании лучшего кода.
«

.

A Handbook of Agile Software Craftsmanship [Книга]

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

Известный эксперт по программному обеспечению Роберт К. Мартин представляет революционную парадигму с Чистый код: Справочник по гибкому разработке программного обеспечения . Мартин объединился со своими коллегами из Object Mentor, чтобы превратить их лучшую гибкую практику очистки кода «на лету» в книгу, которая привит вам ценности мастера программного обеспечения и сделает вас лучшим программистом — но только если вы будете работать на него.

Какую работу вы будете выполнять? Вы будете читать код — много кода. И вам будет предложено подумать о том, что в этом коде правильно, а что — нет. Что еще более важно, вам будет предложено переоценить свои профессиональные ценности и приверженность своему делу.

Чистый код разделен на три части. Первый описывает принципы, шаблоны и практики написания чистого кода. Вторая часть состоит из нескольких тематических исследований возрастающей сложности.Каждое тематическое исследование — это упражнение по очистке кода — по преобразованию кодовой базы, в которой есть некоторые проблемы, в надежную и эффективную. Третья часть — результат: одна глава, содержащая список эвристик и «запахов», собранных при создании тематических исследований. Результатом является база знаний, которая описывает то, как мы думаем, когда пишем, читаем и очищаем код.

Читатели уйдут от этой книги с пониманием

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

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

.

Блог чистого кодера

Блог чистого кода

Роберт К. Мартин (дядя Боб)

Добро пожаловать!

атом / RSS-канал

• Петлевой

  30.09.2020

• Проведение конференции

  23.09.2020

• Отказ от приглашения

  09-12-2020

• Дизайн, управляемый REPL

  27.05.2020

• Еще немного Clojure

  09.04.2020

• Немного Clojure

  06.04.2020

• Новая надежда

  04-05-2020

• Открытое письмо Linux Foundation

  08.11.2019

• Что они думали о программистах.

  11-03-2019

• Кровообращение

  31.10.2019

• Почему именно Clojure?

  22.08.2019

• Почему это не …

  22.07.2019

• Классы против структур данных

  16.06.2019

• Типы и тесты

  08.06.2019

• 737 Макс 8

  18.05.2019

• FP vs.Обработка списков OO

  17.12.2018

• Мы, безобидные

  16.12.2018

• SJWJS

  14.12.2018

• Трагедия мастерства.

  28.08.2018

• Слишком чисто?

  13.08.2018

• Целые числа и оценки

  21.06.2018

• Маринованное состояние

  06-06-2018

• Ремесленник, Мастерица, Ремесленница

  05-02-2018

• FP vs.OO

  13.04.2018

• В большом

  04-02-2018

• Мы, программисты

  29.03.2018

• Дядя Боб Облет.
  У меня для тебя сделка!

  25.02.2018

• Аргумент о гражданстве

  18.01.2018

• Работа за кривой мощности

  15.01.2018

• Оправдания

  18.12.2017

• Dbtails

  12-09-2017

• Столы Бобби

  12-03-2017

• Жизнь на плато

  18-11-2017

• Женщины в спросе

  10-04-2017

• Инструменты — не ответ

  10-04-2017

• Проверка противоречивости

  10-03-2017

• Беспринципный мем

  29.09.2017

• Сьерра Джульетта Фокстрот

  26.09.2017

• Просто следуя заказам

  28.08.2017

• Женщины в технологиях

  14.08.2017

• Об уменьшении способности рационально обсуждать вещи

  08-10-2017

• Полиция мыслей

  08-09-2017

• Проблема с мозгом

  28.07.2017

• Отвези меня в Торонто, Хэл.

  24.07.2017

• Прагматическое функциональное программирование

  07-11-2017

• Первоклассные тесты.

  05-05-2017

• Доктор Кэлвин в комнате?

  16.03.2017

• Нарушение симметрии

  07.03.2017

• Тестирование как TSA

  06.03.2017

• Архитектура TDD Harms

  03-03-2017

• Необходимые комментарии

  -23-2017

• Типы и тесты

  13.01.2017

• Темный путь

  11.01.2017

• Урок TDD — Генерация ландшафта

  09.01.2017

• TDD не работает

  11-10-2016

• Алгоритм Дейкстры

  26.10.2016

• Lurn

  01.09.2016

• Маслобойка

  27.07.2016

• Мутационное тестирование

  06-10-2016

• Синий.Нет! Желтый!

  21.05.2016

• Тип войны

  05-01-2016

• Отказ от TDD

  19.03.2016

• Manhandled

  15.01.2016

• Фазы стабилизации

  14.01.2016

• Немного архитектуры

  04.01.2016

• Прелюдия к профессии

  27.11.2015

• Клятва программиста

  18-11-2015

• Сила плоскогубцев

  11-01-2015

• На будущее

  30.10.2015

• Agile — это не сейчас и не было водопадом.

  16.10.2015

• VW

  14.10.2015

• WATS Line 54

  10-05-2015

• Маленькая структура

  23.09.2015

• Сделай так, чтобы магия ушла.

  08-06-2015

• Выкройки

  07-05-2015

• Маленький синглтон

  07-01-2015

• Первая микросервисная архитектура

  28.05.2015

• Языковые слои

  27.04.2015

• Имеет ли значение организация?

  15.04.2015

• Императив MODE-B

  -21-2015

• Они назвали их компьютерами.

  19.02.2015

• «Интерфейс» считается вредным

  08.01.2015

• Циклы TDD

  17.12.2014

• OO против FP

  24.11.2014

• Шипы вокруг золота

  19.11.2014

• Обязанность программиста.

  15-11-2014

• Один путь хакера!

  11-12-2014

• Смех в комнате, где преобладают мужчины.

  26.10.2014

• ГОМЛ-1, Адаптивный дизайн

  10-08-2014

• Чистая микросервисная архитектура

  10-01-2014

• Микросервисы и банки

  19.09.2014

• Больше вещей меняется …

  18.09.2014

• Время тестирования

  03.09.2014

• Немного о выкройках.

  30.06.2014

• Моя лужайка

  20.06.2014

• TDD мертв?
  Последние мысли о командах.

  17.06.2014

• Первый

  19.05.2014

• Маленький пересмешник

  14.05.2014

• Принцип открытости и закрытости

  12.05.2014

• Ограничение рамок [2]

  11.05.2014

• Когда издеваться

  05-10-2014

• Принцип единой ответственности

  08.05.2014

• Профессионализм и TDD (Reprise)

  05-02-2014

• Повреждение конструкции, вызванное испытанием?

  05-01-2014

• Когда TDD не работает.

  30.04.2014

• Моногамный TDD

  25.04.2014

• Хранители кода

  04-03-2014

• Истина Коррупция Agile

  28.03.2014

• Когда следует подумать?

  11.03.2014

• Спектр доверия

  27.02.2014

• О, бригадир, где ты?

  -23-2014

• Где бригадир?

  21.02.2014

• Прерывание домена

  27.01.2014

• Кодирование в Clink (9)

  20.01.2014

• Экстремальное программирование, отражение

  12-10-2013

• Новички.Кода

  25.11.2013

• Орды новичков

  19.11.2013

• Healthcare.gov

  11-12-2013

• Беспечные

  24.10.2013

• Танцуйте вы, бесы!

  10-01-2013

• В. ПОТЕРПЕТЬ НЕУДАЧУ!

  26.09.2013

• Сначала тест

  23.09.2013

.

Мартин Роберт С. Коллекция чистого кода [PDF]

Pearson Education, Inc, 2012. — 703 с. — ISBN 10 978-0-13-292847-2, ISBN 13 0-13-292847-7. Коллекция чистых кодов Роберта К. Мартина состоит из двух бестселлеров:
Чистый код: руководство по гибкому разработке программного обеспечения
Чистый код Кодер: Кодекс поведения для профессиональных программистов
В «Чистом коде» легендарный эксперт по программному обеспечению Роберт К. Мартин объединился со своими коллегами из Object Mentor, чтобы изложить свои лучшие гибкие методы очистки кода «на лету» в книге, которая поможет внутри вас ценности мастера программного обеспечения и делают вас лучшим программистом — но только если вы над этим работаете.Вам будет предложено подумать о том, что в этом коде правильно, а что — нет. Что еще более важно, вам будет предложено переоценить свои профессиональные ценности и приверженность своему делу.
В книге «Чистый кодер» Мартин знакомит с дисциплинами, методами, инструментами и практиками настоящего мастерства в области программного обеспечения. Эта книга наполнена практическими советами обо всем, от оценки и программирования до рефакторинга и тестирования. Он охватывает гораздо больше, чем просто технику: речь идет об отношении.Мартин показывает, как подходить к разработке программного обеспечения с честью, самоуважением и гордостью; работать хорошо и работать чисто; честно общаться и оценивать; честно и ясно принимать трудные решения; и понять, что глубокие знания связаны с ответственностью действовать.
Читатели этого сборника уйдут с пониманием
Как отличить хороший код от плохого
Как написать хороший код и как преобразовать плохой код в хороший
Как создать хорошие имена, хорошие функции, хорошие объекты и хорошие классы
Как форматировать код для максимальной читаемости
Как реализовать полную обработку ошибок, не скрывая логику кода
Как проводить модульное тестирование и практиковать разработку через тестирование
Что значит вести себя как настоящий мастер программного обеспечения
Как разобраться с конфликтами графики и неразумные менеджеры
Как попасть в поток кодирования и пройти писательский тупик
Как справиться с безжалостным давлением и избежать выгорания
Как совместить стойкое отношение к новым парадигмам развития
Как управлять своим временем и избегать тупиков и болот , болота и болота
Как создать среду, в которой программисты и команды могут процветать
Когда говорить «Нет» и как это говорить Когда говорить «Y» es «–и что на самом деле означает« да »..