Аннотируйте эти вещи — серия о качестве внешнего кода (1)

внешний интерфейс JavaScript спецификация кода Airbnb ESLint
«Комментировать или не комментировать, вот в чем вопрос"

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

Так что же такое хорошие аннотации? Как писать хорошие комментарии? В этой статье мы обсудим аннотации JS с точки зрения назначения и принципов аннотаций.

01 Назначение и принципы аннотации

Цель аннотации:

  • Улучшить читаемость кода и, следовательно, его ремонтопригодность

Принципы аннотации:

  • Не добавлять комментарии, если в этом нет необходимости (как можно короче)

  • Сколь угодно долго

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

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

Мы должны стремиться к «самомкомментарию кода», то есть сам код имеет высокую читабельность (за счет четкого именования, разумной структуры и т. д.). Например:

// 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 Протокол аннотаций

Вот спецификация аннотации для справки (ссылка на спецификацию airbnb):

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, чтобы увидеть больше оригинального контента.