Хорошо написанный код = счастливые клиенты, разработчики, менеджеры, пользователи ...

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

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

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

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

Не пишите код, который вам не нужен

Мо код, МО проблем.

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

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

Используйте согласованные стили кода

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

Посмотрим правде в глаза, это раздражает:

if (hour < 18) {
greeting = "Good day";
}else 
{
greeting = "Good evening";
}

Как w3.org справедливо упоминает:

Браузеры очень снисходительны к синтаксису JavaScript. Однако это не должно быть причиной для написания небрежного кода, который полагается на браузеры для его работы.

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

Для Python руководство по стилю PEP8, вероятно, является наиболее удобным и предлагает удобный инструмент командной строки, чтобы вы могли протестировать свои файлы Python.

Структура файлов и папок

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

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

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

СУХОЙ - Не повторяйся

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

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

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

Как я уже сказал ранее, Мо-код, Мо-проблемы.

Модулируйте свой код

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

Небольшие фрагменты кода легче понять и отладить.

Пишите в защитной манере.

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

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

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

Инженер по тестированию заходит в бар.

Заказывает пиво. Заказов 0 бутылок пива. Заказывает 99999999999 бокалов пива. Заказывает ящерицу. Заказывает -1 бокал пива. Заказывает ueicbksjdhd.

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

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

Каждый раз, когда я вижу файл, заполненный такими переменными, как i, j, k, abc и т. Д., Я закрываю свой редактор и избегаю этого файла, как чумы.

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

Также не переусердствуйте и назовите переменную aVeryMeaningfulButExtremelyLongNameForThisVariable.

Это не ракетостроение

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

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

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

Прокомментируйте свой код!

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

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

Заключение

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

Удачного кодирования! ❤️