• 
  编写让人一目了然的代码然后忽略这一节的其它部分。我是认真的！
  ^[link]

• 
  使用英文编写注释。
  ^[link]

• 
  前导 与注释文本之间应当添加一个空格。
  ^[link]

• 
  注释超过一个单词时，句首字母应当大写，并在语句停顿或结尾处使用标点符号。句号后添加一个空格。
  ^[]

• 
  避免无谓的注释。
  ^[]

• 
  及时更新注释。过时的注释比没有注释还要糟糕。
  ^[]

• 
  避免替烂代码编写注释。重构它们使其变得一目了然。（要么做，要么不做，不要只是试试看。——Yoda）
  ^[]

• 
  注解应该直接写在相关代码之前那行。
  ^[]

• 
  注解关键字后面，跟着一个冒号及空格，接着是描述问题的文本。
  ^[]

• 
  如果需要用多行来描述问题，后续行要放在 # 后面并缩排两个空格。
  ^[]

  def bar
    # FIXME: This has crashed occasionally since v3.2.1. It may
    baz(:quux)
  end

• 
  当问题是显而易见时，任何文档都是多余的，注解应当放在有问题的那行末尾且不带任何多余说明。这个用法应该算是例外而不是规则。
  ^[]

• 
  使用 TODO 标记应当加入的特征与功能。
  ^[]

• 
  使用 FIXME 标记需要修复的代码。
  ^[]

• 
  使用 标记代码异味，即那些应当被重构的可疑编码习惯。
  ^[]

• 
  使用 REVIEW 标记需要确认与编码意图是否一致的可疑代码。比如，REVIEW: Are we sure this is how the client does X currently?。
  ^[]

• 
  适当情况下，可以自行定制其他注解关键字，但别忘记在项目的 README 或类似文档中予以说明。
  ^[]

Magic Comments

• 
  Place magic comments above all code and documentation. Magic comments should only go below shebangs if they are needed in your source file.
  ^[link]

  # good
  # frozen_string_literal: true
  # Some documentation about Person
  class Person
  # Some documentation about Person
  # frozen_string_literal: true
  class Person
  end

• 
  Use one magic comment per line if you need multiple.
  ^[link]

  # good
  # frozen_string_literal: true
  # encoding: ascii-8bit
  # bad
  

• 
  Separate magic comments from code and documentation with a blank line.
  ^[link]