前端团队规范 - GodGc's World

正好这周在HUPU总结了一下FED团队代码规范，整理一下挂在blog上分享一下
分为3-part，包括CSS、JS和自己近3年开发经验总结的软性能力

CSS代码规范

命名使用 "-" 连接 exp: content-warp
选择器 与 { 之间必须包含空格。

  .selector {
    ...
  }

属性名 与之后的 : 之间不允许包含空格， : 与 属性值 之间必须包含空格。

  position: fixed;

当一个 rule 包含多个 selector 时，每个选择器声明必须独占一行。

 /* good */
  .post,
  .page,
  .comment {
    line-height: 1.5;
 }
  
 /* bad */
  .post, .page, .comment {
    line-height: 1.5;
   }

!important 的使用原则是：能不用就不用
z-index 应该分层管理， 1~100，101~200，201~300 ...
- Why? 清晰，可用，容错性强
当数值为 0 - 1 之间的小数时，省略整数部分的 0
url() 函数中的路径不加引号。
- Why? 合法，省事，如果加了css压缩时可能都会去掉
长度为 0 时须省略单位。 (也只有长度单位可省)
Why？易辨识，解析会更快

JavaScript代码规范

变量声明使用const以及let，避免使用var
尽可能的使用简写

// 对象方法简写 

const atom = { 

    value: 1, 

    addValue(value) { 

        return atom.value + value; 

    }, 

}; 

// 简写属性值 

const lukeSkywalker = 'Luke Skywalker'; 

const obj = { 

    lukeSkywalker, 

};

简单类型声明统一放在对象声明前面
字符串使用单引号 ''
在函数签名中使用空格

// bad 

const f = function(){}; 

const g = function (){}; 

const h = function() {}; 

// good 

const x = function () {}; 

const y = function a() {};

将所有的import放在非import语句前
多行import应该像多行数组和对象字面量一样被缩进

// bad 

import {longNameA, longNameB, longNameC, longNameD, longNameE} from 'path'; 

// good 

import { 

    longNameA, 

    longNameB, 

    longNameC, 

    longNameD, 

    longNameE, 

} from 'path';

不允许出现未被使用的变量

原因：声明但未被使用的变量通常是不完全重构犯下的错误.这种变量在代码里浪费空间并会给读者造成困扰.

使用 === 和 !==而非 == 和 !=
对于布尔值使用简写，但对于字符串和数字要显式比较

// bad 

if (isValid === true) { 

// ... 

} 

// good 

if (isValid) { 

// ... 

} 

// bad 

if (name) { 

// ... 

} 

// good 

if (name !== '') { 

// ...stuff... 

} 

// bad 

if (collection.length) { 

// ... 

} 

// good 

if (collection.length > 0) { 

// ... 

}

在起始花括号前加一个空格

// bad 

function test(){ 

    console.log('test'); 

} 

// good 

function test() { 

    console.log('test'); 

} 

// bad 

dog.set('attr',{ 

    age: '1 year', 

    breed: 'Bernese Mountain Dog', 

}); 

// good 

dog.set('attr', { 

    age: '1 year', 

    breed: 'Bernese Mountain Dog', 

});

操作符两边放置空格
用空行结束文件
在代码块结束和下一个声明前留一个空行
逗号前不要加空格，逗号后要加空格(数组)
结尾使用额外的逗号

// bad 

const hero = { 

    firstName: 'Dana', 

    lastName: 'Scully' 

}; 

const heroes = [ 

    'Batman', 

    'Superman' 

]; 

// good 

const hero = { 

    firstName: 'Dana', 

    lastName: 'Scully', 

}; 

const heroes = [ 

    'Batman', 

    'Superman', 

];

使用分号;作为一句代码的结尾

原因: 当JavaScript不使用分号遇到分行符时，会使用一系列称作分号自动插入(ASI) 的规则来决定其是否应该将分行符视作声明的结尾, (正如名字所暗示的) 如果必要的话会在分行符前插入一个分号. ASI拥有几个古怪的行为, 如果JavaScript错误地解释了换行符你的代码会收到破坏. 这些规则会随着新的特性成为JavaScript的一部分而变得越来越复杂. 显式地结束声明语句并且配置好校验器来捕获缺失的分号会帮你避免遇到这些问题.

命名规则

避免单字母名字. 命名需有可描述性，不要担心命名太长
命名对象，函数和实例时使用驼峰风格

const thisIsMyObject = {}; 

function thisIsMyFunction() {}

不要保存指向 this的引用. 使用箭头函数或函数的#bind

// bad 

function foo() { 

    const self = this; 

    return function () { 

        console.log(self); 

    }; 

} 

// bad 

function foo() { 

    const that = this; 

    return function () { 

        console.log(that); 

    }; 

} 

// good 

function foo() { 

    return () => { 

        console.log(this); 

    }; 

}

缩略词应全部大写或小写

原因：名字是用来阅读的，不能让步给计算机算法

// bad 

import SmsContainer from './containers/SmsContainer'; 

// bad 

const HttpRequests = [ 

// ... 

]; 

// good 

import SMSContainer from './containers/SMSContainer'; 

// good 

const HTTPRequests = [ 

// ... 

]; 

// best 

import TextMessageContainer from './containers/TextMessageContainer'; 

// best 

const Requests = [ 

// ... 

];

airbnb-javascript-style-guide-cn
https://github.com/libertyAlone/airbnb-javascript-style-guide-cn

ESlint配置原则

能够帮助发现代码错误的规则，全部开启
配置不应该依赖于某个具体项目，而应尽可能的合理
帮助保持团队的代码风格统一，而不是限制开发体验

{
  "plugins": [
    // "react",
    "html"
  ],
  "env": {
    "node": true,
    "jquery": true,
    "es6": true,
    "browser": true
  },
  "globals": {
    "angular": false
  },
  "parser": "babel-eslint",
  "rules": {
    //官方文档 http://eslint.org/docs/rules/
    //参数：0 关闭，1 警告，2 错误
    "quotes": [0, "single"], //建议使用单引号
    "no-extra-boolean-cast": 1, //多余的感叹号转布尔型
    "no-extra-semi": 1, //多余的分号
    "no-extra-parens": 0, //多余的括号
    "no-empty": 1, //空代码块
    //使用前未定义
    "no-use-before-define": [
      0,
      "nofunc"
    ],
    "complexity": [0, 20], //圈复杂度大于*
    "no-var": 0, //用let或const替代var
    "no-const-assign": 2, //不允许const重新赋值
    "no-debugger": 1, //debugger 调试代码未删除
    "no-dupe-args": 2, //参数重复
    "no-dupe-keys": 2, //对象属性重复
    "no-duplicate-case": 2, //switch-case重复
    "no-func-assign": 2, //函数被赋值
    "valid-typeof": 1, //无效的类型判断
    "no-unreachable": 1, //不可能执行到的代码
    "no-unexpected-multiline": 2, //行尾缺少分号可能导致一些意外情况
    "no-sparse-arrays": 1, //数组中多出逗号
    "no-shadow-restricted-names": 2, //关键词与命名冲突
    "no-undef": 1, //变量未定义
    "no-unused-vars": 1, //变量定义后未使用
    "no-cond-assign": 2, //条件语句中禁止赋值操作

    //object直接量建议写法 : 后一个空格前面不留空格
    "key-spacing": [
      0,
      {
        "beforeColon": false,
        "afterColon": true
      }
    ],

    "block-scoped-var": 1, //变量应在外部上下文中声明，不应在{}代码块中

    //换行调用对象方法  点操作符应写在行首
    "dot-location": [
      1,
      "property"
    ],
    "no-lone-blocks": 1, //多余的{}嵌套
    "no-labels": 1, //无用的标记
    "no-sequences": 1, //禁止可能导致结果不明确的逗号操作符

    //不允许重复声明
    "no-redeclare": [
      1,
      {
        "builtinGlobals": true
      }
    ],
  }
}

可参考：腾讯全端AlloyTeam 团队
https://alloyteam.github.io/eslint-config-alloy/

软实力

独立思考的重要性

人云亦云的人会被最早抛弃

独立思考是一种技能，是不可代替性的重要组成部分，在组织架构、代码开发以及debug的时候显得尤为重要
独立思考不是说一个人去做事情，而是在做事情的时候有主观，在辩证某个想法的时候，如果是自己相信的方向，那么就应该坚持到出结果（whatever fail or success）
独立思考的收获是pure的，因为是自己独自产出的，受到的干扰是最少的，所以是最容易被自己记住的，且产出也是完成度最高的

越早暴露问题越好

最早的暴露问题，是最大的善待自己

特别是刚融入一只队伍的时候，不要害怕出错出丑，该是什么就是什么（不要不懂装懂），遇到问题越早throw出来越能早解决，当你陷入一个泥潭的时候应该越早大声呼救越早有人救你
特别是带新人的同学或是被人带的新人，要时刻check进展，关键时刻要及时介入，直言不讳的指出问题可以减少弯路提高开发效率
没有人是完美的也没有人可以保证永不出bug的，但是无论何时一定要真实，要“直”，不要伪装，要真实，要相信团队的宽容会帮助自己成长

成就感

I'm really niubility

成就感会让人感觉幸福，当我们超出预期的完成某个需求/功能时，个人是有成就感的，适时的释放出来，让团队为你骄傲
成就感会加速一个开发工程师的自驱力，当写出一段awesome的代码自己都能觉得自己帅的不行，这是最简单的获取成就感的方式（so 写出一段高级的code自娱自乐一下吧）
不要满足，不要满足现在的薪水，不要满足现在的职位，不要满足现在的生活，要时刻保持70%饱和度，让自己永远有自驱力去获取剩余的29%，这样的心态会时刻让你保持有新鲜的成绩感

你有一个苹果我有一个梨，如果我们相互分享那我们就收获了一个单位的2种水果

要信任团队，要帮助团队，每一个开发工程师的脑袋里都是一个精彩的0/1世界，大家能加入这个团队，那就说明团队是信任你的，那么也要把信任回馈给团队 => 分享
分享是一次沉淀，你要把自己会的东西share给别人，那么你一定会搞得很清楚，一次成功的分享会让你成为某一个方面的专家
写blog也是另外一种方式的分享，它还会加固你自己technology stack

工程师 or 程序员

What is your position？

工程师在解决问题，程序员在完成任务 => 这是2种人和2种心态
能力不能局限在代码/框架/工具级别，要时刻去思考如何能高效的解决问题，学会使用之后再去翻它的github&源码，在底层挖一挖可能就会收获一些意想不到的东西
业务代码敲得溜，局部瓶颈搞得清（最好能给出解决方案），大方向跑的通