在为ClearPHP收集规则的时候一个总是回来的问题就是定义规则来源的领域。代码约定和概念覆盖不同的域而且很少会相互重叠。ClearPHP规则的目标是尽量接近语言和它的技巧，远离语义(semantics）和架构。为什么呢？
代码约定
代码约定定义代码撰写规则。它们包括操作符周围的空格数量(http://symfony.com/doc/current/contributing/code/standards.html)，代码行缩进的距离(https://make.wordpress.org/core/handbook/coding-standards/php/)和变量名字的意义(http://nette.org/en/coding-standard)。它们一般被PHP code sniffer能汇报代码违规的工具支持；或者用PHP CS Fixer，它试图尽量地来修复任何违规代码。这样有利于避免产生“杂交骆驼和蛇”(https://twitter.com/DragonBe/status/555396473341607936)一样的现象。各种各样不同的项目都应该需要有一个这样的约定来认真跟随。
概念
概念，在另一方面，是试图在更高的一个视角来战斗这个问题。这里是设计模式，依赖注入(dependency injections）和单元测试的领域。你可以发现它们被收集在[PHP the right way](https://twitter.com/DragonBe/status/555396473341607936)网站上。通过工具[phpmetrics](http://www.phpmetrics.org/)和[phpmd](http://phpmd.org/)自动化地反馈矩阵；它们给予全局和本地值的质量报告并且促使你尽量减少[cyclomatic complexity](http://phpmd.org/rules/codesize.html)或[Halstead metrics](http://en.wikipedia.org/wiki/Halstead_complexity_measures)。
Clear PHP code
在这之间，还有一系列的正确推荐不属于上面任何涵盖的地方。比如，著名的strpos()比较规则该属于哪个地方呢？strpos必须用===来比较来避免”匹配找不到”的错误情况因为实际上是在第一个索引0的位置上，错误的认为没有找到的情况。还有，foreach()循环时需要unset它们的指引的情况来避免重用（和错用）？两个例子都不属于代码约定或代码概念。
解决方案是避免它们，积累经验。这个基本上意味着一旦有它们的经验，一些免疫力将会建立，一些小技巧将会像是玩“死飞”一样的。所以，一个更好的方案是包括代码审计(code review)来捕捉那些细违反小规则的情况并且去除它们。
因为那些技巧很多，ClearPHP把自己的一个目标设定为把它们归结到一个参考里。目前，已经有88(本文写下时)条规则，每条规则包括文档，标题和ID。那基本上帮你自己建构自己的参考的工作完成了一半：你只需要简单地选择一个或多个你需要的，然后把你下一次的代码审计基于它。也许，你将会有一些对更不常见的PHP的情形下的经验，而且愿意分享给我们community的所有其他人。期待在那里见到你！
English version: http://178.62.231.40/clear-php-code-between-coding-convention-and-conception/