一、python
1. 命名规范
命名规范很重要,很多时候你的命名能够大致的解释了变量、函数、类是用来做什么的。所以在命名的时候一定要选择贴近的词义,让阅读者可以理解
1.1 包名和模块名
模块应该用简短全小写的名字,如果为了提升可读性,下划线也是可以用的。Python包名也应该使用简短全小写的名字,但不建议用下划线。
1.2 类名
类名一般使用单词首字母大写的约定
推荐:
class CheckFunc:...
糟糕:
# 首字符需大写,同时类名中无需带下划线
class check_func:...
# 全部大写,同时类名中无需带下划线
class CHECK_FUNC:...
1.3 函数名
函数名应该小写,如果想提高可读性可以用下划线分隔。
推荐:
def check_func():...
1.4 变量名
一定要靠近变量的意思,不要使用一些意义不明的参数,如:i,j,k,特别注意永远不要使用字母‘l’(小写的L),‘O’(大写的O),或者‘I’(大写的I)作为单字符变量名。
糟糕:
l = []
i = 0
xxx = [for i in xx]
1.5 常量
常量一般默认全部为大写, 同时一定要表明好注释
推荐
TOTAL = 10 # 订单总页数
# 最大溢出量
MAX_OVERFLOW = 1000
1.6 异常名
因为异常一般都是类,所有类的命名方法在这里也适用。
推荐:
class ErrorInvalidArgument(ApiError):
"""
参数缺失或错误
"""
code = 401001
code_name = 'Invalid_Argument'
message = 'invalid argument.'
zh_message = '参数缺失或错误'
2. 表达式和语句中的空格
2.1 二元运算符中的空格:
推荐:
i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
糟糕:
i=i+1
submitted +=1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)
2.2 关键字参数或者默认参数值:
推荐:
def complex(real, imag=0.0):
return magic(r=real, i=imag)
糟糕:
def complex(real, imag = 0.0):
return magic(r = real, i = imag)
3. 注释
当更新代码时,一定要记得同步更新注释,否则使阅读的人会陷入更糟糕的境况。
3.1 文档字符串
推荐:
"""Return a foobang
Optional plotz says to frobnicate the bizbaz first.
"""
3.2 函数或方法注释
大家在写函数或者方法时,往往会漏掉当前方法或函数的作用,其实这个还是很重要的,这样往往不需要阅读你的逻辑就可以知道你准备干什么
推荐:
"""
def oa_notice_template(project, api, account, cpu, mem):
"""
压测申请模板
:param project: 项目名称
:param api: 接口名称
:param account: 申请人
:param cpu: cpu核数
:param mem: 内存大小
:return:
"""
"""
3.3 其他建议
在编写代码时,阅读者追寻编写人时往往很困难,或者此文件具体是做什么的。这个时候我们稍微添加一些个人信息注释就很好做到追源了。
推荐:
"""
@Description: 接口测试上传
@Author : xxx
@Time : 2021/5/9 11:51 下午
@Site :
@File : http_test_xpa.py
"""
import os
...
4. 代码布局
4.1 缩进
每一级缩进使用4个空格。
推荐:
# 与左括号对齐
foo = long_function_name(var_one, var_two,
var_three, var_four)
# 用更多的缩进来与其他行区分
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
# 挂行缩进应该再换一行
foo = long_function_name(
var_one, var_two,
var_three, var_four)
# 与内容对齐
my_list = [
1, 2, 3,
4, 5, 6,
]
# 与第一行第一个字符对齐
my_list = [
1, 2, 3,
4, 5, 6,
]
糟糕:
# 没有使用垂直对齐时,禁止把参数放在第一行
foo = long_function_name(var_one, var_two,
var_three, var_four)
# 当缩进没有与其他行区分时,要增加缩进
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
my_list = [1, 2, 3, 4, 5, 6]
4.2 行的最大长度
所有行限制的最大字符数为79。
4.3 空行
推荐:
# 类与类之间前后用两个空行隔开
Class A:...
Class B:...
# 类中函数与函数之间前后用一个空行隔开
Class C:
def c_a(self):...
def c_b(self):...
# 函数与函数之间前后用两个空行隔开
def a_run():...
def b_run():...
# 在函数中使用空行来区分逻辑段(谨慎使用)。
def c_run():
# 逻辑A
...
...
# 逻辑B
...
...
4.4 导入
推荐:
- 导入应该按照以下顺序分组:
- 标准库导入
- 相关第三方库导入
- 本地应用/库特定导入
同时在每一组导入之间加入空行。
# 官方标准库导入
import os
import sys
# 第三方库
import arrow
import requests
# 导入本地库
import app
# 以from导入标准库
from datetime import datetime
# 以from导入第三方库
from ldap3 import Server
# 以from导入本地库
from app import DB
from . import create_app # 处理绝对路径过长时可以以相对路径进行替换
5. python编程建议
5.1 关于异常处理:
推荐:
try:
value = collection[key]
except KeyError:
return key_not_found(key)
else:
return handle_value(value)
糟糕:
try:
return handle_value(collection[key])
except KeyError:
return key_not_found(key)
5.2 关于返回结果处理:
不管在任何时候返回结果都需要保持一致。
推荐:
def foo(x):
if x >= 0:
return math.sqrt(x)
else:
return None
def bar(x):
if x < 0:
return None
return math.sqrt(x)
糟糕:
def foo(x):
if x >= 0:
return math.sqrt(x)
def bar(x):
if x < 0:
return
return math.sqrt(x)
5.3 关于True、Fakse的判断:
不要用 == 去和True或者False比较
推荐:
if greeting:
...
糟糕:
if greeting == True:
...
if greeting is True:
...
二、go
1、命名规范
命名是代码规范中很重要的一部分,统一的命名规则有利于提高的代码的可读性,好的命名仅仅通过命名就可以获取到足够多的信息。
Go在命名时以字母a到Z或a到Z或下划线开头,后面跟着零或更多的字母、下划线和数字(0到9)。Go不允许在命名时中使用@、$和%等标点符号。Go是一种区分大小写的编程语言。因此,Manpower和manpower是两个不同的命名。
- 当命名(包括常量、变量、类型、函数名、结构字段等等)以一个大写字母开头,如:Group1,那么使用这种形式的标识符的对象就可以被外部包的代码所使用(客户端程序需要先导入这个包),这被称为导出(像面向对象语言中的 public);
- 命名如果以小写字母开头,则对包外是不可见的,但是他们在整个包的内部是可见并且可用的(像面向对象语言中的 private )
1.1、包命名:package
保持package的名字和目录保持一致,尽量采取有意义的包名,简短,有意义,尽量和标准库不要冲突。包名应该为小写单词,不要使用下划线或者混合大小写。
package demopackage main
1.2、 文件命名
尽量采取有意义的文件名,简短,有意义,应该为小写单词,使用下划线分隔各个单词。
my_test.go
1.3、 结构体命名
- 采用驼峰命名法,首字母根据访问控制大写或者小写
- struct 申明和初始化格式采用多行,例如下面:
// 多行申明
type User struct{Username stringEmail string}// 多行初始化
u := User{Username: "astaxie",Email: "astaxie@gmail.com",}
1.4、 接口命名
- 命名规则基本和上面的结构体类型
- 单个函数的结构名以 “er” 作为后缀,例如 Reader , Writer 。
type Reader interface {Read(p []byte) (n int, err error)}
1.5、变量命名
- 和结构体类似,变量名称一般遵循驼峰法,首字母根据访问控制原则大写或者小写,但遇到特有名词时,需要遵循以下规则:
- 如果变量为私有,且特有名词为首个单词,则使用小写,如 apiClient
- 其它情况都应当使用该名词原有的写法,如 APIClient、repoID、UserID
- 错误示例:UrlArray,应该写成 urlArray 或者 URLArray
- 若变量类型为 bool 类型,则名称应以 Has, Is, Can 或 Allow 开头
var isExist boolvar hasConflict boolvar canManage boolvar allowGitHook bool
1.6、常量命名
常量均需使用全部大写字母组成,并使用下划线分词
const APP_VER = "1.0"
如果是枚举类型的常量,需要先创建相应类型:
type Scheme stringconst (HTTP Scheme = "http"HTTPS Scheme = "https")
1.7、 关键字
下面的列表显示了Go中的保留字。这些保留字不能用作常量或变量或任何其他标识符名称。
2、注释
Go提供C风格的/* */
块注释和C ++风格的//
行注释。行注释是常态;块注释主要显示为包注释,但在表达式中很有用或禁用大量代码。
- 单行注释是最常见的注释形式,你可以在任何地方使用以 // 开头的单行注释
- 多行注释也叫块注释,均已以 /* 开头,并以 */ 结尾,且不可以嵌套使用,多行注释一般用于包的文档描述或注释成块的代码片段
go 语言自带的 godoc 工具可以根据注释生成文档,生成可以自动生成对应的网站( http://golang.org 就是使用 godoc 工具直接生成的),注释的质量决定了生成的文档的质量。每个包都应该有一个包注释,在package子句之前有一个块注释。对于多文件包,包注释只需要存在于一个文件中,任何一个都可以。包评论应该介绍包,并提供与整个包相关的信息。它将首先出现在godoc
页面上,并应设置下面的详细文档。
详细的如何写注释可以 参考:http://golang.org/doc/effective_go.html#commentary
2.1、包注释
每个包都应该有一个包注释,一个位于package子句之前的块注释或行注释。包如果有多个go文件,只需要出现在一个go文件中(一般是和包同名的文件)即可。 包注释应该包含下面基本信息(请严格按照这个顺序,简介,创建人,创建时间):
- 包的基本简介(包名,简介)
- 创建者,格式: 创建人: rtx 名
- 创建时间,格式:创建时间: yyyyMMdd
例如 util 包的注释示例如下
// util 包, 该包包含了项目共用的一些常量,封装了项目中一些共用函数。
// 创建人: hanru
// 创建时间: 20190419
2.2、结构(接口)注释
每个自定义的结构体或者接口都应该有注释说明,该注释对结构进行简要介绍,放在结构体定义的前一行,格式为: 结构体名, 结构体说明。同时结构体内的每个成员变量都要有说明,该说明放在成员变量的后面(注意对齐),实例如下:
// User , 用户对象,定义了用户的基础信息
type User struct{Username string // 用户名
Email string // 邮箱
}
2.3、函数(方法)注释
每个函数,或者方法(结构体或者接口下的函数称为方法)都应该有注释说明,函数的注释应该包括三个方面(严格按照此顺序撰写):
- 简要说明,格式说明:以函数名开头,“,”分隔说明部分
- 参数列表:每行一个参数,参数名开头,“,”分隔说明部分
- 返回值: 每行一个返回值
示例如下:
// NewtAttrModel , 属性数据层操作类的工厂方法
// 参数:
// ctx : 上下文信息
// 返回值:
// 属性操作类指针
func NewAttrModel(ctx *common.Context) *AttrModel {}
2.4、代码逻辑注释
对于一些关键位置的代码逻辑,或者局部较为复杂的逻辑,需要有相应的逻辑说明,方便其他开发者阅读该段代码,实例如下:
// 从 Redis 中批量读取属性,对于没有读取到的 id , 记录到一个数组里面,准备从 DB 中读取
xxxxxxxxxxxxxxxxxxx
2.5、注释风格
统一使用中文注释,对于中英文字符之间严格使用空格分隔, 这个不仅仅是中文和英文之间,英文和中文标点之间也都要使用空格分隔,例如:
// 从 Redis 中批量读取属性,对于没有读取到的 id , 记录到一个数组里面,准备从 DB 中读取
上面 Redis 、 id 、 DB 和其他中文字符之间都是用了空格分隔。
- 建议全部使用单行注释
- 和代码的规范一样,单行注释不要过长,禁止超过 120 字符。
3、代码风格
3.1、缩进和折行
- 缩进直接使用 gofmt 工具格式化即可(gofmt 是使用 tab 缩进的);
- 折行方面,一行最长不超过120个字符,超过的请使用换行展示,尽量保持格式优雅。
我们使用Goland开发工具,可以直接使用快捷键:ctrl+alt+L,即可。
3.2、语句的结尾
Go语言中是不需要类似于Java需要冒号结尾,默认一行就是一条数据
如果你打算将多个语句写在同一行,它们则必须使用 ;
3.3、括号和空格
括号和空格方面,也可以直接使用 gofmt 工具格式化(go 会强制左大括号不换行,换行会报语法错误),所有的运算符和操作数之间要留空格。
// 正确的方式
if a 0 {}
// 错误的方式
if a0 // a ,0 和 > 之间应该空格
{ // 左大括号不可以换行,会报语法错误
}
3.4、import 规范
import在多行的情况下,goimports会自动帮你格式化,但是我们这里还是规范一下import的一些规范,如果你在一个文件里面引入了一个package,还是建议采用如下格式:
import ("fmt")
如果你的包引入了三种类型的包,标准库包,程序内部包,第三方包,建议采用如下方式进行组织你的包:
import ("encoding/json""strings""myproject/models""myproject/controller""myproject/utils""github.com/astaxie/beego""github.com/go-sql-driver/mysql")
有顺序的引入包,不同的类型采用空格分离,第一种实标准库,第二是项目包,第三是第三方包。
在项目中不要使用相对路径引入包:
// 这是不好的导入
import “../net”// 这是正确的做法
import “github.com/repo/proj/src/net”
但是如果是引入本项目中的其他包,最好使用相对路径。
3.5、错误处理
- 错误处理的原则就是不能丢弃任何有返回err的调用,不要使用 _ 丢弃,必须全部处理。接收到错误,要么返回err,或者使用log记录下来
- 尽早return:一旦有错误发生,马上返回
- 尽量不要使用panic,除非你知道你在做什么
- 错误描述如果是英文必须为小写,不需要标点结尾
- 采用独立的错误流进行处理
// 错误写法
if err != nil {// error handling
} else {// normal code
}// 正确写法
if err != nil {// error handling
return // or continue, etc.
}// normal code
3.6、测试
单元测试文件名命名规范为 example_test.go 测试用例的函数名称必须以 Test 开头,例如:TestExample 每个重要的函数都要首先编写测试用例,测试用例和正规代码一起提交方便进行回归测试
三、shell
1、注释
1.1 头部注释
#!/bin/bash
# vim:sw=4:ts=4:et
<<INFO
SCRIPYT:test.sh
AUTHOR:anqixiang<邮箱号>
DATE:2021-09-12
DESCRIBE:描述脚本主要功能
SYSTEM:适配哪些操作系统
WARNING:警告信息
VERSION:1.1.0<可选>
MODIFY:记录修改信息,方便查看和维护
INFO
1.2 单行注释与多行注释
单行注释以#号开头,如
#修改IP地址
多行注释表示方法(INFO可以用别的标识代替,但需与结尾保持一致)
<<INFO
SCRIPYT:test.sh
AUTHOR:anqixiang<邮箱号>
DATE:2021-09-12
INFO
2、排版规范
2.1 程序块采用缩进,缩进为4个空格
举例
while true
do
sleep 5
done
2.2 函数
2.2.1 函数功能注释
所有的函数注释应该包含:
- 函数的描述
- 全局变量的使用和修改
- 使用的参数说明
- 返回值,而不是上一条命令运行后默认的退出状态
示例:
#######################################
# Cleanup files from the backup dir
# Globals:
# BACKUP_DIR
# BACKUP_SID
# Arguments:
# None
# Returns:
# None
#######################################
cleanup() {
...
}
2.2.2 函数编写
函数首字母大写,并用“_”隔开,如Modify_Ip函数名后面必须加小括号()第一个大括号与小括号之间保留一个空格第二个大括号顶格单独占一行同级别的代码块要左对齐举例
Modify_Ip() {
command1
command2
if 表达式;then
command 3
else
command 4
fi
}
2.3 命令较长需分行书写,在低优先级操作符处划分新行,用'\'标识
command 1 | command 2 \
&& command 3 \
|| command 4
2.4 一行只写一条语句
command 1;command 2 #不推荐
command 1 #推荐
command 2
2.5 逻辑运算符&&、||和重定向、管道符前后要留空格
command 1 && command 2
command 1 | command 2
# 长命令管道换行连接,管道放置于下一个命令开头,缩进4个空格
command1 \
| command2 \
| command3 \
| command4
2.6 一个函数只完成一个功能,且不能超过100行
2.7 case语句格式
case $value in
val1)
command 1
;;
a|b)
command 2
;;
*)
command 3
esac
2.8.注释与上面的代码用空行隔开
command 1
[空一行]
#注释内容
command 2
2.9 循环和判断
for循环
for i in 1..3
do
if [[ $i -eq 1 ]];then
echo "等于1"
elif [[ $i -eq 2 ]];then
echo "等于2"
else
echo "等于3"
fi
done
while循环
while read line
do
...
done < file.txt
或者
command | while read line
do
...
done
3、变量规范
3.1.变量名由字母、数字、下划线组成, 只能以字母、下划线开头
3.2.尽量减少全局变量,可在变量前面加local使其成为局部变量
local name=""
for name in a b
do
echo ${name}
done
全局变量仅在当前Shell有效,使用export定义的全局变量在所有子进程中依然有效
3.3.环境变量和全局变量大写,局部变量小写(使用下划线连接,如host_ip )
readonly PATH_TO_FILES='/some/path' #不能修改的变量添加readonly 属性
declare -xr BACKUP_SID='PROD'
declare解释
功能介绍:声明变量的属性,如果使用declare,后面没有任何参数,那么bash就会主动将所有变量名与内容都调出来,just as set.
语 法:declare [-aixr] variable
参数说明:
-a :将后面的variable定义为数组
-i :将后面的variavle定义为整数数字
-x :用法与export一样,就是将后面的variable变成环境变量
-r :将一个variable的亦是设置成只读,读变量不可更改内容,也不能unset
3.4.引用变量用\${value}
val=${value}[[ ${value} == "test" ]] && command 1
3.5.不能被清除和修改的变量通过readonly variable声明
3.6 常用变量集中写在脚本开头,便于修改
3.7.对变量赋空值时,建议使用unset
unset sum
3.8.用ln创建软链接文件,必须先判断文件是否存在,存在时必须先删除,然后再创建软链接
[ -h /data ] && rm -rf /data
ln -sf /home/data /data
3.9 命令替换推荐使用$(),并用双引号括起来,在groovy中建议使用``(反撇号)
local_ip="$(ip addr | grep ......)"
4、安全清理
4.1 环境变量和history不能有敏感信息
5、建议
- 判断推荐使用[[ ]]
- 判断命令是否存在用command -v代替which(command是内部命令,系统自带;如果命令不存在不会输出任何信息)
- 路径尽量保持绝对路径,不易出错,如果非要用相对路径,最好用./修饰
- 简单的if尽量使用&& ||,写成单行。比如[[ x > 2]] && echo x
- 使用rm删除目录的时候建议先cd到父目录,再删除子目录
四、前端
一.编程规约
(一) 命名规范
1.1.1 项目命名
全部采用小写方式,以中线分隔。
正例:mall-management-system
反例:mall_management-system / mallManagementSystem
1.1.2 目录命名
全部采用小写方式, 以中划线分隔,有复数结构时,要采用复数命名法, 缩写不用复数。
正例:scripts/styles/components/images/utils/layouts/demo-styles/demo-scripts/img/doc
反例:script/style/demo_scripts/demoStyles/imgs/docs
【特殊】VUE 的项目中的 components
中的组件目录,使用 kebab-case
命名。
正例:head-search/page-loading/authorized/notice-icon
反例:HeadSearch/PageLoading
【特殊】VUE 的项目中的除 components
组件目录外的所有目录也使用 kebab-case
命名。
正例:page-one/shopping-car/user-management
反例:ShoppingCar/UserManagement
1.1.3 JS、CSS、SCSS、HTML、PNG 文件命名
全部采用小写方式, 以中划线分隔。
正例:render-dom.js/signup.css/index.html/company-logo.png
反例:renderDom.js/UserManagement.html
1.1.4 命名严谨性
代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式。 说明:正确的 英文拼写和语法可以让阅读者易于理解,避免歧义。注意,即使纯拼音命名方式也要避免采用
正例:henan/luoyang/rmb 等国际通用的名称,可视同英文
反例:DaZhePromotion [打折] / getPingfenByName() [评分] / int 某变量 = 3
杜绝完全不规范的缩写,避免望文不知义:
反例:AbstractClass
“缩写”命名成 AbsClass
;condition
“缩写”命名成 condi
,此类随意缩写严重 降低了代码的可阅读性。
(二) HTML 规范 (Vue Template 同样适用)
1.2.1 HTML 类型
推荐使用 HTML5 的文档类型申明:
(建议使用 text/html 格式的 HTML。避免使用 XHTML。XHTML 以及它的属性,比如 application/xhtml+xml 在浏览器中的应用支持与优化空间都十分有限)。
规定字符编码
IE 兼容模式
规定字符编码
doctype 大写
正例:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
<meta charset="UTF-8" />
<title>Page title</title>
</head>
<body>
<img src="images/company-logo.png" alt="Company">
</body>
</html>
1.2.2 缩进
缩进使用 2 个空格(一个 tab);
嵌套的节点应该缩进。
1.2.3 分块注释
在每一个块状元素,列表元素和表格元素后,加上一对 HTML 注释。
1.2.4 语义化标签
HTML5 中新增很多语义化标签,所以优先使用语义化标签,避免一个页面都是 div 或者 p 标 签。
正例
<header></header>
<footer></footer>
反例
<div>
<p></p>
</div>
1.2.5 引号
使用双引号(" ") 而不是单引号(’ ') 。
正例:<div class=”box”></div>
反例:<div class=’box’></div>
(三) CSS 规范
1.3.1 命名
类名使用小写字母,以中划线分隔
id 采用驼峰式命名
scss 中的变量、函数、混合、placeholder 采用驼峰式命名
ID 和 class 的名称总是使用可以反应元素目的和用途的名称,或其他通用的名称,代替表象和 晦涩难懂的名称。
不推荐:
.fw-800 {
font-weight: 800;
}
.red {
color: red;
}
推荐
.heavy {
font-weight: 800;
}
.important {
color: red;
}
1.3.2 选择器
1) css 选择器中避免使用标签名
从结构、表现、行为分离的原则来看,应该尽量避免 css 中出现 HTML 标签,并且在 css 选择 器中出现标签名会存在潜在的问题。
2) 使用直接子选择器
很多前端开发人员写选择器链的时候不使用 直接子选择器(注:直接子选择器和后代选择器的
区别)。有时,这可能会导致疼痛的设计问题并且有时候可能会很耗性能。然而,在任何情况下,
这是一个非常不好的做法。如果你不写很通用的,需要匹配到 DOM 末端的选择器, 你应该总 是考虑直接子选择器。
不推荐:
.content .title {
font-size: 2rem;
}
推荐:
.content > .title {
font-size: 2rem;
}
1.3.3 尽量使用缩写属性
不推荐:
border-top-style: none;
font-family: palatino, georgia, serif;
font-size: 100%; line-height: 1.6;
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;
推荐:
border-top: 0;
font: 100%/1.6 palatino, georgia, serif;
padding: 0 1em 2em;
1.3.4 每个选择器及属性独占一行
不推荐:
button {
width: 100px;
height: 50px;
color: #fff;
background: #00a0e9;
}
推荐:
button {
width: 100px; height: 50px;
color: #fff;
background: #00a0e9;
}
1.3.5 省略 0 后面的单位
不推荐:
div {
padding-bottom: 0px;
margin: 0em;
}
推荐:
div {
padding-bottom: 0;
margin: 0;
}
1.3.6 避免使用 ID 选择器及全局标签选择器防止污染全局样式
不推荐:
#header {
padding-bottom: 0px;
margin: 0em;
}
.header {
padding-bottom: 0px;
margin: 0em;
}
(四) LESS 规范
1.4.1 代码组织
1) 将公共 less 文件放置在 style/less/common 文件夹
例: // color.less,common.less
2) 按以下顺序组织
1、@import;
2、变量声明;
3、样式声明;
@import "mixins/size.less";
@default-text-color: #333;
.page {
width: 960px;
margin: 0 auto;
}
1.4.2 避免嵌套层级过多
将嵌套深度限制在 3 级。对于超过 4 级的嵌套,给予重新评估。这可以避免出现过于详实的 CSS 选择器。避免大量的嵌套规则。当可读性受到影响时,将之打断。推荐避免出现多于 20 行的嵌 套规则出现。
不推荐:
.main {
.title {
.name {
color: #fff;
}
}
}
```
**推荐:**
```css
.main-title {
.name { color: #fff; }
}
(五) Javascript 规范
1.5.1 命名
1) 采用小写驼峰命名 lowerCamelCase,代码中的命名均不能以下划线, 也不能以下划线或美元符号结束
反例:name / name / name$
2) 方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风 格,必须遵从驼峰形式
正例: localValue / getHttpMessage() / inputUserId
其中 method 方法命名必须是 动词 或者 动词+名词 形式
正例: saveShopCarData /openShopCarInfoDialog 反例: save / open / show / go
特此说明,增删查改,详情统一使用如下 5 个单词,不得使用其他(目的是为了统一各个端)
add / update / delete / detail / get
附: 函数方法常用的动词:
get 获取/set 设置,
add 增加/remove 删除,
create 创建/destory 销毁,
start 启动/stop 停止,
open 打开/close 关闭,
read 读取/write 写入,
load 载入/save 保存,
begin 开始/end 结束,
backup 备份/restore 恢复,
import 导入/export 导出,
split 分割/merge 合并,
inject 注入/extract 提取,
attach 附着/detach 脱离,
bind 绑定/separate 分离,
view 查看/browse 浏览,
edit 编辑/modify 修改,
select 选取/mark 标记,
copy 复制/paste 粘贴,
undo 撤销/redo 重做,
insert 插入/delete 移除,
add 加入/append 添加,
clean 清理/clear 清除,
index 索引/sort 排序,
find 查找/search 搜索,
increase 增加/decrease 减少,
play 播放/pause 暂停,
launch 启动/run 运行,
compile 编译/execute 执行,
debug 调试/trace 跟踪,
observe 观察/listen 监听,
build 构建/publish 发布,
input 输入/output 输出,
encode 编码/decode 解码,
encrypt 加密/decrypt 解密,
compress 压缩/decompress 解压缩,
pack 打包/unpack 解包,
parse 解析/emit 生成,
connect 连接/disconnect 断开,
send 发送/receive 接收,
download 下载/upload 上传,
refresh 刷新/synchronize 同步,
update 更新/revert 复原,
lock 锁定/unlock 解锁,
check out 签出/check in 签入,
submit 提交/commit 交付,
push 推/pull 拉,
expand 展开/collapse 折叠,
enter 进入/exit 退出,
abort 放弃/quit 离开,
obsolete 废弃/depreciate 废旧,
collect 收集/aggregate 聚集
3) 常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚, 不要嫌名字长
正例: MAX_STOCK_COUNT 反例: MAX_COUNT
1.5.2 代码格式
1) 使用 2 个空格进行缩进
正例:
if (x < y) {
x += 10;
} else {
x += 1;
}
2) 不同逻辑、不同语义、不同业务的代码之间插入一个空行分隔开来以 提升可读性
说明:任何情形,没有必要插入多个空行进行隔开。
1.5.3 字符串
统一使用单引号(‘),不使用双引号(“)。这在创建 HTML 字符串非常有好处: 正例:
let str = 'foo';
let testDiv = '<div id="test"></div>';
反例:
let str = 'foo';
let testDiv = "<div id='test'></div>";
1.5.4 对象声明
1) 使用字面值创建对象
正例:let user = {};
反例:let user = new Object();
2) 使用字面量来代替对象构造器
正例:var user = { age: 0, name: 1, city: 3 };
反例:
var user = new Object();
user.age = 0;
user.name = 0;
user.city = 0;
1.5.5 使用 ES6+
必须优先使用 ES6+ 中新增的语法糖和函数。这将简化你的程序,并让你的代码更加灵活和可复 用。比如箭头函数、await/async , 解构, let , for…of 等等。
1.5.6 括号
下列关键字后必须有大括号(即使代码块的内容只有一行):if, else, for, while, do, switch, try,catch, finally, with。
正例:
if (condition) {
doSomething();
}
反例:
if (condition) doSomething();
1.5.7 undefined 判断
永远不要直接使用 undefined 进行变量判断;使用 typeof 和字符串’undefined’对变量进行判断。 正例:
if (typeof person === 'undefined') { ... }
反例:
if (person === undefined) { ... }
1.5.8 条件判断和循环最多三层
条件判断能使用三目运算符和逻辑运算符解决的,就不要使用条件判断,但是谨记不要写太长的 三目运算符。如果超过 3 层请抽成函数,并写清楚注释。
1.5.9 this 的转换命名
对上下文 this 的引用只能使用 ’self’ 来命名。
1.5.10 慎用 console.log
因 console.log 大量使用会有性能问题,所以在非 webpack 项目中谨慎使用 log 功能。