Наверное, самое сложное для разработчика — погрузиться в чужой код и начать в нем работать. Код другого разработчика всегда пугает, но вот несколько советов, как сделать его менее пугающим для ваших коллег.
Уважайте отступы друг друга
Одна из вещей, которая действительно вызывает у меня обсессивно-компульсивное расстройство, — это когда в проекте используются несколько типов отступов. Реальность такова, что у каждого есть свое мнение о том, как следует располагать отступы.
Может быть трудно прийти к единому мнению относительно отступов, но вы можете улучшить ситуацию, включив файл .editorconfig. Здесь вы можете указать правила отступов для каждого типа файлов. Большинство IDE либо поддерживают это, либо имеют для этого плагины (включая Sublime Text, Visual Studio Code и т. д.).
Создайте файл .editorconfig при запуске проекта. Когда вы входите в существующий проект, уважайте .editorconfig, который определил ваш коллега!
Не делайте имена переменных слишком широкими
Придумать хорошие имена переменных сложно. Я иногда даже шучу, что это самая сложная часть моей работы. Но, пожалуйста, не пугайтесь этого! Наличие хороших имен переменных может иметь ключевое значение.
Часто легко выбрать слишком широкое имя переменной. Старайтесь избегать использования таких имен, как «элемент», «результаты», «значение». Вместо этого назовите, что в нем.
Оставайтесь сухим
Dне Rповторяйте Y себя! Это то, что вы слышали тысячу раз, но это так важно. Не пишите одни и те же 5 строк кода 5 раз в своем проекте, это сделает код трудным для чтения, и это ужасно для ремонтопригодности.
Если вы чувствуете дежа вю при кодировании, вам, вероятно, следует сделать шаг назад и посмотреть, не сможете ли вы провести рефакторинг.
Не используйте аббревиатуры, когда они вам не нужны
Еще одна ловушка при именовании переменных — использование для них акронимов. Во время написания для вас может быть очевидно, что означает эта аббревиатура, но не стоит недооценивать, насколько сложно вашему коллеге понять ее.
Каждая секунда, потраченная на попытки понять что-то, что могло бы быть более очевидным, — это секунда, когда вы или ваш коллега отвлекаетесь от понимания важной части вашего кода.
Не оставляйте вещи в комментариях
Вы все были там, вы читаете какой-то старый код и какой-то (иногда кажущийся важным) фрагмент кода находится в комментариях. В вашей голове крутится множество вопросов: «почему это в комментариях?», «как это может работать, когда эта часть в комментариях?», «нам это когда-нибудь еще понадобится?».
Для меня есть простое правило: никогда не коммитить закомментированный код. Я также довольно жесток, когда вижу какой-то код с комментариями, так как часто просто удаляю его, потому что это только запутает меня и любого, кто попытается его прочитать.
Но что, если вам снова понадобится этот закомментированный код? Ну, у вас есть контроль версий для этого!
Создавайте хорошие комментарии
Вместо того, чтобы размещать код в комментариях, вы должны сосредоточиться на написании комментариев, которые помогут вашим коллегам и вашему будущему «я» понять код, который вы написали.
Обычно я стараюсь соблюдать два правила:
- Не стоит недооценивать, насколько сложно понять этот фрагмент кода.
- Будьте кратки, разработчики ленивы и быстро пропускают большие блоки текста.
Сложно ли описать происходящее в 1-2 предложениях? Тогда ваша функция может быть слишком большой, и вам следует подумать о рефакторинге.
Вам нужна помощь с кодированием? "Давайте поговорим!" Будем рады помочь.
