Написание комментариев к коду — очень хорошая практика, но ее можно избежать, когда в действительности это не требуется. Хороший код всегда говорит сам за себя.
Я на самом деле очень боюсь, когда дело доходит до исправления какой-то ошибки в коде, написанном не мной. Мне становится очень трудно понять фрагмент кода, очевидно, потому что он написан не мной.
Но несколько дней назад я наткнулся на кодовую базу, где код был очень читаемым, и я смог очень быстро исправить ошибку. Кодекс был весьма замечательным. Очень мало комментариев, но код не требует пояснений Кодирование — прекрасная вещь, если вы видите. Быть разработчиком означает, что мы должны читать код, писать код или вносить изменения в существующий код. Если мы не понимаем код, становится очень неловко, так как это снижает нашу эффективность и производительность. Давайте сделаем несколько ритуалов, пока вы читаете этот пост, и следуйте ему для достижения наилучших результатов.
Говоря о моем опыте, худшее, что я испытал, это код, который закомментирован. Я имею в виду, почему мы хотим закомментировать код, а не удалить его?
Мы все используем контроль версий для нашего кода, чтобы отслеживать изменения или сделанные правки. Тем не менее, мы комментируем код, а не удаляем его. Давайте доверимся системе контроля версий и сделаем наш код максимально чистым.
Представьте себе такой код:
if( sunRisen) {
// washClothes();
// dryClothes();
// wrapClothers();
manageClothes();
} else {
donothing();
}Зачем нужен закомментированный код, если он бесполезен. Это просто пустая трата строки и размера кода.
Ритуал 1:
Давайте сделаем ритуал, чтобы удалить ненужный код и не комментировать его перед фиксацией нашего кода.
if( sunRisen) { manageClothes(); } else { donothing(); }Это выглядит намного лучше.
Ритуал 2:
Давайте сделаем ритуал, чтобы добавить префикс //FIXME or //TODO к нашему комментарию, чтобы о нем позаботились.
Иногда нам приходится аннотировать проблему или аннотировать решение. Наряду с этим было бы здорово, если бы для них был создан тикет.
createBreakfast(config) {
// TODO: need to pass an optional param for type of salt (white or pink)
const foodPrepared = return startCooking(config);
return foodPrepared;
}Ритуал 3:
Давайте возьмем за правило не писать комментарии к коду, если код уже понятен.
// to check if warning modal should be shown or not shouldShowWarningModal(){
return !this.isModalSeen && !this.isValidUser;
}Комментарий здесь бесполезен, поскольку само название функции говорит само за себя. Самодокументированный и понятный код — это магия. Выбирайте имя функции и имя переменной с умом.
Ритуал 4:
Давайте возьмем за правило объяснять наш код только тогда, когда это необходимо, и это вполне возможно, используя наименьшее количество слов. Примечание. Начинайте комментарий с пробела, чтобы его было удобнее читать. Подробнее читайте: spaced-comment
function getName() {
// set the default name to 'no name'
const name = this.name || 'no name';
return name;
}Ритуал 5:
Давайте сделаем ритуал, чтобы следовать стандартной практике, чтобы однажды, когда кто-то прочитает наш код, он легко его понял. Всегда легко указать на ошибки в чужом коде, но очень трудно следовать хорошим практикам. себя.
Окончание на позитивной ноте, поскольку это личный выбор, писать или не писать комментарии. Моей целью было сказать, что в коде тоже есть эмоции и чувства. Давайте поможем коду отображать свои эмоции и не всегда их комментировать. :)
Первоначально опубликовано на https://www.simranraj.in.
