CS From the Groud Up [T1] – Coding Style

见字如面，读码识人。

什么是代码风格

代码风格，也叫编程约定、代码约定、代码规范等等，和行文风格类似，是指源代码的排版、命名和逻辑组成方法的集合。代码风格更具体地关心以下内容的组织方式：

• 变量和方法的名字
• 缩进和换行
• 注释的格式
• 代码块的布局

为什么要有代码风格

保持代码风格的统一是为了降低心智负担。

这里的降低心智负担并不意味着拥有良好的代码风格可以使得难懂的算法变得简单，而是指掌握代码的大概框架和流程的速度变快。就像读数学书，排版合适的书至少你能耐着性子看下去并思考书中阐述的定理和问题；印刷粗糙字迹潦草的册子刚看开头就会让人失去继续的勇气。

同时，保持代码风格有益团队之间的合作。当每个人都使用统一的书写习惯时，对代码的阅读的重心就可以转移到对逻辑的理解上，而无需先将不同于自己的风格的代码先转写再理解。

以及，保持一个良好的代码习惯可以让你在一个月之后回头读代码的时候不至于想掐死你自己。对于经常需要回顾历史代码并做出改进的人而言，能够快速读懂过去自己的想法而不需要自己再想一遍是非常重要的。

但是我打竞赛

竞赛不适用此文章。

因为竞赛关注的是如何在尽量短的时间内解出尽量多的数学题，它和生产要求不同。生产要求在可接受的时间内为一个现实世界问题创建一套解决方案，而且这套解决方案通常需要多人协作。

竞赛的编码模式是一发入魂、用过即丢的，即这段代码提交后如果通过就立刻会被忘记，不需要之后再维护。即使在赛后为了积攒经验，也只需要记住解题的思路并重写即可——而且这个思路通常是平凡的、原子的；生产的编码模式则是一次部署、终身负责的，即这段代码在上线后依旧可能需要调整和维护。而且更有可能，系统的初始设计者和之后的维护者不是同一个人，甚至不是同一个团队。系统的业务逻辑尽管也是平凡的，但却是错综复杂的，即使有超人的记忆力，也很难记住全部细节。

所以，竞赛党就不需要给自己设这么多条条框框了——这是一个工程问题。

如何形成自己的代码风格

形成代码风格的最简单的方法是直接使用已有的代码风格。不同的大厂有略微不同的编码风格指南，可以以谷歌的各大编程语言代码风格和微软的《C# 编码约定》为参考。

同时，也有工具用于检查和统一代码风格，比如 ESLint 用于检查 JavaScript 和 TypeScript 的代码风格以及 Go 本身自带的 go fmt 命令进行风格统一。大多数现代 IDE 也有代码格式化工具将各种语言的代码调整到一定的风格。但大多数工具只关心最基本的缩进，命名等内容仍需要开发者自行调整和理解。

当然，最实际的方案就是多写代码、多读代码，尤其是要不时回过头看一看过去的自己写的代码。再多的说教都比不上一次体验。