airbnb/javascript 把出错的提醒提前到了编码的时候,几乎不能再前了,大家都知道错误发现的越早解决的成本越低,带来的破坏越小。 最近代码写的越多越感觉js不弄一个强约束很容易大家每人一个风格,分分钟玩坏。
我在我的 open-rest 框架的es6样本工程 open-rest-es-boilerplate 里全面通过了最严格的eslint规则,体会非常深刻,大家感兴趣的去clone下来体会一下。
想必 airbnb 也是吃了不少代码不规范的亏,导致代码无法维护
这个好可怕
就记得//
后面是要有tab的
@chemzqm 规范是好事儿,我做这个的过程深有体会
@stonephp 我同意。在ESLint与StyleLint工具的帮助下,团队的“纪律性”与“工程化意识”才能够在短期内被确立。虽然这个过程真心地有一些痛苦。但是,值得。
@stuartZhang 同道中人
最近代码写的越多越感觉js不弄一个强约束很容易大家每人一个风格,分分钟玩坏。 辣么, 还玩啥 eslint airbnb, 上 standard 啊
@magicdawn 一样的,都是基于eslint的规范。
最近也在研究ESlint,试过airbnb的base集,确实很严格。 感觉Airbnb的规则更偏向于WEB或移动端WEB化的开发场景?Node.js服务开发的时候用好像并不是很好用。 仔细看了看airbnb的文档,决定不用了,综合了公司所有服务端开发人员的习惯和思想,比如大家都觉得4空格缩进更加清晰一些,目前是ESlint自己的规则全开,关闭部分有特殊需求的规则,外加一些自定义规则
不错
代码格式是通往牛逼的捷径。
@libook 恩,适当的引入一些特殊的配置,但是尽量要少,或者说增加自己特殊配置的时候一定要明白规则的初衷是什么?
eslint 使用airbnb的规则的话,必须在项目最开始就实行,如果项目几万行代码已经写出来了,这个时候使用,会让你哭到你妈妈都不认识你!不要问我怎么知道,我妈已经不认识我了。
@rongchanghai 不是有个 --fix 选项,正好测试一下功能哈
@rongchanghai 为什么不用–fix参数?
@rongchanghai 其实我有好几个项目就是后期引入airbnb的,确实很痛苦,我给团队定了一条规则就是新建立的文件必须要符合规范,另外如果某一次要改动一个原有的文件,那么这次改动一定要顺带调整编码规范,以满足airbnb的要求。 这样就把这个规范放到一个较长的时间过程中了。避免了团队的强抵触。
我想问,你这个注释是遵循什么约定的
@DevinXian 这个是 apidocs 的约定,不过下一步计划用 swagger 了。
然后你还会写代码吗?反正我是用上以后一个月之内都感觉自己不会写代码了
@jiangzhuo 我适应了一周,现在基本上习惯被矫正过来了。那现在的代码和之前的代码对比确实规范、漂亮很多。
用的 standard 规范,感觉相对 airbnb 更加合理一点。
@kisnows 目前有那些大公司在实践 standard 吗?和airbnb的规范有哪些区别?