无人问津的自留地 >>> 无人问津的自留地 >>>

我始终相信,走过平湖烟雨,岁月山河,
那些经历劫数,尝遍百味的人,会更加生动而干净。

目录
代码规范 | 好的代码应该是便于维护的
/  

代码规范 | 好的代码应该是便于维护的

好的命名比注释要好

# 团队统一定义标记:
TODO  待处理的问题
FIXME  已知有问题的代码
HACK 不得不采用的粗糙的解决方案

样式修改 - 要么原生 JS 要么 JQuery  用 submit 事件

复制过来不用的代码都删掉

源代码中的 html 注释是一种厌物, 增加阅读难度

注释

注释模板 不要留空

# 典型的烂注释:
不恰当的信息
废弃的注释
冗余注释
糟糕的注释
注释掉的代码
# 唯一真正好的注释是你想办法不去写的注释:
不要有循规式注释,比如 setter/getter 注释
不要添加日志式注释,比如修改时间等信息( git 可以做的事情)
注释一定是表达代码之外的东西,代码可以包含的内容,注释中一定不要出现
如果有必要注释,请注释意图(why),而不要去注释实现(how),大家都会看代码
适当添加警示注释

命名

了解一些设计模式,这样看到名字里有 proxy,builder,factory 之类的,就心领神会了

代码都是分模块的,有的是 core,有的是 util,parser 之类的

尽可能使用标准命名方法,比如设计模式,通用学术名词等
命名要找更有表现力的词
使用更专业的词,比如不用 get 而使用 fetch 或者 download
避免空泛的名字,像 tmp
使用具体的名字来细致的描述事物
给变量名带上重要的细节,比如加上单位ms等
为作用域大的名字采用更长的名字,作用域小的使用短名字
变量类型为布尔值表达加上 is,has ,can ,should 这样的词会更明确
变量名称长短应该与其作用域对应
别害怕长名称,长而具有描述性的名称比短而令人费解的名称好
函数名称应该说明副作用,名称应该表达函数,变量或类的一切信息,请不要掩盖副作用,比如 CreateAndReturnXXX

commit

commit 的 message 一定要规范

feat:新功能(feature)
fix:修补bug
docs:文档(documentation)
style: 格式(不影响代码运行的变动)
refactor:重构(即不是新增功能,也不是修改bug的代码变动)
test:增加测试
chore:构建过程或辅助工具的变动

如何避免自己写的代码成为别人眼中的一坨屎!


标题:代码规范 | 好的代码应该是便于维护的
版权声明:本文为博主「fpdan」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.fpdan.cn/articles/2019/01/12/1547296855000.html