Что такое хороший код

Что такое хороший код, или как стать востребованным разработчиком

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

Начну, пожалуй, с философии, а именно, со слов Сократа: «Вот вам мой совет — никогда не слушайте ничьих советов».

Уверен, что вопрос «Что такое хороший код?», возник с самого начала появления такой отрасли как программирование. И в процессе становления этой индустрии критерии оценки довольно серьезно менялись. Вот некоторые из них:

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

Я занялся программированием более 20 лет назад и честно пытался придерживаться правил написания хорошего кода, которые были актуальны на тот период времени. Только вот в чем фишка: как бы я ни старался, меня не покидало ощущение, что я написал нехорошо и можно сделать лучше. И я старался снова, осваивал новые технологии, некоторые канули в лету, некоторые развились настолько, что стали иметь мало общего с первоначальным прототипом, и все равно я так и не получил 100% уверенности, что да — этот код написан хорошо. И как оказалось, причина этому довольно проста. Хорошего кода в классическом понимании не существует, потому что невозможно угодить всем и вся. Но в процессе поиска ответа на вопрос, как научиться писать хороший код, я получил ответы на множество других вопросов и, что самое важное для программиста — это профессиональный опыт и знания. И я готов поделиться своим опытом в своих статьях.

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

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

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

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

Совет второй — ваша задача как разработчика, это понять, что нужно заказчику. Чем точнее вы это поймете, тем точнее вы это реализуете.

Чем быстрее и гармоничнее происходит процесс, тем более важной частью команды Вы становитесь:

• Программирование — это командный вид отрасли, если хотите преуспеть в ней, то с этим придется считаться;

• Если вы думаете, что вы самый умный программист, а все остальные программисты тупые, то советую переехать из Антарктиды и прекратить общаться с пингвинами. Допускаю, что они не очень сильны в этой области, но, если вы все-таки находитесь в цивилизации и являетесь сотрудником маленькой компании, тогда вперед в большую. Уверяю на 100% вас там ждут, правда, вас проверят на наличие знаний и спрашивать о них будут не пингвины;

• Если вы гениальны в программировании и считаете, что компания с большим (хорошо, уточню) многомилионным оборотом и выше будет расположена к вам, то вы ошибаетесь. Скорее всего вы окажетесь за бортом. Объясняю на своем примере: от меня должностные обязанности требуют управления командой разработчиков. Другими словами, на мне лежит ответственность за сроки разработки и качество кода разработки. А вот с чем я сталкиваюсь, когда беру в команду гениального программиста:

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

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

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

Четвертое. Гениальный программист не понимает, что, если в контроле «КНОПКА» обнаруживается текст «КНОПКО» — для заказчика это баг.

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

Как отличить хороший код от плохого?

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

Что нужно всегда помнить при разработке программ?

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

Сколько и чему нужно учиться чтобы стать востребованным (и хорошо оплачиваемым) разработчиком?

Текст объявления: «Нужен личный водитель до 20 лет с навыками эксперта по рукопашному бою, умению пройти тренировочный рубеж спецназа ГРУ за минуту в водолазном скафандре, при этом поджарив одновременно 10 пирожков на одной сковородке». Примерно так обычно описываются должностные обязанности. Но это совершенно не значит, что вам все это нужно выполнять. В требованиях, как правило, указан максимум. Выделите из всего круга то, что вы знаете и умеете, добавьте немного артистизма и красок, и вперед — убеждать наших менеджеров по персоналу. Но прежде чем это сделать, все-таки оцените трезво свои знания. А то у некоторых есть один очень хороший симптом под названием «Я знаю очень много», который сразу говорит о том, что вы обладаете посредственным багажом знаний. С другой стороны, если у вас большое количество вопросов и вы начинаете понимать, как мало вы знаете, то это уже показатель, что ваш багаж знаний солидный и можно претендовать на уровень разработчика, а не джуниора.

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

• достичь уровня начинающего разработчика (junior) вполне можно за 6 месяцев;
• достичь уровня разработчика (developer) — за 12-18 месяцев;
• продвинутого разработчика (key developer) — 2-5 лет;
• экспертного уровня(seignior) — от 7 лет и выше.

С чего начать?
В качестве ответа на этот вопрос хорошо подходит высказывание Лао-Цзы: «Даже самое долгое путешествие начинается с первого шага».

Источник

Как писать чистый и красивый код

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

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

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

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

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

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

Имена

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итоги

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

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

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

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

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

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

Источник

Что такое хороший код? Считаем звёзды

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

Этот код тянет как минимум на одну звезду 🙂

Такой код в настоящее время распространён повсеместно. Причин этому несколько, вот наиболее заметные:

Массовая цифровизация, из-за которой техзадания программистам ставят люди, далёкие от IT (например, руководители заводов) и они в принципе не могут оценить качество кода.

Высокие зарплаты в IT активно привлекают всех-всех-всех, которые трудоустраиваются, пройдя курсы «вайти-вайти за месяц» и имея соответствующие навыки.

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

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

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

На практике эффективность по времени иногда определяется не по этому учебно-тренировочному критерию, а по объективным целям и задачам проекта, и может быть задана как относительно («на каждый N не больше k»), так и абсолютно («открывать окно не дольше 0,5 секунды») или даже субъективно («не менее 80% опрошенных согласились, что программа открывается мгновенно»).

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

Код, который сам имеет минимальный объём. Можно сказать, что он оптимизирован и по процессору, и по оперативке, и по накопителю.

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

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

Выводы

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

Источник

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

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

Прочтение этой статьи: 15 минут
Осмысление методики: 10 минут
Ощутимые результаты: 30 минут

Зачем?

Что можно сказать о плохом коде?

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

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

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

Например, есть вот такой код для отсылки уведомления на мобильное устройство:

Вроде кажется, что это более-менее чистый код. Но это только так кажется.

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

Такая методика существует.

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

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

В начале этого метода идет отдельный кусочек кода, который решает отдельную задачу, дает ответ на отдельный вопрос: “можно ли найти девайс?”

Этот код можно отделить и назвать:

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

Идем дальше. Давай посмотрим внутрь isLocatable(). В начале видим тоже самое: в этом методе есть два алгоритма, которые отвечают на совершенно разные вопросы:

Этот код уже похож на нормальную английскую речь. Его когнитивная нагрузка очень низкая: читая метод isLocatable() ты видишь, какое он принимает решение и фокусируешь свое внимание только на высоком уровне. Читая isDeviceExpired(), ты понимаешь, как это решение принимается и твое внимание сосредоточено на конкретных данных.

Этот код уже не требует анализа — его достаточно лишь только прочитать.

Заодно, кстати, ты узнал что означает, когда token пустой. Обрати внимание, каким элегантным и надежным способом это знание закреплено в проекте: названием метода.

Ах да, заметь: этому коду уже не нужны комментарии. Instant win!

Почему?

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

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

* 300ms — средняя скорость переключения контекста мышления по разным оценкам и исследованиям.

Примеры

Два алгоритма: один читает конфигурацию в одном из двух вариантов (множественный и единичный), второй находит корневой каталог проекта. Разделяем и даем имена:

Код поиска картинки в мобильном приложении на iOS:

Если картинки нет, то нужно взять общую картинку. Результат положить в кэш. Разделяем:

Распиливаем данные из SQL в память. Я этот код писал сам год назад, а сейчас, когда искал примеры для статьи, долго пытался понять, что вся эта каша делает.

Собираем XML для беседы с Amazon S3. Поскольку мы точно знаем, какие данные мы туда кладем, то XML создается вручную:

Теоретически это довольно понятный код, но давай его упростим:

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

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

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

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

Как внедрить

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

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

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

Update: убрал конструкции вида «if (true) return true» из примеров, т.к. суть статьи не в этом, но каждый считает своим долгом прокомментировать этот момент.

Источник