之所以会写这份文档是要下定决心修改自己那写的跟一坨屎一样的垃圾代码规范！相信正在阅读本文档的读者出发点也是如此（可能你的代码规范还没有像一坨屎那么严重）。因为作者工作内容的原因(做单片机开发板的)，此前没有代码规范化的思维，变量，函数的命名随心所欲，大小写混用；代码注释“//”和“/* */”混用等等很多陋习，这样的陋习写出的例程供阅读者学习也会带坏人家哒，所以痛定思痛，一定要改掉这些陋习。在这个看脸的时代，优美的代码风格让人看着都赏心悦目。

当然，代码规范和风格不是用来赏心悦目的，要不然就是花瓶了，代码规范和风格的目的是要编写出简洁明了、可维护、可测试、可靠、可移植、高效的代码。

1、简单、 明了、清晰：

代码写出来重点是给人看的，因此简单、明了、清晰是第一要务！ 代码的可阅读性要高于代码的性能(除非你的代码以后不需要维护，那你写成啥样都无所谓)。简单、明了、清晰的代码也利于后期维护，尤其是当你写的代码交给他人去维护的时候，请不要祸害别人！

2、精简

代码越长越难看懂，这个大家应该都深有体会，一个 1000 多行的函数和一个最多 100 行的函数哪个好看？所以尽量将把函数写的精简。而且代码越长越容易出错，没有用的代码，变量等一定要及时的清理掉！功能类似或者重复的代码应尽可能提炼成一个函数。

3、尽量与原有代码风格保持一致

一个公司内部的代码风格一般都是统一的，但是如果你跳槽到其他公司去，或者有时候因为业务原因需要维护别的公司的代码，此时代码风格出现冲突的话尽可能使用现在维护的代码风格。

4、减少封装

此规则仅适用于作者所在公司，作者公司是做开发板的，所写的所有例程代码都需要开源给客户阅读学习。在编写的过程中会遇到使用很多第三方库，比如 ST 的 HAL 库、 NXP 的 FSL库， LWIP 协议栈、 UCOS 操作系统、 FreeRTOS 操作系统等等，这些第三方库的编码规范和风格各不相同。有人为了统一自己的编码风格会对这些第三方库的 API 函数做封装，如果是做产品的话这样做无可厚非，毕竟为了代码风格的统一，但是作为做开发板的，尽量不要对第三方库做封装！因为每一次封装都会将原有 API 函数的本意遮蔽，读者第一眼看懂这个 API 函数的具体函数，比如 ST 官方的 Cube 库里面就为了兼容自己的代码风格，对 FreeRTOS 的 API 函数做了封装，结果很多客户就问我们为何 ST 官方所调用的任务创建函数和我们的 FreeRTOS 教程不同！他们之间有什么区别？他们之间没有任何区别，只是 ST 对其做了一个简单的封装，结果给学习者带来了困惑！ 如果不做这个封装的话虽然影响到了代码风格的统一，但是却给学习者减少了困惑，提高了学习效率，而提高客户的学习效率是我们公司的第一宗旨！