«Комментировать или не комментировать, вот в чем вопрос"
Хорошие комментарии могут улучшить читабельность и удобство сопровождения кода, тем самым улучшая качество кода.
Так что же такое хорошие аннотации? Как писать хорошие комментарии? В этой статье мы обсудим аннотации JS с точки зрения назначения и принципов аннотаций.
01 Назначение и принципы аннотации
Цель аннотации:
Улучшить читаемость кода и, следовательно, его ремонтопригодность
Принципы аннотации:
Не добавлять комментарии, если в этом нет необходимости (как можно короче)
Сколь угодно долго
Мы должны стремиться к «самомкомментарию кода», то есть сам код имеет высокую читабельность (за счет четкого именования, разумной структуры и т. д.). Например:
// bad
// 如果已经准备好数据,就渲染表格
if (data.success && data.result.length > 0) {
renderTable(data);
}
// good
const isTableDataReady = data.success && data.result.length > 0;
if (isTableDataReady) {
renderTable(data);
}
«Будьте настолько подробны, насколько это необходимо»Это означает, что места, которые необходимо комментировать, должны быть написаны максимально подробно, чтобы читатели могли полностью понять логику и намерение кода как стандарта.
02 Что такое хорошие комментарии и что такое плохие комментарии
Согласно принципу комментариев, мы должны судить о том, является ли комментарий «необходимым», исходя из того, «может ли он помочь читателям лучше читать и понимать код».
Хорошие заметки включают в себя:
Помогите читателям лучше понять логику и структуру кода, например:
init: function() {
// 获取配置信息
const config = getConfig();
// 获取用户信息
const userInfo = getUserInfo();
// 根据配置和用户信息,进行初始化
doInit(config, userInfo);
// 如果存在自定义配置时的特殊逻辑
if (config.custom) {
...
}
}
Специальные или трудные для понимания пояснения, такие как:
/**
* parseInt was the reason my code was slow.
* Bitshifting the String to coerce it to a
* Number made it a lot faster.
*/
const val = inputValue >> 0;
Примечания к специальным меткам: метки со специальными значениями, такие как TODO, FIXME и т. д.
Примечания к файлу: некоторые правила требуют, чтобы в начале файла была написана примечание фиксированного формата, например, автор, соглашение и другая информация.
Комментарии класса документации: часть соглашений использует комментарии класса документации (например, стиль jsdoc) для API, классов, функций и т. д.
Следуйте унифицированным спецификациям стиля, таким как определенные пробелы и пустые строки, чтобы обеспечить удобочитаемость самих комментариев.
К плохим комментариям относятся:
Комментарии бесполезны для чтения кода: как и в первом примере в этой статье, вы можете использовать четкие имена и логику для самоаннотирования кода без комментариев.
Не соответствует единой спецификации стиля: такой как длина однострочного комментария, пробелы, пустые строки, например:
// bad 单行注释过长,不易阅读,应写成多行
// parseInt was the reason my code was slow.Bitshifting the String to coerce it to Number made it a lot faster.
const val = inputValue >> 0;
// good
/**
* parseInt was the reason my code was slow.
* Bitshifting the String to coerce it to a
* Number made it a lot faster.
*/
const val = inputValue >> 0;
Эмоциональные ноты: такие как жалобы, дискриминация, забавные вещи и т. д. (вы встаете на колени, когда вас находят)
03 Как писать хорошие заметки
Спецификация аннотации
Понимать цель и принципы аннотаций, а также разрабатывать и соблюдать спецификацию аннотаций, чтобы обеспечить удобочитаемость и согласованность аннотаций.
Гарантия на инструмент
Например, используйте ESLint, чтобы обеспечить согласованность стиля аннотаций, и используйте Sonar, чтобы проверить скорость аннотирования проекта.
04 Протокол аннотаций
4.1 [Рекомендуется] Используйте однострочные комментарии//
Комментарии должны быть написаны на одной строке над аннотируемым объектом, а не после оператора:
// bad
const active = true; // is current tab
// good
// is current tab
const active = true;
Пустая строка требуется над строкой комментария (если только строка комментария не находится над верхней частью блока) для удобочитаемости:
// bad
function getType() {
console.log('fetching type...');
// set the default type to 'no type'
const type = this.type || 'no type';
return type;
}
// good
function getType() {
console.log('fetching type...');
// set the default type to 'no type'
const type = this.type || 'no type';
return type;
}
// good
// 注释行上面是一个块的顶部时不需要空行
function getType() {
// set the default type to 'no type'
const type = this.type || 'no type';
return type;
}
4.2 [Рекомендуется] Использование многострочных комментариев/** ... */
, вместо многострочного//
// bad
// make() returns a new element
// based on the passed in tag name
function make(tag) {
// ...
return element;
}
// good
/**
* make() returns a new element
* based on the passed-in tag name
*/
function make(tag) {
// ...
return element;
}
4.3 [Обязательно] Между содержимым комментария и символом комментария должен быть пробел для повышения удобочитаемости. эслинт:spaced-comment
// bad
//is current tab
const active = true;
// good
// is current tab
const active = true;
// bad
/**
*make() returns a new element
*based on the passed-in tag name
*/
function make(tag) {
// ...
return element;
}
// good
/**
* make() returns a new element
* based on the passed-in tag name
*/
function make(tag) {
// ...
return element;
}
4.4 [Рекомендуется] Использовать специальный значок комментария
Иногда мы находим возможную ошибку, которую по какой-то причине нельзя исправить, или где-то еще нужно сделать какую-то фичу, тогда нам нужно сообщить будущему себе или соавторам соответствующей специальной маркерной аннотацией. Обычно используются два типа специальных тегов:
// FIXME: укажите, в чем проблема
// TODO: указать, что еще нужно сделать или решение проблемы
class Calculator extends Abacus {
constructor() {
super();
// FIXME: shouldn’t use a global here
total = 0;
// TODO: total should be configurable by an options param
this.total = 0;
}
}
4.5 [Рекомендуется] В комментариях к классам документов, таким как функции, классы, файлы, события и т. д., используйте спецификацию jsdoc.
Например:
/**
* Book类,代表一个书本.
* @constructor
* @param {string} title - 书本的标题.
* @param {string} author - 书本的作者.
*/
function Book(title, author) {
this.title=title;
this.author=author;
}
Book.prototype={
/**
* 获取书本的标题
* @returns {string|*}
*/
getTitle:function(){
return this.title;
},
/**
* 设置书本的页数
* @param pageNum {number} 页数
*/
setPageNum:function(pageNum){
this.pageNum=pageNum;
}
};
05 Инструменты
Мы можем использовать некоторые инструменты для обеспечения качества аннотаций, такие как:
Эслинт: гарантированный последовательный стиль комментирования
ESLint — самый популярный инструмент проверки кода JS.В ESLint есть несколько правил, связанных с аннотациями, которые пользователи могут открыть:valid-jsdoc
require-jsdoc
no-warning-comments
capitalized-comments
line-comment-position
lines-around-comment
multiline-comment-style
no-inline-comments
spaced-comment
Sonar: проверьте скорость аннотации проекта
Sonar — это платформа непрерывной интеграции кода, которая может статически сканировать код для получения данных о скорости аннотирования проекта.
Уровень комментариев отражает долю закомментированных строк в общем количестве строк кода. Слишком низкий уровень комментариев не является хорошим, но невозможно слепо следовать высокому уровню комментариев.
Кроме того, как и в Eslint, в Sonar также есть некоторые настраиваемые правила стиля аннотаций.
06 Постскриптум
Понимание цели и принципов аннотаций, соблюдение спецификации аннотаций и объединение инструментов для обеспечения реализации могут сделать аннотации хорошим подспорьем в коде, улучшить читаемость и удобство сопровождения, а также улучшить качество кода.
Эта статья является первой из серии статей о качестве внешнего кода. В последующих сериях также будут обсуждаться такие темы, как соглашения о написании кода, сложность и частота повторения, так что следите за обновлениями :)
Ссылки на части этой статьи и примеры кода:
спецификация аннотации aralejs https://github.com/aralejs/aralejs.github.io/wiki/JavaScript-аннотация спецификация
Спецификация кодирования airbnb https://github.com/airbnb/javascript#comments
http://zh-google-styleguide.readthedocs.io/en/latest/google-cpp-styleguide/comments/
Часть картинок взята из интернета.В случае нарушения или удаления просьба связаться с автором
Обратите внимание на публичный аккаунт WeChat, чтобы увидеть больше оригинального контента.