О профессионализме программиста можно судить на основании нескольких факторов, что присутствуют в коде: правильные имена переменных и конструкций, логическое выполнение делений на разделы, простые способы решения сложных задач, наличие удобной структуры и комментарии к основным функциям. На счет последнего фактора есть некоторые сомнения, так как комментарии не всегда свидетельствуют о профессиональных навыках. Для новичков это может стать проблемой, что мешает развиваться. Теперь ближе к сути.
Кому и зачем нужны комментарии
Всего комментирование кода выполняет 4 основные задачи:
Простая навигация. Весьма часто приходится находить и устранять ошибки в коде, с помощью навигации проще найти блок, что занимается обработкой нужного направления. Особенно сложно, если программа другого разработчика;
Изъяснение кода. Когда используются специфические функции со сложными математическими, химическими или другими формулами. Даже хороший специалист может не знать специфику какого-либо направления;
Описание всего кода в целом. Используется при формировании больших объёмов данных, например, библиотек, расширений и практически во всех сферах программирования с общедоступным кодом;
Описание ожидаемого результата функции. В этом случае комментарии используются для отладки кода и проверки результата.
Чем плохо
Ещё в далеком 2008 году впервые зазвучали идеи в отношении кода без комментариев. Первым сформулировал идею Роберт Мартин в своей книге «Чистый код». В издании было приведено множество вариантов оптимизации написанного года, среди них указывалась идея полного отказа от системы комментирования. Мнение Мартина сводилось к тому, что код часто ограничивает разработчика в выражении собственных идей. Из-за использования комментариев многие программисты не занимаются оптимизацией и структурированием кода.
Для примера приведём ситуацию: рядом со всеми функциями, что выполняют последовательные действия, устанавливаются комментарии только из-за банальной скуки разработчика или неправильного написания/оформления кода. В противном случае необходимость в комментариях и не возникла бы.
Что делать
Полностью выражаться против комментариев мы не будем, так как это является важной частью кода, но их количество должно быть небольшим и обоснованным. Комментарии призваны только сделать код более читабельным.
Приступим к занятиям, первым будет полный отказ от подписей, которые располагаются правее от кода. Не нужно просто удалять комментарии, так вы ничему не научитесь. Удаляя подписи постарайтесь сделать так, чтобы читаемость и информативность от этого не пострадала. Использование многострочных комментариев допустимо, они выполняют лишь роль навигации. Методика призвана:
Выполнить оценку качества и внятности написанного кода;
Помочь выявить множество комментариев, что абсолютно бесполезны;
Найти способы достижения оптимизации написанного кода, при этом упростив его для понимания;
Научить правильно оформлять работы, уместно расставляя пробелы, отступы и табуляции.
Если возможность пояснения отпадает как минимум появляется необходимость давать смысловые названия переменным и объектам, что уже станет шагом в развитии программиста.
Рассмотрим на простом примере: при составлении анкеты на любом сайте требуется правильное введение данных, если заполнение неверное, дальше алгоритм не пропустит. При обнаружении мест с ошибками появляется подсветка красным. Лучший способ реализовать эту систему посредством кода – применить флаги. Собственный опыт подсказывает частое использование имён:
flag_2;
surnameField;
validatedSurname.
В первом случае очевидно, что работает совсем «зелёный» специалист. Такое имя не должно быть в коде даже при наличии множества комментариев. В остальных случаях имена допустимы, но они вырваны из контекста, то есть программист не получает четкого ответа сразу после чтения имени.
if (validatedSurname != null)
Чтобы понять, какое условие исполняется, и что произойдёт придётся читать следующие стройки, вернуться немного назад и только тогда становится понятно, что эта переменная является флагом для заполнения поля. Повторим, запись относится к допустимым, но скорее для небольшого кода, где текста всего-то 5-6 строчек. Если код заполняет десятки списанных листов, то имён, где используется приставка Surname может быть достаточно много. Лучше обозначить имя более ясно, используя конкретику.
Следующее упражнение – это переписывание кода сначала, только с использованием предельно возможного наследования и правил инкапсуляции. Если ваш язык программирование не объектно-ориентированный, попробуйте создать схожую структуру при помощи манипуляции в именах. Пример: FormSurname, FormSurnameActionTrue, FormSurnameActionFailed, FormSurnameFieldCorrectly, FormSurnameFieldCorrectlyBoxShadow и подобное. Нельзя назвать такой код слишком удобным для чтения, но в качестве тренировки манипуляция подходит отлично.
И всё же без комментариев никуда
Отлаженный, структурированный код с комментариями – это предельно удобная работа с программой на протяжении всего периода отладки. Комментарии помогут сделать код легко читаемым, улучшат навигацию по документу, сделают код доступным для другого разработчика. Злом их можно назвать только в случае объяснения написанного кода, когда программист пренебрегает правильной структурой в пользу разъяснения действий. Это ничто иное как костыли, которые лишь прикрывают недобросовестно написанный код. Выкиньте костыли и сможете покорить Эверест в программировании значительно быстрее.