这份指南阐述了一些 CoffeeScript 的最佳实践和编码惯例。

这份指南是社群驱动的,非常鼓励大家来贡献内容。

请注意这还是一份正在完善的指南:仍有很多地方可以改进,有些已制定的准则也不一定是社区惯用的(基于此,在适当的情况下,这些有待斟酌的准则将有可能被修改或删除。)

灵感

本指南中的很多细节受到了几份现有的风格指南和其他资源的启发。特别是:

  • PEP-8: Style Guide for Python Code
  • Bozhidar Batsov’s Ruby Style Guide
  • Google’s JavaScript Style Guide
  • Common CoffeeScript Idioms
  • Thomas Reynolds’ CoffeeScript-specific Style Guide
  • Jeremy Ashkenas’ code review of Spine
  • The CoffeeScript FAQ

代码布局(Code Layout)

Tab 还是 空格?(Tabs or Spaces?)

只用 空格,每级缩进均为 2 个空格。切勿混用 Tab 和空格。

最大行宽(Maximum Line Length)

限制每行最多 79 个字符。

空行(Blank Lines)

  1. 顶级函数和类的定义用一个空行分开。
  2. 类内部的函数定义也用一个空行分开。
  3. 对于每个函数体内,只在为了提高可读性的情况下才使用一个空行(例如:为了达到划分逻辑的目的)。

结尾空白(Trailing Whitespace)

不要在任何一行保留行尾空白。

可选的逗号(Optional Commas)

当对象(或数组)的属性(或元素)作为单独一行列出时,避免在换行符前使用逗号。如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 好
foo = [
  'some'
  'string'
  'values'
]
bar:
  label: 'test'
  value: 87
# 差
foo = [
  'some',
  'string',
  'values'
]
bar:
  label: 'test',
  value: 87

编码(Encoding)

UTF-8 是首选的源文件编码。

模块导入(Module Imports)

如果需要导入模块 (CommonJS 模块,AMD,等等.), require 语句应该单独作为一行。如下:

1
2
require 'lib/setup'
Backbone = require 'backbone'

这些语句应该按以下顺序去分组:

  1. 标准库的导入 (如果标准库存在)
  2. 第三方库的导入
  3. 本地导入 (导入这个应用程序的或库的具体依赖)

表达式和语句中的空白(Whitespace in Expressions and Statements)

下列情况应该避免多余的空格:

  • 紧贴着圆括号、方括号和大括号内部
1
2
($ 'body') # 好
 ( $ 'body' ) # 差

紧贴在逗号前

1
2
console.log x, y # 好
console.log x , y # 差

额外建议:

  • 在下列二元操作符的左右两边都保留 一个空格

    • 赋值运算符: =
      注意:这同样适用于函数定义中的默认参数
1
2
test: (param = null) -> # 好
test: (param=null) -> # 差

  • 自增运算符: +=-=, 等等。
  • 比较运算符: ==<><=>=unless, 等等。
  • 算术运算符: +-*/, 等等。
  • (这些操作符两边的空格不要多于一个)
1
2
3
4
5
6
7
8
9
# 好
  x = 1
  y = 1
  fooBar = 3
  # 差
  x      = 1
  y      = 1
  fooBar = 3

注释(Comments)

如果你修改了一段已有注释说明的代码,则也要更新它对应的注释。(理想状态是,重构这段代码直到它不需要注释说明,然后再把之前的注释全删掉。)

注释的首字母要大写,除非第一个单词是以小写字母开头的标识符。

如果注释很短,可以省略末尾的句号。

块注释(Block Comments)

注释块通常应用于尾随其后的一段代码。

每一行注释都以 # 加一个空格开头,而且和被注释的代码有相同的缩进层次。

注释块内的段落以仅含单个 # 的行分割。

1
2
3
4
5
6
7
8
9
# 这是一个块注释。请注意假如这是一段块注释,
 # 则它描述的就应该是接下来的这段代码。
 #
 # 这是块注释的第二段。
 # 请注意这段是由上一行带有 # 号的空行分开的。(P.S. 最好用英文写注释)
 init()
 start()
 stop()

行内注释(Inline Comments)

行内注释紧贴在被描述的代码的上一行,如果行内注释足够短,则可以处在同一行行尾(由一个空格隔开)。

所有行内注释都以 # 加一个空格开头。

应该限制行内注释的使用,因为它们的存在通常是一个代码异味的标志。

不要给显而易见的情况作行内注释:

1
2
# 差
x = x + 1 # x 自增

然而,行内注释在某些情况下是有用的:

1
2
# 好
x = x + 1 # 边界补足

命名规范(Naming Conventions)

使用 小驼峰命名法 (第一个词的首字母小写,后面每个词的首字母大写)来命名所有的变量、方法和对象属性。

使用 大驼峰命名法 (第一个词的首字母,以及后面每个词的首字母都大写)来命名所有的类 (在其他类似的命名法中,这种风格通常也被称为 帕斯卡命名法(PascalCase)、 大写驼峰命名法(CamelCaps) 或 首字母大写命名法(CapWords)。)

(CoffeeScript 官方 约定是用驼峰命名法,因为这可以简化与 JavaScript 的相互转化,想了解更多,请看这里.)

对于常量,单词全部大写,用下划线隔开即可:

1
CONSTANT_LIKE_THIS

私有函数和私有变量都应该在前面加一个下划线:

1
_privateMethod: ->

函数(Functions)

(以下这些准则同样适用于类中的方法。)

当声明一个带参函数时,应在参数列表的右圆括号后空出一个空格:

1
2
foo = (arg1, arg2) -> # 好
foo = (arg1, arg2)-> # 差

无参函数不要用圆括号:

1
2
bar = -> # 好
bar = () -> # 差

当函数链式调用,却在一行放不下时,则把每个函数调用都另起一行,且都缩进一级(即在 . 前加两个空格)。

1
2
3
4
5
[1..3]
  .map((x) -> x * x)
  .concat([10..12])
  .filter((x) -> x < 11)
  .reduce((x, y) -> x + y)

当调用函数时,我们应该为了提高可读性而去掉圆括号。请记住,「可读性」是我们主观臆断的。只有类似下面几个例子的情况才被社区认为是最佳的:

1
2
3
4
5
6
7
8
9
10
11
baz 12
brush.ellipse x: 10, y: 20 # 大括号在适当的时候也可以去掉
foo(4).bar(8)
obj.value(10, 20) / obj.value(20, 10)
print inspect value
new Tag(new Value(a, b), new Arg(c))

有时候你会发现圆括号用来包裹的是函数体(而不是函数的参数)。请看下面的例子(以下简称为「函数体风格」):

1
2
3
($ '#selektor').addClass 'klass'
(foo 4).bar 8

这段代码会编译为:

1
2
3
$('#selektor').addClass 'klass'
foo(4).bar 8

一些习惯链式调用的人会巧用「函数体风格」进行单独初始化:

1
2
($ '#selektor').addClass('klass').hide() # 单独初始化调用
(($ '#selektor').addClass 'klass').hide() # 全部调用

「函数体风格」并不得到推荐。但是, 当它适应一些特殊的项目需求时,还是得用它。

字符串(Strings)

用字符串插值代替字符串连接符:

1
2
"this is an #{adjective} string" # 好
"this is an " + adjective + " string" # 差

最好用单引号 ('') 而不是双引号 ("") 。除非是插入到另一段现有的字符串中(类似字符串插值)

条件判断(Conditionals)

用 unless 来代替 if 的否定情况。

不要用 unless...else, 而用 if...else:

1
2
3
4
5
6
7
8
9
10
11
# 好
 if true
   ...
 else
   ...
 # 差
 unless false
   ...
 else
   ...

多行的 if/else 语句应该缩进:

1
2
3
4
5
6
7
8
9
# 好
 if true
   ...
 else
   ...
 # 差
 if true then ...
 else ...

循环和列表解析(Looping and Comprehensions)

尽可能的使用列表解析:

1
2
3
4
5
6
7
# 好
 result = (item.name for item in array)
 # 差
 results = []
 for item in array
   results.push item.name

还可以过滤结果:

1
result = (item for item in array when item.name is "test")

遍历对象的键值:

1
2
object = one: 1, two: 2
alert("#{key} = #{value}") for key, value of object

扩展本地对象(Extending Native Objects)

不要修改本地对象。

比如,不要给 Array.prototype 引入 Array#forEach 。

异常(Exceptions)

不要抑制异常抛出。

注解(Annotations)

必要的时候应该写注解,来指明接下来的代码块具体将干什么。

注解应紧贴在被描述代码的上一行。

注解关键字后面应该跟一个冒号加一个空格,加一个描述性的注释。

1
2
3
# FIXME: The client's current state should *not* affect payload processing.
resetClientState()
processPayload()

如果注解不止一行,则下一行缩进两个空格。

1
2
3
# TODO: Ensure that the value returned by this call falls within a certain
#   range, or throw an exception.
analyze()

注解有以下几类:

  • TODO: 描述缺失的功能,以便日后加入
  • FIXME: 描述需要修复的代码
  • OPTIMIZE: 描述性能低下,或难以优化的代码
  • HACK: 描述一段值得质疑(或很巧妙)的代码
  • REVIEW: 描述需要确认其编码意图是否正确的代码

如果你必须自定义一个新的注解类型,则应该把这个注解类型记录在项目的 README 里面。

其他(Miscellaneous)

and 更优于 &&.

or 更优于 ||.

is 更优于 ==.

not 更优于 !.

or= 应在可能的情况下使用:

1
2
temp or= {} # 好
temp = temp || {} # 差

最好用 (::) 访问对象的原型:

1
2
Array::slice # 好
Array.prototype.slice # 差

最好用 @property 而不是 this.property.

1
2
return @property # 好
return this.property # 差

但是,避免使用 单独的 @:

1
2
return this # 好
return @ # 差

没有返回值的时候避免使用 return ,其他情况则需要显示 return 。

当函数需要接收可变数量的参数时,使用 splats (...)。

1
2
3
console.log args... # 好
(a, b, c, rest...) -> # 好

[CoffeeScript]编码风格指南相关推荐

  1. 来自 Google 的 R 语言编码风格指南

    来自 Google 的 R 语言编码风格指南 R 语言是一门主要用于统计计算和绘图的高级编程语言. 这份 R 语言编码风格指南旨在让我们的 R 代码更容易阅读.分享和检查. 以下规则系与 Google ...

  2. JavaScript编码风格指南

    首次发表在个人博客 前言 程序语言的编码风格指南对于一个长期维护的软件而言是非常重要的;好的编程风格有助于写出质量更高.错误更少.更易于 维护的程序. 团队合作需要制定一些代码规范还有利用一些工具来强 ...

  3. Airbnb JavaScript 编码风格指南(2018年最新版)

    Airbnb JavaScript 编码风格指南(2018年最新版) 访问此原文地址:http://galaxyteam.pub/didi-fe... 另外欢迎访问我们维护的https://www.t ...

  4. c++编码风格指南_带回家的编码挑战的基本指南

    c++编码风格指南 by Jane Philipps 简·菲利普斯 带回家的编码挑战的基本指南 (The Essential Guide to Take-home Coding Challenges) ...

  5. c++编码风格指南_100%正确的编码样式指南

    c++编码风格指南 Here are three links worth your time: 这是三个值得您花费时间的链接: The 100% correct coding style guide ...

  6. c++编码风格指南_100%正确编码样式指南

    c++编码风格指南 Tabs or spaces? Curly brace on the same line or a new line? 80 character width or 120? 制表符 ...

  7. Spring Boot 微服务编码风格指南和最佳实践

    文奇摄于世界尽头州立公园 通过多年来使用 Spring Boot 微服务,我编制了一份编码风格指南和最佳实践列表.这份清单并不全面,但我希望您能找到一两点可以借鉴的地方,无论您是新手还是经验丰富的 S ...

  8. Python 编码风格指南

    本节收录了稍作剪辑的PEP 8摘要(Python Enhancement Proposal,Python增强提案).PEP 8由Guido van Rossum和Barry Warsaw撰写,是Pyt ...

  9. Python编码风格指南

    来源 | 异步图书 本节收录了稍作剪辑的PEP 8摘要(Python Enhancement Proposal,Python增强提案).PEP 8由Guido van Rossum和Barry War ...

最新文章

  1. redis有几种数据类型
  2. WebAPi接口安全之公钥私钥加密
  3. 为Drupal7.22添加富编辑器 on Ubuntu 12.04
  4. Python3基础教程:元类详解
  5. linux redis release.c:37:10: fatal error: release.h: No such file or directory
  6. 设计模式2—结构型模式
  7. Oracle sqlserver mysql的自增变量设置
  8. mysql5.6 主从同步
  9. Linux格式化分区报错Could not start /dev/sda No such file or directory 解决办法
  10. 转:Confusion Matrix(混淆矩阵) 解释最全的一个
  11. 富士施乐Fuji Xerox DocuPrint M225 dw 驱动
  12. android手表文件管理,watch文件管理器APP安卓版下载-watch文件管理器华为手表版v1.1.0 免费版-007游戏网...
  13. 电影天堂,批量下载,简单实现
  14. 前端学到什么程度才能叫精通?
  15. 《分布式消息中间件实践》 读书笔记
  16. NXP的S32K系列MCU怎么样?
  17. Mac-Mini 外接三个显示器教程
  18. 创建 mapbox 本地 sprite
  19. 手把手教你设计:拼团活动
  20. PDF不能编辑的问题如何解决?

热门文章

  1. 发明专利申请流程与条件
  2. linux下安装checkra1k
  3. Vue中引入富文本编辑器
  4. 大概这就是“无监督学习”的机器学习算法实例
  5. 掌上单片机实验室 - 编程环境(续)(6)
  6. [Fatal Error] total number of created files now is 100576, which exceeds 100000. Killing the job.
  7. 使用create-react-app搭建TypeScript+React+Ant Design开发环境
  8. 22 Rest高级客户端实践(八):滚动搜索
  9. ShareSDK QQ分享遇到的问题记录
  10. Dolphin for Mac(Wii游戏模拟器)