6 простых советов по написанию чистого кода


Оглавление (нажмите, чтобы открыть):

15 правил написания качественного кода

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

Правило 1. Следуйте стандартам оформления кода.

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

Например, в этом куске кода в соответствии со стандартом есть 12 ошибок:

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

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

Правило 2. Давайте наглядные имена.

Ограниченные медленными, неуклюжими телетайпами, программисты в древности использовали контракты для имён переменных и процедур, чтобы сэкономить время, стуки по клавишам, чернила и бумагу. Эта культура присутствует в некоторых сообществах ради сохранения обратной совместимости. Возьмите, например, ломающую язык функцию C wcscspn (wide character string complement span). Но такой подход неприменим в современном коде.

«Росбанк», Москва, до 60 000 ₽ (до налогов)

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

Гораздо важнее, чтобы вы долго и хорошо думали перед тем, как что-то назвать. Является ли имя точным? Имели ли вы в виду highestPrice или bestPrice? Достаточно ли специфично имя, дабы избежать его использования в других контекстах для схожих по смыслу объектов? Не лучше ли назвать метод getBestPrice заместо getBest? Подходит ли оно лучше других схожих имён? Если у вас есть метод ReadEventLog, вам не стоит называть другой NetErrorLogRead. Если вы называете функцию, описывает ли её название возвращаемое значение?

В заключение, несколько простых правил именования. Имена классов и типов должны быть существительными. Название метода должно содержать глагол. Если метод определяет, является ли какая-то информация об объекте истинной или ложной, его имя должно начинаться с «is». Методы, которые возвращают свойства объектов, должны начинаться с «get», а устанавливающие значения свойств — «set».

Правило 3. Комментируйте и документируйте.

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

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

Правило 4. Не повторяйтесь.

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

  • Создание справочников API из комментариев, используя Javadoc и Doxygen.
  • Автоматическая генерация Unit-тестов на основе аннотаций или соглашений об именовании.
  • Генерация PDF и HTML из одного размеченного источника.
  • Получение структуры классов из базы данных (или наоборот).

Правило 5. Проверяйте на ошибки и реагируйте на них.

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

Правило 6. Разделяйте код на короткие, обособленные части.

Каждый метод, функция или блок кода должн умещаться в обычном экранном окне (25-50 строк). Если получилось длиннее, разделите на более короткие куски. Даже внутри метода разделяйте длинный код на блоки, суть которых вы можете описать в комментарии в начале каждого блока.

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

Правило 7. Используйте API фреймворков и сторонние библиотеки.

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

Правило 8. Не переусердствуйте с проектированием.

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

Правило 9. Будьте последовательны.

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

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

Правило 10. Избегайте проблем с безопасностью.

Современный код редко работает изолированно. У него есть неизбежный риск стать мишенью атак. Они необязательно должны приходить из интернета; атака может происходить через входные данные вашего приложения. В зависимости от вашего языка программирования и предметной области, вам возможно стоит побеспокоиться о переполнении буфера, кросс-сайтовых сценариях, SQL-инъекциях и прочих подобных проблемах. Изучите эти проблемы, и избегайте их в коде. Это не сложно.

Правило 11. Используйте эффективные структуры данных и алгоритмы.

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

Правило 12. Используйте Unit-тесты.

Сложность современного ПО делает его установку дороже, а тестирование труднее. Продуктивным подходом будет сопровождение каждого куска кода тестами, которые проверяют корректность его работы. Этот подход упрощает отладку, т.к. он позволяет обнаружить ошибки раньше. Unit-тестирование необходимо, когда вы программируете на языках с динамической типизацией, как Python и JavaScript, потому что они отлавливают любые ошибки только на этапе исполнения, в то время как языки со статической типизацией наподобие Java, C# и C++ могут поймать часть из них во время компиляции. Unit-тестирование также позволяет рефакторить код уверенно. Вы можете использовать XUnit для упрощения написания тестов и автоматизации их запуска.

Правило 13. Сохраняйте код портируемым.

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

Правило 14. Делайте свой код собираемым.

Простая команда должна собирать ваш код в форму, готовую к распространению. Команда должна позволять вам быстро выполнять сборку и запускать необходимые тесты. Для достижения этой цели используйте средства автоматической сборки наподобие Make, Apache Maven, или Ant. В идеале, вы должны установить интеграционную систему, которая будет проверять, собирать и тестировать ваш код при любом изменении.

Правило 15. Размещайте всё в системе контроля версий.

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

Заключение.

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

Шесть советов по написанию более понятного программного кода

Как уберечь себя от проблем, порожденных собственными программами

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

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

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

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

Пример

В качестве иллюстрации в этой статье я буду рассматривать программу, представляющую собой гипотетическую компьютерную игру под названием Kill Bad Aliens (Убей плохого инопланетянина). Участник этой игры должен управлять космическим кораблем. Этот корабль перемещается по горизонтали в нижней части экрана и стреляет снарядами по вертикали. Управление этим космическим кораблем будет осуществляться, скажем, с помощью клавиатуры.

Рис. 1. Наша гипотетическая игра

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

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

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

Итак, вы садитесь за рабочий стол и начинаете писать программный код игры Kill Bad Aliens на языке C++. Сначала вы определяете объекты, которые будут представлять космический корабль, снаряды игрока, инопланетян и их бомбы. Затем вы пишете код для графического представления на экране всех указанных объектов. После этого вы пишете код для перемещения объектов по экрану в зависимости от времени. И, наконец, вы пишете игровую логику, искусственный интеллект инопланетян, программный код для ввода с клавиатуры команд игрока и т.д.

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

Совет 1. Будьте благоразумны – пишите комментарии.

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

Следует, однако, отметить, что написание комментариев – это тоже искусство. Для достижения мастерства в этом виде деятельности необходима практика. Комментарии бывают хорошие и плохие.

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

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

Мастер Йода рекомендует:  15 скриптов таймера обратного отсчёта на jQuery и CSS3

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

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

И уж если мы подошли к этому, еще одна рекомендация – никогда не делайте такого:

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

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

  1. Несколько предложений в начале процедуры/функции, объясняющих, что она делает.
  2. Описание значений, передаваемых в эту процедуру/функцию.
  3. В случае функции — описание смысла возвращаемых параметров.
  4. Внутри процедуры/функции – комментарии, разбивающие программный код на короткие подзадачи.
  5. Для особо сложных фрагментов кода – краткое пояснение того, что происходит.

Итак, все, что нам необходимо – это описание в начале и несколько «указателей» внутри, поясняющих выбранный путь. Все это делается очень быстро и в длительной перспективе экономит массу времени.

Ниже приведен пример из нашей гипотетической игры Kill Bad Aliens. Рассмотрим объект, представляющий снаряды, которыми стреляет игрок. Вам придется часто вызывать функцию, которая будет перемещать этот объект вверх и определять, куда он попал. Я бы написал эту процедуру примерно так:

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

Совет 2. Используйте оператор #define чаще. КАК МОЖНО ЧАЩЕ.

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

Хороший способ: В некотором глобальном файле напишите следующую строку:

Теперь, если захотим присвоить игроку несколько призовых баллов, достаточно написать следующее:

Большинство программистов так или иначе знают, что надо поступать именно так. Однако для последовательной реализации этой концепции необходима внутренняя дисциплина. Почти каждый раз, когда вы вводите числовую константу, надо тщательно обдумать – не задать ли ее в некотором «центральном пункте». Предположим, например, что вы хотите иметь игровую область с размерами 800 х 600 пикселов. Настоятельно рекомендую задавать размеры этой области следующим образом:

Если впоследствии вы решите изменить размеры игрового окна (а это весьма вероятно), то возможность централизованного изменения этих значений сэкономит вам время дважды. Во-первых, вам не придется просматривать весь свой код в поисках всех мест, где вы указали ширину экрана, равную 800 пикселам. («800 пикселов! И о чем я только думал?») Во-вторых, вам не придется исправлять неизбежные ошибки, связанные со ссылками, которые вы неминуемо пропустите.

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

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

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

Теперь достаточно одной перекомпиляции – и ваша игра станет значительно веселее и даже безумнее.

Рис. 2. Игра Kill Bad Aliens до изменения констант
Рис. 3. Игра Kill Bad Aliens после увеличения всех констант (играть, может быть, трудновато, но посмотреть интересно)

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

Совет 3. Не давайте переменным имена, способные ввести в заблуждение.

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

Один из основных способов достижения этой цели состоит в том, чтобы давать переменным, процедурам и т.д. хорошие, т.н. «говорящие» имена. Если упомянутый выше гипотетический читатель вашего кода, посмотрев на имя переменной, подумает: «Ага, я понимаю, что это такое», это сэкономит ему пять минут – ему не придется просматривать вашу программу на предмет объяснений, что, в конце концов, по мысли автора должно означать имя incremeter_side_blerfm .

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

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

я, скорее всего, написал бы следующее:

Любое недоразумение, обусловленное более коротким именем, будет устранено очень быстро, а «читаемость» кода улучшится.

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

Обратите внимание, что массив для всех инопланетян так и называется – aliens . И это очень хорошо. Данное имя передает именно то, что я хотел сказать, однако при этом оно достаточно короткое, чтобы я мог ввести его с клавиатуры тысячи раз и не сойти при этом с ума. По всей вероятности, вы будете использовать этот массив ОЧЕНЬ ЧАСТО. Если вы назовете этот массив all_aliens_currently_on_screen , ваш программный код станет на десять миль длиннее и настолько же непонятнее.

Кроме того, параметру цикла я без каких-либо дополнительных комментариев дал простое имя i . Если вы только начали осваивать стратегию описательного именования переменных, у вас может возникнуть искушение дать этой переменной «говорящее» имя counter (счетчик) или что-то вроде этого. Это совсем не обязательно. Цель именования переменной состоит в том, чтобы немедленно вызвать у читателя реакцию: «Ага, я знаю, что это значит». Если я дам этой переменной имя i, j и т.д., любой читатель сразу поймет, что это параметр цикла. Каких-либо дополнительных разъяснений не требуется.

Несомненно, к именованию переменных можно относиться гораздо серьезнее. Например, существует т.н. венгерская нотация. Эта концепция имеет множество вариантов, однако ее основная идея состоит в том, что каждое имя переменной должно начинаться с префикса, указывающего на тип этой переменной. (Например, все переменные типа unsigned long variable должны начинаться с префикса ul и т.д.). На мой взгляд, это уже перебор, однако вам надо знать о существовании и такого варианта. Можно потратить достаточно много времени на то, чтобы сделать вещи понятнее, однако решение этой задачи также требует определенных усилий.

Совет 4. Проверяйте свою программу на наличие ошибок. Вы ведь делаете ошибки. Да-да, именно вы.

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

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

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

Пока все идет нормально. Теперь задайте себе вопрос: «Что в этом коде может быть не так?»

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

Этот пример был достаточно простым. Существует и менее очевидная проблема (с которой я постоянно сталкиваюсь в своих играх). Что произойдет, если переменная num_points будет равна нулю?

Это весьма правдоподобная ситуация. Не забудьте, что по окончании каждой волны мы даем игроку бонусные баллы в зависимости от скорости ее прохождения. Что произойдет, если игрок будет действовать слишком медленно и мы решим дать ему 0 баллов? Вполне вероятно, что, работая над своим кодом в 3 часа ночи, вы решите вызвать процедуру change_score и передать ей значение 0.

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

Ну вот. Так гораздо лучше.

Обратите внимание, что это была очень простая функция. В ней совершенно отсутствуют всякие новомодные указатели, которые так любят использовать молодые лихие программисты. Если вы передаете массивы или указатели, вам ОБЯЗАТЕЛЬНО нужно предусмотреть выявление ошибок или плохих данных.

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

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

Совет 5. «Преждевременная оптимизация – корень всех зол», – Дональд Кнут (Donald Knuth).

Эту фразу придумал не я. Однако она есть в Википедии, и поэтому, по всей видимости, не лишена смысла.

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

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

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

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

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

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

И, наконец, раз уж мы заговорили о болезненном, вот мой завершающий совет:

Совет 6. Не умничайте.

Возможно, вы слышали о существовании мероприятия под названием International Obfuscated C Code Contest – международного конкурса по самому запутанному программному коду на языке C. Все дело в том, что языки C и C++, при всех своих преимуществах, позволяют создавать кошмарно запутанный код. Этот конкурс демонстрирует преимущества понятного кода «от противного» – посредством награждения самых безумных программистов. Отличная идея.

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

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

Каждый программист имеет свой допустимый уровень сложности создаваемого кода. Лично я пишу свои программы так, как водит машину типичная бабушка. На мой взгляд, если ваш код на C требует понимания тонких различий между выражениями i++ и ++i, то он слишком сложен.

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

Заключение

Возможно, дочитав до этого места, вы думаете: «И это все? Только зря потратил время. Это же очевидно и всем известно. Зачем автор все это писал?» Очень надеюсь, что вы думаете именно так. Значит, вы уже сами все знаете. Очень рад за вас.

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

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

Ресурсы для скачивания

Похожие темы

  • Оригинал статьи Six ways to write more comprehensible code: How to keep your code from destroying you.
  • Различные варианты венгерской нотацииописаны в Википедии.
  • Обратите внимание на профайлеры, перечисленные в Википедии. Как правило, для каждой среды разработки требуется свой профайлер. Изучение документации по вашей среде разработки поможет найти подходящий вариант.
  • Если вы любитель неподдерживаемого программного кода, рекомендую ознакомиться с победителями конкурса International Obfuscated C Code Contest.
  • Рекомендую также ознакомиться с другими советами по написанию удобного для поддержки программного кода: 9 советов от Брэма Кохена (Bram Cohen) (how to write maintainable code), 6 советов от Шона Келли (Sean Kelly) (more maintainable code) и 12 советов от Джоэла Сполски (Joel Spolsky) (12 steps to better code).
  • Примерно 100 иронических антисоветовв прекрасной работе Руди Грина (Roedy Green) «Как написать неподдерживаемый программный код» (юмористическая статья).
  • Ознакомьтесь с играми от автора статьи, и вы увидите его мудрость в ее реальном воплощении.
  • Ознакомьтесь с избранными работами автора, включая юмористические заметки, статьи по компьютерным играм и различные технические материалы.
  • В разделе Linux сайта developerWorks можно найти дополнительные ресурсы для Linux-разработчиков, включая руководства по Linux, а также самые популярные среди наших читателей статьи и руководства по Linux за последний месяц.
  • Используйте ознакомительные версии программных продуктов IBM, которые можно загрузить непосредственно с сайта developerWorks, в своем следующем проекте по разработке для Linux.

Комментарии

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

6 простых советов по написанию чистого кода

В этой рубрике Вы найдете уроки, которые относятся к теме создания сайта, но не попали ни в один раздел.

Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

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

Разработка веб-сайтов с помощью онлайн платформы Wrike

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

Мастер Йода рекомендует:  Безопасность и анонимность в Интернете

20 ресурсов для прототипирования

Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Топ 10 бесплатных хостингов

Небольшая подборка провайдеров бесплатного хостинга с подробным описанием.

Быстрая заметка: массовый UPDATE в MySQL

Ни для кого не секрет как в MySQL реализовать массовый INSERT, а вот с UPDATE-ом могут возникнуть сложности. Чтобы не прибегать к манипуляциям события ON_DUPLICATE можно воспользоваться специальной конструкцией CASE … WHEN … THEN.

Распознавание текста из изображений через командную строку

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

HTTPie — удобный инструмент похожий на cURL

cURL — это самый известный инструмент для отправки HTTP запросов из командной строки. В этом уроке мы познакомим вас с более удобным аналогом, который называется HTTPie.

Руководство по написанию чистого и читабельного кода для начинающих разработчиков. Часть 1

Написание чистого и читабельного кода — непростая задача, но данное краткое руководство поможет вам овладеть этим искусством.

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

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

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

  1. Целенаправленность — каждая функция, каждый класс и модуль выполняют определенное действие.
  2. Элегантность — чистый код легко прочитать, и он максимально понятен.
  3. Чистый код требует внимания. Для создания простоты и порядка нужно время и внимание к деталям.
  4. Чистый код проходит все тестирования. Плохой код не является чистым!

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

Используйте форматирование и отступы последовательно

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

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

Хороший пример

  • С первого взгляда понятно, что заявление if/else находится в функции.
  • Благодаря скобкам и последовательным отступам видно, где начинаются и заканчиваются блоки кода.
  • Скобки последовательны — открывающие скобки для function и if находятся на одной линии.

Плохой пример

Кошмар! Практически все неправильно.

  • Повсюду отступы — невозможно определить, где заканчивается функция и начинается блок if/else (да, там есть блок if/else!).
  • Скобки расставлены непоследовательно.
  • Межстрочный интервал тоже непоследовательный.

Пример немного преувеличен, однако показывает преимущества использования последовательных отступов и форматирования. “Хороший” пример гораздо легче прочитать!

Приятные новости: есть множество плагинов для IDE, с помощью которых можно автоматически форматировать код.

Используйте понятные названия переменных и методов

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

Этот фрагмент кода хорош по следующим причинам:


  • Названия функций и аргументов максимально понятны. При прочтении кода становится ясно, что при вызове метода getStudentName() с studentId будет возвращено имя студента. В таком случае не придется переходить к методу getStudentName() без необходимости!
  • Названия вызовов переменных и методов в getStudentName() также максимально ясны — метод вызывает api , получает объект student и возвращает свойство name . Все просто!

При росте приложения используйте следующие советы для улучшения читабельности кода:

  • Выберите стиль названий и будьте последовательны. Либо camelCase , либо under_scores , но не оба!
  • Названия функций, методов и переменных должны соответствовать тому действию, которое они выполняют. Например, если метод получает что-либо, то используйте get в названии. Или если переменная хранит цвет машины, то назовите ее carColour .

БОНУС: если название функции или метода трудно подобрать, то она выполняет слишком много действий. Разделите ее на несколько функций! Например, если функция называется updateCarAndSave() , то создайте два метода: updateCar() и saveCar() .

При необходимости используйте комментарии

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

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

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

Рассмотрим несколько примеров комментариев, которых стоит избегать.

Излишние комментарии, не добавляющие значения:

6 простых советов о том, как писать чистый код

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

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Поиск

uWebDesign настоятельно рекомендует!

Темы к ближайшему подкасту (6 комментариев)

Предлагайте свои темы для выпуска #214 в комментариях!

6 простых советов по написанию чистого кода. #[email protected]

Шесть простых советов по написанию чистого кода

Статья посвящена довольно простым и очевидным советам по написанию чистого кода, однако не все так просто! Прочти и убедись в этом сам!

Комментарии (9)

Дмитрий Брин

О да, код-стайл WordPress с пробелами после каждого символа – очень хорошая иллюстрация чистого кода. Нет.

Вадим Бобров

Пожскажите может кто знает какая это color schema на картинке ?

Денис Марченко

Спасибо за советы

Станислав Жолобов

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

Роман Щёголев

Мудрить не надо, комментировать надо. Чистый код я видел только в книге «Чистый код». Идеалисты, мамкины кодеры-теоретики.

5 способов повышения качества кода

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

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

А пока вы выискиваете на это время, позвольте тезисно рассказать о 5 основных заповедях создания превосходного кода:

Использование линтера

Линтер – утилита для проверки код на соответствие стандартам и спецификациям языка. К примеру, для Python он существует в виде пакета Pylint, для JavaScript – ESHint, для Java – FindBugs и т.д.

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

На практике же стиль кода и стандарты языка часто являются основой для создания надёжного кода, который легко читается и правится, а главное – работает. А ведь именно это — цель разработки.

Контроль разработки

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

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

Создание чёткого кода

На GeekBrains неоднократно выходили статьи с рекомендациями по оформлению качественного кода. Они сводятся к 4 основным пунктам:

  • Умеренное комментирование.
  • Правильные имена.
  • Ограничение объёма блоков.
  • Чёткая структура кода.

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

А вот названия функций и переменных должны делать конкретную строку кода понятной для других разработчиков. При этом длина должна укладываться в разумные пределы: в зависимости от языка предел составляет 15-25 символов. Если ваше имя больше – потратьте ещё 30 секунд на обдумывание.

Следить также следует за длиной функций и циклов. К примеру, Google C++ Style Guide рекомендует ограничение в 40 строк, всё, что больше – лучше разбить на более мелкие части. Цифра здесь – ориентир, главное – сохранить читаемость кода. Если разбиение 100 строк кода на 5 логических блоков пойдёт только во вред – лучше оставить как есть.

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

Тестирование кода

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

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

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

Обзор кода

Финальная стадия проверки качества кода, которая даже не входит в системы непрерывной интеграции. Алгоритм простой:

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

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

Вы следите за качеством своего кода?

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

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

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

А пока вы выискиваете на это время, позвольте тезисно рассказать о 5 основных заповедях создания превосходного кода:

Использование линтера

Линтер – утилита для проверки код на соответствие стандартам и спецификациям языка. К примеру, для Python он существует в виде пакета Pylint, для JavaScript – ESHint, для Java – FindBugs и т.д.

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

На практике же стиль кода и стандарты языка часто являются основой для создания надёжного кода, который легко читается и правится, а главное – работает. А ведь именно это — цель разработки.

Контроль разработки

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

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

Создание чёткого кода

На GeekBrains неоднократно выходили статьи с рекомендациями по оформлению качественного кода. Они сводятся к 4 основным пунктам:

  • Умеренное комментирование.
  • Правильные имена.
  • Ограничение объёма блоков.
  • Чёткая структура кода.

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

А вот названия функций и переменных должны делать конкретную строку кода понятной для других разработчиков. При этом длина должна укладываться в разумные пределы: в зависимости от языка предел составляет 15-25 символов. Если ваше имя больше – потратьте ещё 30 секунд на обдумывание.

Следить также следует за длиной функций и циклов. К примеру, Google C++ Style Guide рекомендует ограничение в 40 строк, всё, что больше – лучше разбить на более мелкие части. Цифра здесь – ориентир, главное – сохранить читаемость кода. Если разбиение 100 строк кода на 5 логических блоков пойдёт только во вред – лучше оставить как есть.

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

Тестирование кода

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

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

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

Обзор кода

Финальная стадия проверки качества кода, которая даже не входит в системы непрерывной интеграции. Алгоритм простой:

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

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

5 Игр, чтобы научиться писать код

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

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

Мастер Йода рекомендует:  SQL универсальный язык для работы с базами данных

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

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

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

Это удивительное пространство, где программисты могут практиковать свои навыки разработки, чтобы увидеть, насколько хорошо они развиваются. Игра поддерживает JavaScript, Python, PHP, Java, Ruby и другие популярные языки программирования, используемые сегодня. Это бесплатная онлайн платформа кодирования, которая доступна для всех, кто имеет интерес к программированию. Вы можете создавать новую сессию вашей практики каждый раз, когда вы входите в игру. Это отличный способ, чтобы практиковать программирование, параллельно получая удовольствие от самой игры.

Это платформа, которая предоставляет учащимся возможность освоить некоторые компьютерные науки, наслаждаясь веселым препровождением времени, играя в настоящую игру. Это целое сообщество, участники которого вызвались добровольно создавать уровни, через которые игроки должны пройти. Игра предлагает поддержку Java, JavaScript, Coffee Script, Lua и Python. В игре, вы научитесь программировать с помощью живой мульти-пользовательской стратегии кодирования. Это отличный способ для новичков, чтобы начать. The code combat до сих пор известен, как самая увлекательная игра для тех, кто хочет научиться программированию. Хорошая новость заключается в том, что платформа является доступной для каждого, поэтому нет никаких ограничений относительно того, кто может обучаться кодированию.

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

10 правил написания чистого кода

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

Для того, чтобы код выглядел чистым (что по сути обеспечивает нормальную работу в команде), нужно следовать нескольким простым правилам, которыми никогда не нужно пренебрегать.

Пишем красивый и чистый программный код

1. Тщательно продумайте логику, перед тем как начать кодить

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

2. Чётко обозначьте для себя структуру вашей страницы

Работать с определёнными контейнерами очень удобно, но ещё более удобно работать с контейнерами, у которых есть определённые ID. Предположим, что мы имеем дело со следующим фрагментом кода:

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

3. Используйте понятные идентификаторы

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

4. Пишите краткие и понятные комментарии

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

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

5. Используйте комментарии без фанатизма

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

  • Написание комментариев для себя (пример: /* Закончу как-нибудь потом. */).
  • Отвод глаз от себя (пример: /* это писал Johns.С него и спрос. */).
  • Ни о чём не говорящие выражения (e.g. /* Это очередная математическая функция. */).
  • Также иногда люди не уверены в какой-то функциональности и просто комментируют фрагмент кода.

Данные комментарии бессмыслены и могут ввести человека в заблуждение. У каждого комментария должен быть свой смысл. Никогда не забывайте об этом

Примеры хороших комментариев:

  • Спецификация автора (пример: /* Автор John, 13 Ноября 2010 */).
  • Какая-то детализация метода или процедуры (пример: /* Данный метод предназначен для валидации формы входа пользователя в систему */).
  • Быстрые заметки или описание изменений в коде (e.g. /* Добавлена валидация e-mail */).

6. Не пишите слишком большие методы

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

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

7. Используйте стандарты именования переменных и функций

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

Существует немало компаний, в которых узаконены свои собственные стандарты именования методов и переменных (пример: префикс ‘int_’ для всех переменных данного типа), но также наравне с ними существует масса компаний где вообще нет никаких стандартов. Из-за своей лени работники данных компаний часто делают одну и ту же работу вдвое дольше. Как вы думаете? Это нормально?

8. Осторожно производите все изменения

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

Так же необходимо учитывать следующее:

  • Сохраняйте код читабельным (пример: если вы добавляете условный оператор IF, то обратите внимание на форматирование кода).
  • Создавайте дополнительные комменты.
  • Уважайте стандарты, согласно которым был написан данный метод.

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

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

10. Ограничивайте импорт файлов

Это конечно хорошо, когда функциональность разбита на несколько файлов, но тут всё тоже должно быть в меру. Если у вас есть несколько файлов с таблицами стилей их можно и даже нужно объединить в один.

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

Время действовать

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

20 самых рекомендуемых книг для программистов на русском языке

Авторы проекта Dev-Books проанализировали миллионы вопросов и ответов в крупнейшем сообществе программистов Stack Overflow. Всё для того, чтобы найти книги, на которые чаще всего ссылаются разработчики.

В общий список вошло 5 720 книг. Ниже вы найдёте 20 самых упоминаемых из них, которые когда-либо выходили на русском.

По просьбе Лайфхакера своими мнениями насчёт некоторых изданий поделились отечественные эксперты.

1. «Эффективная работа с унаследованным кодом», Майкл К. Физерс

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

2. «Приёмы объектно-ориентированного проектирования. Паттерны проектирования», Эрих Гамма и другие

Классика для программиста. Первая книга, посвящённая именно шаблонам.

Леонид Выговский, системный архитектор IT-компании LiveTex

— Издание уже 20 лет переиздаётся в изначальном виде. В этом, конечно, главный недостаток книги: некоторые шаблоны уже неактуальны. Думаю, её полезно читать уже после других, более современных, книг по паттернам проектирования. Тем более что она написана сухим академическим языком. Для понимания паттернов эта книга не must read, но её прочтение добавляет крутости в глазах коллег-программистов. 🙂 Начинать я советую с «Паттернов проектирования» (Head First Design Patterns).

3. «Чистый код. Создание, анализ и рефакторинг», Роберт К. Мартин

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

Леонид Выговский, системный архитектор IT-компании LiveTex

— Почему спорная? Книг про написание кода уже огромное количество, и часть приёмов являются общепризнанными. Но каждый автор добавляет что-то своё. Лично для меня мнение Боба Мартина кажется иногда странным и противоречащим другим источникам. Не must read, но прочитать всё же стоит. Качество кода после прочтения становится лучше.

4. «Предметно-ориентированное проектирование», Эрик Эванс

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

Леонид Выговский, системный архитектор IT-компании LiveTex

— Из этой книги выросли концепции СQRS, BDD, onion-architecture и много других интересных идей. Единственный недостаток: книга насквозь теоретическая. Практическую пользу она приобрела только с выходом книги Вона Вернона «Реализация методов предметно-ориентированного проектирования» (Implementing Domain Driven Design). Поэтому читать их надо последовательно, сразу друг за другом.

5. «JavaScript: сильные стороны», Дуглас Крокфорд

Обязательная книга для веб-разработчиков. В ней Дуглас Крокфорд рассказывает о преимуществах языка JavaScript и учит грамотно их применять для создания эффективного кода.

6. «Шаблоны корпоративных приложений», Мартин Фаулер и другие

Книга описывает базовые принципы проектирования ПО для корпоративных платформ.

7. «Совершенный код. Мастер-класс», Стив Макконнелл

Классическая книга о том, как писать код лучше.

Михаил Осотов, директор по производству «Центра высоких технологий»

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

8. «Рефакторинг. Улучшение существующего кода», Мартин Фаулер и другие

Из серии книг по написанию понятного и качественного кода, «Рефакторинг» — лучшая.

Леонид Выговский, системный архитектор IT-компании LiveTex

Выговский: «Она не только показывает хороший код, но и на примере плохого объясняет, чем именно он плох. Эта книга — must read для всех. Причём чем раньше вы её прочтёте, тем лучше. Качество кода после прочтения сильно вырастет».

Если книгу Фаулера вы уже прочли, обратите внимание на «Рефакторинг с использованием шаблонов» (Refactoring to Patterns) Джошуа Кериевски, которую рекомендует Михаил Осотов.

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

Михаил Осотов, директор по производству «Центра высоких технологий»

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

9. «Паттерны проектирования», Эрик Фримен, Элизабет Фримен и другие

Серия Head First, на мой взгляд, идеально подходит для новичков в области разработки ПО.

Михаил Осотов, директор по производству «Центра высоких технологий»

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

10. «Язык программирования C», Брайан У. Керниган, Деннис М. Ритчи

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

11. «Эффективное использование С++. 55 верных способов улучшить структуру и код ваших программ», Скотт Майерс

Книга содержит советы по проектированию программ, работе с шаблонами и управлению ресурсами, а также другие рекомендации по созданию качественного ПО на языке С++.

12. «Экстремальное программирование: разработка через тестирование», Кент Бек

Автор на примерах описывает методику разработки ПО, которая предполагает тестирование программ ещё до написания их кода.

13. «Алгоритмы. Построение и анализ», Томас Х. Кормен и другие

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

14. «Регулярные выражения», Джеффри Фридл

Издание об эффективной работе с текстом в Perl, PHP, Java, Python, Ruby и других языках программирования.

15. «CLR via C#. Программирование на платформе Microsoft.NET Framework 4.5 на языке C#», Джеффри Рихтер

Классический учебник по разработке приложений для платформы Microsoft, в том числе с помощью Silverlight, Windows Presentation Foundation, ASP.NET и прочих технологий компании.

16. «Современное проектирование на C++», Андрей Александреску

Книга для опытных программистов на C++. Автор предлагает новый подход к разработке, сочетающий метапрограммирование шаблонов, обобщённое программирование и объектно-ориентированное программирование на этом языке.

17. «Microsoft ASP.NET 2.0. Базовый курс», Дино Эспозито

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

18. «Шаблоны тестирования xUnit. Рефакторинг кода тестов», Джерард Месарош

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

19. «Компиляторы. Принципы, технологии и инструментарий», Альфред В. Ахо и другие

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

20. «Инфраструктура программных проектов. Соглашения, идиомы и шаблоны для многократно используемых библиотек .NET», Кржиштоф Цвалина, Брэд Абрамс

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

Полный рейтинг англоязычных книг доступен на сайте Dev-Books. Там же можно просмотреть списки самых популярных книг на определённые темы, будь то Java, Database Design или CSS.

Добавить комментарий