当提到编码规范，自然而然就会想到约束，没错，编程规范本来就会约束开发人员的编码风格。 但是约束并不是所期望的最终目的，约束只是一种表现形式，关键在于建立编码过程中的一种秩序， 以及团队编码风格的统一和稳定，从而提高编码质量，进而提高产品的质量。
当下的我们处于一个需要团队协同作战的世界，一个项目可能需要几个人、十几个人或几十几百人的技术团队，而在产品的生命周期中可能会经历多个项目， 在此期间，人来人往，人走人留，当新来的团队成员在读他的前任留下的代码时，如果团队内部没有一个统一的规范，可能会出现一系列的问题。如： 不知道变量名的意思，莫名其妙的函数定义，搞不清的类实现等等。这些问题会让新来的成员相当纠结难过， 从而给他们一种挫败感，他们熟悉项目代码的时间就会比较长，比较辛苦。 这只是没有编码规范所带来的一个比较显著的问题而已。
每个公司，每个团队都有其文档化或潜规则的编码规范，这里我们不谈具体的规范，只谈“风月”。 我们认同在编码过程中应该遵循的两条原则：
- 代码不仅仅是写给计算机看的，更重要的是是写给人看的。
- 注意破窗户，细节决定成败。
写给计算机看的代码往往追求的是运行结果的正确和满足需求的执行效率。这样的代码可能是乱糟糟的，没有注释，没有空格，没有排版，没有可以理解命名…. 除了刚写完的那会儿，我们知道我们所写的代码是啥意思。当过了十天半个月回来可能就连自己也不知道当初那会儿是怎么想的了， 更不用说如果这样的代码移交到其它同事，他那张纠结的小脸了…
代码到最后都是写给人看的，首先是给自己看的，然后是给使用这段程序的人，最后是其他与这段代码现在或将来相关的人。 这里所谓相关的人包括：
- 可能会阅读这段代码的人
- 可能会修改这段代码的人
- 可能会下载/复制这段代码的人
- 可能会走读这段代码的人
- 测试人员
- ……
从这个点出发，我们才能理解为什么要有编码规范，为什么会有若干文档。 我们所做的这些都是为将来做的，所谓“前人栽树，后人乘凉”，大致就是这个意思。
《程序员修炼之道》有这样一条：不要容忍破窗户（Don’t Live with Broken Windows）。 当我们遇到“破窗户”： 如低劣的设计、错误决策、或糟糕的代码，要及时的处理，如果不能马上修改代码，也请在有问题的地方写上注释，说明问题。 因为一旦有了第一个破窗户，不久后就会有第二个，第三个……直到整个系统满目疮痍、崩溃。 这里的“破窗户”可以理解为一些细节的问题，虽然我们经常会听到“细节决定失败”，在现实中也确实有些因为细节而成功的案例。 但是细节并不是每个人都可以看到的，有些人对于一些有问题的细节可以视而不见，这不是因为他们不想去改， 而是他们根本就不知道这些细节是不是正确的，感知细节也是一种能力，这需要在实践中不断的学习，不断的思想，不断的阅读好的代码，最好还有此中高手的指导。 这些细节决定了我们代码的成败，虽然结果不是马上显现的。
回到我们所用的语言-PHP，在编码规范这块，PHP本身就有一些问题，如函数的命名，PHP既有使用骆驼命名法的，也有类似于C中的以下划线隔开。 但是这种不规范中也有它的规范，所有的函数的命名都是以下划线隔开，所有的PHP提供的类中的方法都是骆驼命名法。 PHP以一种包容和开放的心态来处世，但是是否失去了自己特色呢？虽然PHP的有一些语言特点与一些商业的运作有关， 但是应该有自己的坚持，应该建立属于自己的规则。