-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathsearch.xml
More file actions
28 lines (18 loc) · 2.18 KB
/
search.xml
File metadata and controls
28 lines (18 loc) · 2.18 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<?xml version="1.0" encoding="utf-8"?>
<search>
<entry>
<title><![CDATA[javascript语言精粹读书笔记-第一章]]></title>
<url>%2F2017%2F05%2F16%2Fjavascript-good-parts%2Fone%2F</url>
<content type="text"></content>
</entry>
<entry>
<title><![CDATA[zepto源码分析一]]></title>
<url>%2F2017%2F04%2F20%2Fzepto-source-code-analysis%2Fone%2F</url>
<content type="text"></content>
</entry>
<entry>
<title><![CDATA[基于fis3的eslint自动检测插件]]></title>
<url>%2F2017%2F03%2F09%2FEssay%2Ffis3-lint-noob-eslint%2F</url>
<content type="text"><![CDATA[##起因团队发展到一定规模就需要有一个统一的标准去约束成员,统一编码风格。要完成这件事就需要先确定几个事: 用什么样的编码规范 是自己定义一套还是基于开源标准 编码规范怎么在实际开发中执行 选择规范在团队中开了几次头脑风暴,也实际调研了下现有的编码规范。目前比较流向的两个规范: feross 的 standard 标准,目前在 github 上有1w多个star github地址 官网地址 airbnb 公司的 javascript 标准,目前在 github 上 star 已经突破5w github地址 虽然 airbnb 公司的方案已有 5w 个 star,不过 standard 标准大有赶超的意思,所以最后选择了基于standard来做 js 规范。 确定方案好了,现在确定了编码规范,剩下的就是怎么去落地标准。如果只是让每个人去学习标准并不能保证所有人都能严格的执行标准去写代码,所以最好的办法还是在开发阶段就发现问题,并且必须要解决了错误才能继续开发,这样就能保证大家都是一样的标准了。 由于团队使用的是百度的 fis3 作为构建工具,所以第一想法就是用 fis3+eslint 来检查代码。于是就在 fis3 的插件列表中搜了下,找到几款基于 eslint 的 fis3 插件: 但是美中不足的是这些插件大都是在终端中显示错误信息,而且错误信息的格式也不优雅: 基于以上原因最终确定自己开发一款基于fis3,eslint和standard标准的插件。 钩子]]></content>
</entry>
</search>