之前做的是一个二次开发的项目，只有两个人，那时候在原有框架的基础上，代码完全由自己来控制，想怎么写就怎么写，完成功能即可。完成了那个项目后，直接进入另一个项目。
由于我是中途进入这个项目组的，在编码前，我先了解了我的任务，搞明白后， 开始熟悉他们现用的框架。搞明白了框架以后，就可以写代码了。他们之前有过代码规范，也没有让我看，带我把模块都写到80%的时候，他们说我的代码不规范，没有按照他们的要求来，当时我还很气愤，我写了这么多了你给我说我的代码不规范，我写之前你咋不让我看代码规范呢。
然后我看了一下他们的代码规范，就开始改代码了。按照他们的规范（方法名、类名、变量名）改好了，他们审查后还说不规范。我就让他们一行一行的看我的代码（包括前后台代码都看了），听他们说的过程中，我的脸色越来越差劲，那苛刻劲，简直不叫代码规范，简直就是脑残做法。
我想说的是，代码规范是有必要的，但是不要太脑残。
一 编码规范的作用
- 提高可读性 “任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优先的程序员。”编码规范，帮助我们写出人类容易理解的代码，它为我们提供了最基本的模板，良好的编码风格，使代码具有一定的描述性，可以通过名字来获取一些需要IDE才能得到的提示，如可访问性、继承基类等。
- 统一全局，促进团队协作 开发软件是一个团队活动，而不是个人的英雄主义。编码规范，要求团队成员遵守这一统一的全局决策，这样成员之间可以轻松地阅读对方的代码，所有成员正以一种清晰而一致的风格进行编码。而且，开发人员也可以集中精力关注他们真正应该关注的问题——自身代码的业务逻辑，与需求的契合度等局部问题。
- 有助于知识传递，加快工作交接 风格的相似性，能让开发人员更迅速，更容易理解一些陌生的代码，更快速地理解别人的代码。因为，他和你的代码风格是一样的，你没有必要对他的一些个性化风格进行揣测。这样的好处是开发人员可以很快的接手项目组其他成员的工作，快速完成工作交接。
- 减少名字增生，降低维护成本 在没有规范的情况下，和容易为同一类型的实例起不同的名字。对于以后维护这些代码程序员来说会产生疑惑。
- 强调变量之间的关系，降低缺陷引人的机会 命名可以表示一定的逻辑关系，是开发人员在使用时保持警惕，从而一定程度上减少缺陷被引人的机会。
- 提高程序员的个人能力 不可否认，每个程序员都应该养成良好的编码习惯，而编码规范无疑是教材之一。从一个程序员的代码本身能看出很多东西。所以，即便是为了自身发展，作为程序员也没有理由抵制这种规则的存在。你可能没有认识到，我们正默默地得益于编码规范。
在高质量的软件中，你可以看到“架构的概念完整性”与“底层实现”之间的关系。“实现”与“架构”必须是清晰一致的，这种内在的、固有的一致性，需要编码规范来维系。如果没有这种统一的约定，那么我们做出的东西可能会充斥着各种不同的风格，显得混乱且难以理解。团队成员之间可能很不理解彼此之间的想法，甚至是相互抨击。各种编码风格上的差异会不断扩大，而代码质量则不断下降。而且，团队成员会花费时间在理解不同编程风格之间的差异，而没有专注于真正应该解决的问题。这样的时间消耗是难以接受的。所以，在每一个高质量代码的背后，一定存在着一份优秀的编码规范。
然而，也必须认识到编码规范不是“物神”。编码规范仅仅是一个全局性质的规范，它只不过是一种编程约定，不能解决更深层次的问题。就像一篇格式漂亮但内容糟糕的论文不能被发表一样，你不能仅靠一个规范来摆脱软件作坊。而且，在编码规范中不宜包含那些冗长的开发技巧。我认为，对于代码是最佳实践应该是代码审查所要解决的，应该避免将编码规范写成一部关于重构的教科书。