Чистый код

Но это неправильное предположение! Вот собственное определение Мартина из более ранней части этой главы:

Friends & Following

When source code is printed in a book, you get none of this. To make matters worse, Martin’s code samples have absolutely no syntax highlighting applied to them. When I read source code, certain parts are rendered in specific ways that make it easier to pull the information into my brain. Strings and literals are formatted differently, comments are dimmer so I can focus on code, and so on. Code samples in «Clean Code» are just characters, with occasionally bolding used to draw attention to parts that were changed. It’s amazing how much syntax highlighting helps make code more comprehensible, even at a completely subconscious level.

*
Неужели вся книга такая?

I consider many of the the suggestions to simply be common sense, but I’ve worked with enough of «other people’s code» to realize they don’t necessarily agree. With all of that said, I’d definitely recommend the book to Java developers at the beginner and intermediate levels.

Подумайте, что будущему читателю кода будет интересно, когда он встретит этот if? Ему нужно понять, что этот if проверяет, является ли год високосным (leap year). Но, вероятнее всего, его не будет волновать, как выполняется эта проверка. Если все-таки это будет интересно, то он может перейти к реализации этого метода. Убрав комментарий, мы невольно также разделили разные уровни абстракции в коде.

*
Есть глава «Объекты и структуры данных», где автор приводит такой пример структуры данных:

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

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

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

Другие издания — Просмотреть все

These are rather notes than a review while reading:

Обязательно стоит упомянуть одноименную книгу, написанную Робертом К. Мартином в 2008 году (Прим. переводчика: издание на русском «Чистый код. Создание, анализ и рефакторинг.»). Но и до выхода этой книги было много других книг и опытных разработчиков, говоривших о подобных концепциях.

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

Скажи мне, добрая IDE, что я могу с этим сделать?

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

Robert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.

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

Теперь все чисто!

Заключение

1. Use very descriptive names. Be consistent with your names.

Я вывел своего рода определение чистого кода, объединив мнения нескольких авторов и источников:

Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте — Джон Ф. Вудс (John F. Woods).

Приглашаем всех на открытое занятие «Элементы формальной логики. Базовые структуры данных в языке Java». На нем познакомимся с основами алгоритмов и булевой алгебры. В процессе мы изучим базовые структуры данных языка Java: массивы, списки и словари. Регистрация по ссылке.

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

First published January 1, 2007

Среди всех идей о функциях я выделю три:

В общем, избегайте комментариев для пояснения кода. А, так как вы используете систему управления версиями кода вроде GIT, то избегайте и закомментированного кода (удалите его!), информации об авторах частей кода и т. п.

Чистый код и проблемы , связанные с его написанием

2. A function should not do more than one thing.

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

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

На самом деле, в моей IDE я могу выделить кусок кода и в меню «Refactor This» увидеть все доступные рефакторинги, которые можно применить к этому конкретному случаю:

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

He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.

Когда я учился программировать в 90-х, мои учителя обычно просили меня писать комментарии везде. Довольно часто приходилось слышать что-то вроде: «Если вы не будете комментировать код, я не приму ваш экзамен…». Целью этих комментариев было облегчить чтение нашего кода. Но мы преследуем эту же цель при написании чистого кода, и комментарии — не лучший способ ее достичь.

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

Что такое чистый код: рекомендации к чистоте кода

4. Stepdown rule: every function should be followed by those at the next level of abstraction (low, intermediate, advanced).

Я хочу, чтобы мой код был чистым!

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

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

Первое правило: функции должны быть компактными. Второе правило: функции должны быть ещё компактнее. Я не могу научно обосновать своё утверждение. Не ждите от меня ссылок на исследования, доказывающие, что очень маленькие функции лучше больших. Я могу всего лишь сказать, что я почти четыре десятилетия писал функции всевозможных размеров. Мне доводилось создавать кошмарных монстров в 3000 строк. Я написал бесчисленное множество функций длиной от 100 до 300 строк. И я писал функции от 20 до 30 строк. Мой практический опыт научил меня (ценой многих проб и ошибок), что функции должны быть очень маленькими.

464 pages, Paperback

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

Понятные имена, маленькие функции, отсутствие комментариев для пояснения кода… все ясно. Но как это сделать? Как написать код, следуя этим концепциям?

Некоторые принципы

Я добавил комментарий. Теперь я могу спать спокойно. Но лучшее ли это решение?

Если таково качество кода, который создаёт этот программист — на досуге, в идеальных условиях, без давления реальной производственной разработки программного обеспечения — тогда зачем вообще обращать внимание на остальную часть его книги? Или другие его книги?

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

7. Flag arguments are ugly. Passing a boolean into a function is loudly proclaiming that this function does more than one thing. It does one thing if the flag is true and another one if the flag is false.

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

‣ How to tell the difference between good and bad code
‣ How to write good code and how to transform bad code into good code
‣ How to create good names, good functions, good objects, and good classes
‣ How to format code for maximum readability
‣ How to implement complete error handling without obscuring code logic
‣ How to unit test and practice test-driven development

Приложение. Инструменты рефакторинга

У нас есть два публичных статических метода, один приватный конструктор и пятнадцать приватных методов. Из пятнадцати приватных методов аж тринадцать либо имеют побочные эффекты (они изменяют переменные, которые не были переданы им в качестве аргументов, например buildIncludeDirective , который имеет побочные эффекты на newPageContent ), либо вызывают другие методы, которые имеют побочные эффекты (например, include , который вызывает buildIncludeDirective ). Только isTestPage и findInheritedPage выглядят как будто без побочных эффектов. Они по-прежнему используют переменные, которые в них не передаются ( pageData и testPage соответственно), но, кажется, делают это без побочных эффектов.

Множество инструментов рефакторинга!

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.
Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship . Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code on the fly into a book that will instill within you the values of a software craftsman and make you a better programmer but only if you work at it.
What kind of work will you be doing? You’ll be reading code — lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.
Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code — of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and «smells» gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.
Readers will come away from this book understanding

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

His book «Clean Code» is, in many ways, an introduction to the concept of Software Craftsmanship and a guide for developers interested in becoming craftsmen. Clean Code is not about only writing correct code, it’s about writing code that is designed well, code that reads well, and code that expresses the intent of the author.

Порекомендовал бы я вам эту книгу? Нет. Даже в качестве текста для начинающих, даже со всеми оговорками выше? Нет. Может быть, в 2008 году я рекомендовал бы вам эту книгу? Могу ли я рекомендовать его сейчас как исторический артефакт, образовательный снимок того, как выглядели лучшие практики программирования в далёком 2008 году? Нет, я бы не стал.

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

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

Когда следует проводить рефакторинг кода?

Давайте проигнорируем import с подстановочными знаками.

3. Теперь код перемещен в метод, а вместо него идет вызов этого метода. Инструмент позаботился о создании метода, перемещении туда кода и изменении всех мест, где был такой же код, на этот один вызов метода (он ищет дубликаты кода).

This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.

Написать код уже достаточно сложно, и без раздумий о его чистоте

The book is essentially divided into two parts. The first part contains Bob’s suggestions for writing and maintaining clean code. This includes suggestions on everything ranging from how to properly comment code and how to properly name variables to how to separate your classes and how to construct testable concurrent code. The second part of the book uses the principles in the first part to guide the reader through a few exercises in which existing code is cleaned.

Первоначально я читал «Чистый код» в группе на работе. Мы читали по главе в неделю в течение тринадцати недель.

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Примеры того, что не является рефакторингом:

Переименование (rename)

На этом этапе вы можете сделать вывод, что, возможно, определение Мартина «побочный эффект» не включает переменные-члены объекта, метод которого мы только что вызвали. Если мы примем это определение, то пять таких переменных, pageData , isSuite , testPage , newPageContent и pageCrawler , неявно передаются каждому вызову приватного метода, и это считается нормальным; любой приватный метод свободен делать всё, что ему нравится, с любой из этих переменных.

Инструмент извлечения метода даже осмеливается предложить подходящее имя

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

Комментарии не запрещены, есть ситуации, когда комментарии вполне уместны:

The first part of the book is fantastic. I can’t recommend it highly enough for a professional software developer that wishes to elevate him or herself to a higher standard. This guide is excellent, and gave me lots of things to think about while reading it. I could almost feel myself becoming a better programmer as I internalized Martin’s advice, and the code I’ve been writing has been noticeably better since I began following his suggestions.

*
Я написал это эссе, потому что постоянно вижу, как люди рекомендуют «Чистый код». Я почувствовал необходимость предложить антирекомендацию.

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

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

Источники:

https://deveducation.com/blog/kak-napisat-chistyy-kod-bez-oshibok-i-kakikh-oshibok-izbegat/&rut=b11e7ef2167c7088b660bd7cf3d9ef85bd7b8e86bcfc81f4accb32baa6671a95
https://habr.com/ru/companies/otus/articles/682922/&rut=9688701538d20aa382c1a456b9e41c23dc7e945dc7ad4f0ce64329fbb142fa3c
https://codernet.ru/articles/drugoe/chistyij_kod_opredelenie_pravila_napisaniya_i_primeryi/&rut=98fe984b2286206f1ac5bd5c5ef7b25ace317ea21c7e2bd085f8f9cb95f5af31
https://books.google.com/books/about/%D0%A7%D0%B8%D1%81%D1%82%D1%8B%D0%B9_%D0%BA%D0%BE%D0%B4_%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B0.html?id=2zjECwAAQBAJ&rut=b4cd84012563d0e076d388eea3779c85e5c63e8ae85770587a026a1e3dc01c65
https://books.google.com/books/about/%D0%A7%D0%B8%D1%81%D1%82%D1%8B%D0%B9_%D0%BA%D0%BE%D0%B4_%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B0.html?id=PFkSEQAAQBAJ&rut=aafc73a21b61d94c027d63badda491ff920c1d38b62bf9773558cd0bdb9830f9
https://habr.com/ru/articles/508876/&rut=509db44e7c769ee7d6b000be24f0a9b962baee22224fa3eed9b4a874273b3be3
https://www.goodreads.com/book/show/3735293-clean-code&rut=efd610359f826fc93e0676e4743600e88c7ce7118f82eeb9ea209052439ea8e1
https://www.goodreads.com/book/show/61170173&rut=bb353e5bd467a5d6af3bc2bcb5d2ed11cc7d9275d8e8efbaa8595f4bfb1a9135
https://tproger.ru/articles/kak-napisat-chistyj-kod-i-sdelat-zhizn-proshhe&rut=d9fbe76d0a1e1b2d881ebd3300cb6ff0f727702d428c40884f4512ce94fff189