代码规范

更新: 2/10/2025 字数: 0 字 时长: 0 分钟

代码质量

在工作中经历中，一个好的代码对于优秀的团队来说至关重要，能够提高团队的协作效率，减少不必要的麻烦。 当然要做到这一点，需要团队成员共同参与，共同提高。 对于好的代码，大家都有不同的看法，但是好的代码能够带来的好处是显而易见的。简单列举如下：

• 好的代码在面对需求变更时，能够快速适应，不会因为需求变更而产生大量的修改。
• 好的代码能够多样的复用，减少代码出错的几率。
• 好的代码能够提高团队成员的协作效率，减少不必要的沟通成本。
• 好的代码能够提高团队成员的编码水平，减少因为写错而产生的bug。

好的代码带来的好处远不止这些，作为一个合格的程序员，书写好的代码是必备的技能之一。是技术的基础，是一切美好的开始。 当然编写代码的目的是实现业务需求，有人可以为此买单，没有业务需求的编写代码都是没有意义的。

可读性（readability）

代码的可读性，我认为是衡量代码质量的一个最核心的指标。能够让不同能力水平的人快速理解代码的功能，减少不必要的思考时间。在编写代码时，时刻要考虑代码的可读性、理解性，让代码能够快速被他人理解。 代码的可读性在非常大的程度上影响着代码的维护性，毕竟是修改代码还是新增代码，首先需要的是读懂代码，然后才能修改或者新增。

可复用性（reusability）

代码的可复用性可以理解尽量减少重复代码的编写，复用已有的代码，可以大大减少代码出错的几率，应对需求变更时，能够快速适应。 为了提高代码的可复用性，在设计代码时，一般会遵循一些原则，比如单一职责原则、接口隔离原则等。以实现解耦、高内聚、低耦合、模块化等来提高代码的复用性。

可测试性（testability）

代码的可测试性对于复杂的系统来说尤为重要，代码片段的单元测试能够在不了解代码细节的情况下，快速验证代码的正确性，提高代码的健壮性和复用性。

可扩展性（extensibility）

代码的扩展性对代码的编写和系统的设计有着很大的影响，好的代码设计能够让系统在需求变更时，快速适应，减少不必要的修改。但要做具有很好扩展性的代码是不容易的，需要设计者对业务领域的足够了解，对可扩展点的敏感分析，对系统架构的足够了解。 纵观具备可扩展性的代码都需要经过一定的积累和沉淀，才能做到恰到好处的好代码。既不过度设计，不浪费时间，又能很好快速适应需求变更。

代码风格（style）

在团队中一致的代码风格可以让不同岗位不同能力的人快速找到自己需要的代码位置，减少不必要的沟通和管理成本。

代码规范

• 满足业务需要：代码是来实现业务的，如果业务都实现不了，代码也就没什么价值了
• 代码尽可能的清晰明了：就是让小白也能看懂你的代码
• 代码尽可能的少：在保证清晰明了的前提下，能少一行少一行，能少一个类少一个类，能少一行注释少一行注释
• 代码尽可能复用性和模块化：在保证清晰明了和尽可能少的前提下，能复用的代码尽量复用，能模块的尽量模块

英文单词命名规范

无论前端代码还是后端代码、异或其他代码，都是由一个个单词组成的，所以一个好的单词影响着代码的本身，所以定义如下：

1. 一定要用英文，且单词正确，不要用汉语拼音。
2. 英文单词一定要使用常用词语，不要使用生僻词。
3. 英文单词要符合业务需求，不要使用无意义的单词。
4. 合理区分名词和动词，在大部分编程中，项目名、类名、表名等都是名词，而具体的方法名应该是动词异或动名词。
5. 各端命名保持一致，比如：前端命名使用中划线连接，后端使用下划线连接。

   比如之前遇到过这么一个功能，OA办公系统的`通知`功能，各个端定义为：
   - 后端:`notice`, （NoticeController, 表：t_notice）
   - 前端用成了`news`， （news-list.vue， /news/news-list）
   - 移动端用成了`message`，(MessageFragment)
   - 最后再对接的时候，懵逼了，懵了，懵了，懵了

注释规范

代码注释不是为了写注释而写注释，而是为了让代码能够被他人理解。 注释并不是越多越好，当注释过多，维护代码的同时，还需要维护注释，不仅变成了一种负担，也与当初添加注释的初衷背道而驰。 写注释的目的是让别人能够快速理解你的代码，所以注释一定要做到简明扼要、准确无误。

规范脚本

EditorConfig

.editorconfig 文件用于定义代码格式，避免在 IDE 中检查代码时出现 Code Style 的不一致。

# EditorConfig 用于在 IDE 中检查代码的基本 Code Style
# @see: https://editorconfig.org/

[*]
end_of_line = lf
indent_size = 4
indent_style = space
max_line_length = 256
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
max_line_length = off
trim_trailing_whitespace = false

[*{js,ts,tms,vue,css,lass,scss,html}]
indent_size = 2

[*.{yml,yaml,json}]
indent_size = 2

GitAttributes

.gitattributes 文件用于定义 Git 仓库中文件的行尾处理方式。

*.js linguist-language=java
*.html linguist-language=java

# 对于以 .txt 结尾的文件，将其视为文本文件
*.txt text

# 对于以 .png、.jpg 或 .gif 结尾的文件，将其视为二进制文件
*.png binary
*.jpg binary
*.gif binary

# 对于特定路径下的文件，使用不同的换行符处理方式
*.txt eol=lf
*.sh eol=lf
*.lic eol=lf
*.cpp eol=crlf

# 指定合并时使用的策略
*.docx merge=ours