代码规范类思考

如果一个人处于解决问题的位置，却并不受问题困扰，那就采取一些行动使他能亲身体验到问题

在日常中总是存在着需要的规范问题：嵌入式程序设计规范、原理图设计规范、PCB设计规范...

但是试图用规范来消除重复错误的尝试可能是徒劳的！

规范能够起到多大作用，取决于自身的理解程度和执行程度。有些规范你只是知道用，却不知道为什么，导致即使你真正的记忆了，也无法使用，因为你并没有理解规范的作用

如果对一个事物理解的不够透彻，看到的只是局部，是一个个离散的点或线段，形成不了知识面，容易产生错误观点。就像盲人摸象一样，摸到耳朵的就认为大象是蒲扇、摸到腿就认为大象是柱子...这些都是错误的观点。

如果一个事物我们没有亲身体验过，只是靠语言描述，是很难理解的。就像你无法向盲人解释红色是什么一样：必须亲眼看到了，才能知道其含义。

对事物的理解过程，大都是从错误中学习的，如果没有遇到错误，可能都不会意识到其中蕴含的道理

通过对错误事件的处理，会对这个问题的理解程度加深，这是进步的表现

换句话说，大部分人需要经历犯错和纠错的过程，如果你在学习过程中一直是一帆风顺的话，那么你以后将会犯很多错。只有犯的错误足够多，才更有可能避免类似错误！所以如果将消除重复错误的希望寄托在一个文档上，恐怕带来的只有失望。

对规范的理解能力是要在实践中积累的，然而我们缺乏的就是积累，所以更难理解规范。就像刚开始烧菜，总是要经过手忙脚乱的过程，不清楚放多少油盐酱醋合适，更不要提火候。而比不能理解规范更糟糕的事情是误解规范，因此为了更好的理解以后的知识

在编程界，重复 可能是软件中一切邪恶的根源 --  能力：避免重复代码如何实现？提高自己的代码能力，代码能力不仅仅是逻辑思维能力也是设计能力

无论是《程序员修炼之道》、还是《代码整洁之道》，它们都强调要遵循 DRY 原则 ：系统中的每一项知识都必须具有单一、无歧义、权威的表示。重复代码是违反 DRY 原则最为明显的例子。

为何称其为 DRY ？DRY - Don’t Repeat Yourself（不要重复你自己）。

所以对编程而言，消除重复是一件天大的事情。甚至有人说“自函数发明以来，软件开发领域的所有创新都是在不断尝试从代码中消灭重复”。
 

 当你实现功能后，你需要自发的追求代码质量。代码是需要不断重构的，只有不断的重构升级，你的代码质量才会提升

代码审查的标准很简单：

        不能有重复
        不能有魔法数
        函数体不大于 80 行
        函数嵌套不大于 3 层
        圈复杂度不大于 15
        遵循单一职责原则：一行代码只做一件事、一个变量只做一件事、一个函数只做一件事
        命名要准确清晰。
提升代码质量的重构，比如要求用宏来替换魔法数、用函数封装重复代码等，

在我看来，提升代码质量非常重要，高质量代码更清晰，所以可以减少BUG的产生，高质量代码更好修改，所以更适应未来的需求变化