flower-f / code-standard

前端开发规范，包括命名，代码格式化，git message，文件结构组织等。

description
旨在团队在协同开发时，提供一致性的开发体验。

规范说明

{% hint style="info" %} 本规范仅适用于前端开发领域。 {% endhint %}

我们为什么需要规范？

以下列举到一些场景，您是否有类似的感受？

场景一

产品："这是个2年前的项目，页面要改一下，修改后的原型图我发给你了哈。"
小明："好啊，大概三天能搞定。"(心想，这么简单的需求，半天就能搞定)
产品："好的。"
...你拿过项目...
小明："这啥呀这是？"
小明："哎~~"
小明："卧槽，牛逼！"
小明："诶？这个方法是干嘛使的？"
小明："递归..."

场景二

CTO："有个多语言的翻译有点问题，你帮忙改一下，日文改成求德玛得就行。"
小明："好的，我一会儿改好给您。"
......
小明："老板，我改好了，辛苦处理下pr哦。"
CTO："卧槽，我只让你改了一个翻译，你怎么全改了，你这让让我怎么review，你重新弄吧。一个翻译都弄不好，真是的。"

场景三

大神："axios源码里面，request...."
小明："大神你咋看的源码，教教我。"
大神："打开直接看不就行了，他们注释都有写，挺规范的。"
小明："可是我看不懂。"
大神："......"

我们使用规范有什么好处？

• 个人
  • 代码维护性更高；
  • 看源码更轻松，感觉就像自己写的；
  • 不用纠结这个方法叫啥比较好；
• 团队
  • review更轻松；
  • 代码维护更容易；
  • 每个参与者都很爽；
• 开源
  • 更容易有人参与贡献；
  • 更容易建立自己的影响力；

我们的规范为什么权威？

为确保内容的权威性，本书的规范内容均来自于知名的框架与库中，截取写法，示例的形式进行编排与和汇总，最后整理到文档中。形成规范依据。

目前参照的库如下

• ant-design
• element-ui
• vue
• react

如何对本文档进行贡献？

项目目前处于发展初期，诚邀大家加入。可以添加我的微信kasoqian，注明开源建设，我会拉您进开源群内，一起参与建设。

本书TODO

• 目录规范
• git commit规范
• .prettierrc规范
• .stylelintrc规范

开源贡献者

裴洋，黄云汉，刘家俊，张伟凯