我们现在的规则是箭头函数只有一个参数，则此参数必须省略

真实的情况是，只有一个参数的箭头函数会有不同场景不同状态，虽然没有明确的结论，但我想我们应该对各种情况再重新审视一下：

普通的多行函数定义

let hash = str => {
    let compute = require('md5');
    return compute(str);
};

普通的单行函数定义

let hash = str => require('md5').compute(str);

函数工厂

let hook = controller => route => console.log(route.url);

let hook = controller => route => action => console.log(action.context);

let hook = controller => route => action => {
    let context = action.context;
    console.log(context.url, context.args);
};

用作参数的单语句函数

let list = names.map(name => name.split(' '));

用作参数的多语句函数

let list = names.map(name => {
    let [firstName, lastName] = name.split(' ');
    return {firstName, lastName};
});

异步函数

let fetch = async id => request(`users/${id}`)

let fetchName = async id => {
    let user = await request(`users/${id}`);
    return user.fullName;
};

顺便箭头+generator是早晚的事，不知道到时候会长啥样……讨论在这边：https://esdiscuss.org/topic/generator-arrow-functions

数组解构

let getFullName = [first, last] => first + ' ' + last

对象解构

let getFullName = ({first, last}) => first + ' ' + last

解构我们现在是要求加括号的，主要原因是对象解构不加括号跑不了……

另外解构也会和多行的组合，效果又有点不一样，可以写着感受下

参数展开

let warn = ...args => console.error(...args);

let filterAndJoin = ...args => {
    return args.filter(s => !!s)
        .map(s => s.replace(/ /g, ''))
        .join(' ')
};

---

这些情况还有可能是组合的，比如在参数中用异步函数等等……

我个人在实践中的感受是，只有“用作参数的单语句函数”这一情况不加括号是另人比较舒服的，理由如下：

1. 作为参数时，前后都已经有括号，使得这个表达式有明确的边界，容易识别
2. 作为参数时是一个callback，其参数个数由当前正在调用的函数（如`.filter`或`.map`）决定的，出于接口的稳定性，这种callback的参数个数基本不会发生变化，所以不会有一会儿多了个参数要加括号了，一会儿参数又减掉了要把括号去掉了这种情况

其它情况下，因为一些原因，我更倾向于加括号：

1. 缺少边界的情况下，参数和函数体的识别变得困难，特别是在多级函数工厂再配上一个单语句函数体的情况下
2. 由于解构和参数展开的存在，使得参数并不是一个简单的identifier，前面后面经常会有杂七杂八的东西，少个括号包起来会造成阅读上一定程度的麻烦（要脑内look ahead之类的）
3. 因为`async`和未来的generator的存在，参数前面还可能出现不同的关键字等，又会造成这部分和参数之间也缺少足够明确的分隔

所以我们是不是集众人之力，对不同情况做一下判断，再整合出一个标准来？

因为template string会保留所有的空白字符，所以template string其实是不能受制于coding style的，否则coding format会影响到实质性的内容。

反过来说，为了保持代码意图清晰，coding style或许应该规定尽量避免在template string中包含换行。

@kener @firede @otakustay @Justineo @leeight @chriswong @wangyang0123 @errorrik

在()进行function call，以及[]的property accessor中，我们现在有两种空格风格：

// style1
functionCall(arg0, arg1);
this.props[this.list[i]];

// style2
functionCall( arg0, arg1 );
this.props[ this.list[ i ] ];

在现有的编码规范中，并未对()和[]内紧贴括号部分是否有空格进行说明，大部分同学的习惯是使用风格1。风格2的好处是多property accessor或者嵌套的function call中更清晰，但大多数人没有此习惯。

然后，我们现在遇到了问题，当多人项目时，很容易出现同项目，甚至同文件的编码风格不一致。

经过 @Justineo 同学发起讨论，决定对此问题发起决策性投票：

A： 强制规定()和[]内不允许添加空格。 B： 保持现状，不强制规定

Less 编码规范

Less 代码的基本规范和原则与 HTML 与 CSS 编码规范中的 CSS 部分保持一致。

代码组织

代码_必须_（MUST）按如下形式按顺序组织：

1. @import
2. 变量声明
3. 样式声明

// ✓
@import "est/all.less";

@default-text-color: #333;

.page {
    width: 960px;
    margin: 0 auto;
}

@import 语句

@import 语句引用的文件_必须_（MUST）写在一对引号内，.less 后缀_不得_（MUST NOT）省略（与引入 CSS 文件时的路径格式一致）。引号使用 ' 和 " 均可，但在同一项目内_必须_（MUST）统一。

// ✗
@import 'est/all';
@import "my/mixins.less";

// ✓
@import "est/all.less";
@import "my/mixins.less";

空格

属性、变量

选择器和 { 之间_必须_（MUST）保留一个空格。

属性名后的冒号（:）与属性值之间_必须_（MUST）保留一个空格，冒号前_不得_（MUST NOT）保留空格。

定义变量时冒号（:）与变量值之间_必须_（MUST）保留一个空格，冒号前_不得_（MUST NOT）保留空格。

在用逗号（,）分隔的列表（Less 函数参数列表、以 , 分隔的属性值等）中，逗号后_必须_（MUST）保留一个空格，逗号前_不得_（MUST NOT）保留空格。

// ✗
.box{
    @w:50px;
    @h :30px;
    width:@w;
    height :@h;
    color: rgba(255,255,255,.3);
    transition: width 1s,height 3s;
}

// ✓
.box {
    @w: 50px;
    @h: 30px;
    width: @w;
    height: @h;
    transition: width 1s, height 3s;
}

运算

+ / - / * / / 四个运算符两侧_必须_（MUST）保留一个空格。+ / - 两侧的操作数_必须_（MUST）有相同的单位，如果其中一个是变量，另一个数值_必须_（MUST）书写单位。

// ✗
@a: 200px;
@b: (@a+100)*2;

// ✓
@a: 200px;
@b: (@a + 100px) * 2;

混入（Mixin）

Mixin 和后面的空格之间_不得_（MUST NOT）包含空格。在给 mixin 传递参数时，在参数分隔符（, / ;）后_必须_（MUST）保留一个空格：

// ✗
.box {
    .size(30px,20px);
    .clearfix ();
}

// ✓
.box {
    .size(30px, 20px);
    .clearfix();
}

选择器

当多个选择器共享一个声明块时，每个选择器声明_必须_（MUST）独占一行。

// ✗
h1, h2, h3 {
    font-weight: 700;
}

// ✓
h1,
h2,
h3 {
    font-weight: 700;
}

Class 命名不得以样式信息进行描述，如 .float-right、text-red 等。

省略与缩写

缩写

多个属性定义可以使用缩写时， 尽量（SHOULD）使用缩写。缩写更清晰字节数更少。常见缩写有 margin、border、padding、font、list-style 等。在书写时_必须_（MUST）考量缩写展开后是否有不需要覆盖的属性内容被修改，从而带来副作用。

数值

对于处于 (0, 1) 范围内的数值，小数点前的 0 可以（MAY）省略，同一项目中_必须_（MUST）保持一致。

// ✗
transition-duration: 0.5s, .7s;

// ✓
transition-duration: .5s, .7s;

0 值

当属性值为 0 时，必须（MUST）省略可省的单位（长度单位如 px、em，不包括时间、角度等如 s、deg）。

// ✗
margin-top: 0px;

// ✓
margin-top: 0;

颜色

颜色定义_必须_（MUST）使用 #RRGGBB 格式定义，并在可能时_尽量_（SHOULD）缩写为 #RGB 形式，且避免直接使用颜色名称与 rgb() 表达式。

// ✗
border-color: red;
color: rgb(254, 254, 254);

// ✓
border-color: #F00;
color: #FEFEFE;

私有属性前缀

同一属性有不同私有前缀的，尽量（SHOULD）按前缀长度降序书写，标准形式_必须_（MUST）写在最后。且这一组属性以第一条的位置为准，尽量（SHOULD）按冒号的位置对齐。

// ✓
.box {
    -webkit-transform: rotate(30deg);
       -moz-transform: rotate(30deg);
        -ms-transform: rotate(30deg);
         -o-transform: rotate(30deg);
            transform: rotate(30deg);
}

其他

可以（MAY）在无其他更好解决办法时使用 CSS hack，并且_尽量_（SHOULD）使用简单的属性名 hack 如 _zoom、*margin。

可以（MAY）但谨慎使用 IE 滤镜。需要注意的是，IE 滤镜中图片的 URL 是以页面路径作为相对目录，而不是 CSS 文件路径。

嵌套和缩进

必须（MUST）采用 4 个空格为一次缩进， 不得（MUST NOT）采用 TAB 作为缩进。

嵌套的声明块前_必须_（MUST）增加一次缩进，有多个声明块共享命名空间时_尽量_（SHOULD）嵌套书写，避免选择器的重复。

但是需注意的是，尽量（SHOULD）仅在必须区分上下文时才引入嵌套关系（在嵌套书写前先考虑如果不能嵌套，会如何书写选择器）。

// ✗
.main .title {
  font-weight: 700;
}

.main .content {
  line-height: 1.5;
}

.main {
.warning {
  font-weight: 700;
}

  .comment-form {
    #comment:invalid {
      color: red;
    }
  }
}

// ✓
.main {
    .title {
        font-weight: 700;
    }

    .content {
        line-height: 1.5;
    }

    .warning {
        font-weight: 700;
    }
}

#comment:invalid {
    color: red;
}

变量

LESS 的变量值总是以同一作用域下最后一个同名变量为准，务必注意后面的设定会覆盖所有之前的设定。

变量命名_必须_（MUST）采用 @foo-bar 形式，不得（MUST NOT）使用 @fooBar 形式。

// ✗
@sidebarWidth: 200px;
@width:800px;

// ✓
@sidebar-width: 200px;
@width: 800px;

继承

使用继承时，如果在声明块内书写 :extend 语句，必须（MUST）写在开头：

// ✗
.sub {
    color: red;
    &:extend(.mod all);
}

// ✓
.sub {
    &:extend(.mod all);
    color: red;
}

混入（Mixin）

在定义 mixin 时，如果 mixin 名称不是一个需要使用的 className，必须（MUST）加上括号，否则即使不被调用也会输出到 CSS 中。

// ✗
.big-text {
    font-size: 2em;
}

h3 {
    .big-text;
}

// ✓
.big-text() {
    font-size: 2em;
}

h3 {
    .big-text();
}

如果混入的是本身不输出内容的 mixin，必须（MUST）在 mixin 后添加括号（即使不传参数），以区分这是否是一个 className（修改以后是否会影响 HTML）。

// ✗
.box {
    .clearfix;
    .size (20px);
}

// ✓
.box {
    .clearfix();
    .size(20px);
}

Mixin 的参数分隔符使用 , 和 ; 均可，但在同一项目中_必须_（MUST）保持统一。

命名空间

变量和 mixin 在命名时_必须_（MUST）遵循如下原则：

• 一个项目只能引入一个无命名前缀的基础样式库（如 est）
• 业务代码和其他被引入的样式代码中，变量和 mixin 必须有项目或库的前缀

字符串

在进行字符串转义时，使用 ~"" 表达式与 e() 函数均可，但在同一项目中_必须_（MUST）保持一致。

字符串两侧的引号_可以_（MAY）使用 ' 或 "，但在同一项目中_必须_（MUST）保持一致。

JS 表达式

可以（MAY）使用 JS 表达式（~``）生成属性值或变量，其中包含的字符串两侧的引号_尽量_（SHOULD）使用单引号（'）。

注释

单行注释_尽量_（SHOULD）使用 // 方式。

// Hide everything
* {
    display: none;
}

背景

提出人

@otakustay @firede

提出原因

1. 我们现有的《项目目录规范》lib目录规定与《commonjs package spec》对lib目录的规定职责不同，commonjs规定lib用于存放Javascript文件。
2. 国外技术社区发展的很快，我们应该向成熟体系的事实标准（如：bower/components）靠拢，便于技术社会化。至少不要产生冲突导致无法融合。

决议

请大家根据投票章节的内容，进行投票。

由于本次修订比较紧急，并且内容不多，所以投票时间截至2013-5-22（星期3）18:00。逾期视为自动放弃。

相关Spec引用

src目录用于存放开发时源文件，发布时必须（MUST）被删除。 lib目录用于存放项目引入依赖的第三方包。该目录下的内容通过平台工具管理，项目开发人员不得（MUST NOT）更改lib目录下第三方包的任何内容。

A CommonJS package will observe the following: A package.json file must be in the top level directory Binary files should be in the "bin" directory, Javascript code should be under the "lib" directory Documentation should be under the "doc" directory Unit tests should be under the "test" directory

投票

1. 修改目录名称：存放项目引入依赖的第三方包的 lib

   A. 将lib修改为component B. 将lib修改为其他名字（选此选项的同学，请在后面附加建议名） C. 不修改，维持lib

2. 修改目录名称：存放开发时源文件的 src

   A. 统一更改为lib B. 业务项目使用src，package项目使用lib C. 可以使用src或lib，但不能同时存在 D. 不修改，维持src

这示例代码用await作为bad的例子可能让人对async/await产生误解。建议把good改写为：

async function requestData() {
    const [tags, articles] = await Promise.all([
        requestTags(), 
        requestArticles(),
    ])
    return {tags, articles}
}

BTW，注意我把 let 改写为了 const。

显见，全部加分号的规则，在esnext的情况下变得更加复杂——function声明，class声明，export声明，decorator，class properties等诸多例外，记忆负担很大。

建议采用 semicolon-less 风格，规则非常简单：不写分号，除非语句首是[、(，则在前面加分号。（正负号和正则literal等理论上可能产生歧义的符号通常不会出现在语句首。）

html标签的缩进为4空格是否有点大了？理论上来说2空格缩进，能很明显的看出缩进排版来。而且，在多层嵌套的标签中，使用2空格缩进，可以大大减少页面源文件的体积。 例如以下两段代码，用4空格缩进的时候，与2空格所进的时候，显示效果差距不是太大，但是4空格所进的时候，会多出两个空格位来。

<!--2空格缩进-->
<div class="lv1">
..<div class="lv2">some code</div>
</div>

<!--4空格缩进-->
<div class="lv1">
....<div class="lv2">some code</div>
</div>

另外，我没有在W3C的规范文档中找到缩进为4空格的建议，不知道是不是遗漏了。如果作者的规定是基于W3C的规范建议来的，希望能分享个链接。

背景

1. 解决 edp package 与 npm package 的依赖冲突
2. 满足 edp package 信息扩展的需求

提议

1

在 package.json 中增加 edp 字段，package.json 的结构像这样：

{
  // npm dependences
  "dependences": {
    "edp-provider-rider": "~0.2.1"
  },
  "edp": {
    // edp dependences
    "dependences": {
      "saber-lang": "~0.3.0",
      // more ...
    },
    // edp devDependences
    "devDependences": {
      "saber-viewport": "~0.2.0"
    }
  }
}

当存在 edp 字段且字段下有需要的配置，采用 edp 字段中对应的配置；否则，仍使用根节点下的配置。

2

在 edp 字段下增加 browsers 字段，标明前端 package 对浏览器的支持情况，比如：

{
  "edp": {
    "browsers": {
      "ie": ">=10",
      "android": ">=2.3",
      "ios": ">=5"
    }
  }
}

browsers 字段的命名来自 browserify 社区的 testling。 字段内配置的浏览器命名参考了 autoprefixer。

问题

目前有一些不确定的问题：

1. 各个字段的命名，是采用 edp、browsers 还是别的字段。
2. 配置的检测是对 edp 之外的 所有字段 采用 提议1 中的逻辑，还是仅针对 dependences/devDependences 等有限字段进行处理。
3. browsers 字段内的格式、版本号对比等。

更多的问题请大家 review @errorrik @leeight @chriswong @otakustay

使用eslint-plugin-react，已经包含所有规则的具体配置，可以针对每一个讨论

{
    "default-props-match-prop-types": [2],
    "display-name": [2],
    "forbid-component-props": [1],
    "forbid-elements": [0],
    "forbid-foreign-prop-types": [1],
    "forbid-prop-types": [0],
    "jsx-boolean-value": [2],
    "jsx-closing-bracket-location": [2],
    "jsx-curly-spacing": [2],
    "jsx-equals-spacing": [2],
    "jsx-filename-extension": [2, [".js", ".jsx", ".es"]],
    "jsx-first-prop-new-line": [2],
    "jsx-handler-names": [1, {"eventHandlerPrefix": "", "eventHandlerPropPrefix": "on"}],
    "jsx-indent-props": [2, 4],
    "jsx-indent": [2, 4],
    "jsx-key": [2],
    "jsx-max-props-per-line": [2, {"when": "multiline", "maximum": 1}],
    "jsx-no-bind": [1],
    "jsx-no-comment-textnodes": [1],
    "jsx-no-duplicate-props": [2],
    "jsx-no-literals": [2],
    "jsx-no-target-blank": [2],
    "jsx-no-undef": [2],
    "jsx-pascal-case": [2],
    "jsx-sort-props": [0],
    "jsx-space-before-closing": [2],
    "jsx-tag-spacing": [2],
    "jsx-uses-react": [0],
    "jsx-uses-vars": [2],
    "jsx-wrap-multilines": [2],
    "no-array-index-key": [2],
    "no-children-prop": [2],
    "no-danger-with-children": [2],
    "no-danger": [1],
    "no-deprecated": [2],
    "no-did-mount-set-state": [2],
    "no-did-update-set-state": [2],
    "no-direct-mutation-state": [2],
    "no-find-dom-node": [2],
    "no-is-mounted": [2],
    "no-multi-comp": [2, {"ignoreStateless": true}],
    "no-render-return-value": [2],
    "no-set-state": [0],
    "no-string-refs": [2],
    "no-unescaped-entities": [2],
    "no-unknown-property": [2],
    "no-unused-prop-types": [1],
    "no-will-update-set-state": [2],
    "prefer-es6-class": [2],
    "prefer-stateless-function": [2],
    "prop-types": [2],
    "react-in-jsx-scope": [0],
    "require-default-props": [2],
    "require-optimization": [0],
    "require-render-return": [2],
    "self-closing-comp": [2],
    "sort-prop-types": [0],
    "style-prop-object": [2],
    "void-dom-elements-no-children": [2],
    "sort-comp": [
        2,
        {
            "order": [
                "static-properties",
                "static-methods",
                "lifecycle",
                "everything-else",
                "render"
            ],
            "groups": [
                "static-properties": [
                    "displayName",
                    "propTypes",
                    "contextTypes",
                    "childContextTypes",
                    "mixins",
                    "statics"
                ],
                "lifecycle": [
                    "defaultProps",
                    "constructor",
                    "getDefaultProps",
                    "getInitialState",
                    "state",
                    "getChildContext",
                    "componentWillMount",
                    "componentDidMount",
                    "componentWillReceiveProps",
                    "shouldComponentUpdate",
                    "componentWillUpdate",
                    "componentDidUpdate",
                    "componentWillUnmount"
                ]
            ]
        }
    ]
}

“import会被默认提升至模块最前面”这个说法是错误的，实际并不会。

“浏览器如能尽早读取相关的import内容则有可能更早地请求相关的依赖模块，有一定的性能提升作用，在HTTP/2之后可能会具有更明显的效果。”——这些说法也存疑，虽然理论上似乎是可能的。实际上更可能的是服务器端利用HTTP/2在没有请求的情况下预先发出被依赖的module——然而此种优化与import的前后并无关系。

另外bad的代码本身是错误的，import语句只能在top-level，而不能在函数里。

tsx 文件中，尖括号含义可能出现歧义，即 ts 下的泛型与 html 中的标签。这种语法的二义性可能导致不合理的报错。 例如，在 tsx 文件中，定义一个带有一个泛型参数的箭头函数。VS Code 就会将 <T> 理解为标签，导致后续代码报错

const f = <T>(v: T) => v;

<T extends any> 是消除标签-泛型歧义的常用手段，但是会与目前规则冲突。

/good/示例中，大小写并未统一。

原文： [强制] font-family 不区分大小写，但在同一个项目中，同样的 Family Name 大小写必须统一。 示例：

/* good */ body { font-family: Arial, sans-serif; }

h1 { font-family: Arial, "Microsoft YaHei", sans-serif; }

/* bad */ body { font-family: arial, sans-serif; }

h1 { font-family: Arial, "Microsoft YaHei", sans-serif; }

vue单页面 方法和计算属性 是使用 像 普通js 方法一样的注释吗？？？？如： methods: { /** * 加载运送类型列表 * @param {string} transTypeParentCode 接口请求的参数: 运送编码 */ getTransTypeList (transTypeParentCode) { // 这里写逻辑代码 } }

return exeEndUser.tel ? ${exeEndUser.userName}(${exeEndUser.tel}) : exeEndUser.userName

怎么换行？这样吗？ return exeEndUser.tel ? ${exeEndUser.userName}(${exeEndUser.tel}) : exeEndUser.userName