PHP CodeSniffer有多有用？ 守则标准强制执行？
我正在考虑在持续集成服务器上设置PHP CodeSniffer ，以提高代码库的质量。 阅读完文档之后，我对标准化和执行编码标准的想法感到非常兴奋。 但是，我仍然想知道我们产品的实际改进。 我很清楚，嗅探器只能检测到违规行为，而不是一个明确的编码标准，但是干净，一致的代码库提供了什么样的好处呢？ 为了符合PEAR标准，使用10万行代码重构项目是否值得花费额外的工作？
对于那些不熟悉PHP CodeSniffer或者一般代码嗅觉的人来说，这里是一个输出示例：
FILE：/path/to/code/myfile.php
发现5错误（S）影响2线（S）
–
2 | 错误| 缺less文件的文件评论
20 | 错误| PHP关键字必须小写; 预计“假”，但发现“假”
47 | 错误| 线没有正确缩进; 预计4个空格，但发现1
51 | 错误| 缺lessfunction文档评论
88 | 错误| 线没有正确缩进; 预计9空间，但发现6
严格地说，用户/客户不会注意到重构的产品有任何区别，符合标准，但我想知道是否还有其他隐藏的好处
现在我们的代码并不是马虎，我们试图遵循我们自己的个人标准，这个标准大部分来自梨编码标准，但训练有素的眼睛可以发现差异。
所以我的问题是他们提高产品的质量有多less。 由此产生了什么样的潜在利益？
我只是为了强迫自己的产品更接近一套标准？ 这会值得吗？ 如果是这样，你使用什么样的策略来实现代码嗅探器，并纠正后来检测到的违规行为？
首先，我是PHP_CodeSniffer的维护者，所以我明显偏向于这个领域。 但是作为一名PHP开发人员，我还曾在一些大型代码库中工作过，所以我希望能够给出一些具体的理由来解释为什么编码标准是一件好事。 我可以写一个关于这个主题的博客系列，但是我只是给你一个关于PHP_CodeSniffer是如何产生的小故事，所以你可以理解这个工具为我解决的问题。
我曾经做过几个大型CMS项目。 第一个有一堆代码，还有一个相对较小的开发团队。 我们没有标准。 但是我们没有真正的问题。 球队很小，一起呆了一段时间。 我们习惯了彼此。
然后我们build立了一个新的CMS。 我们刚刚开始只有几个开发人员。 那时我只是两个开发者团队的一员。 编码标准再一次没有引起我们任何问题。 我和另一个开发者来自同一个背景，已经制定了一些我们遵循的准则。 当时我们并不需要PHPCS。
但是这个团队一度成长为一名开发人员，最终达到了12名全职开发人员，不less来来往往。 有些来自旧的CMS，有些来自公司外部。 所有人都有不同的背景和不同的发展方式。 谁写了什么代码是很明显的，因为风格是如此不同。 每当你做了一些复杂的事情，你首先必须适应自己的风格，因为它不是你习惯看代码的方式。 这就像是第一次读莎士比亚。 你需要习惯它，然后才能以自然的速度阅读。
对于开发者来说，额外的时间不得不停下来找出另一种编码风格，这纯粹是浪费时间。 当你陷入间距，缩进和托架位置时，这是一个想法溜走的机会。 在这一天结束的时候，这些事情并不重要。 但是让我告诉你，如果他们导致开发人员打破stream动，那么他们就很重要。 所以我们需要一种方法让他们摆脱困境，让开发者做他们最擅长的事情。
同时，我们正在深入研究JavaScript。 一种新的语言，风格通常被抛出窗外。 代码是从示例网站复制/粘贴并混合在一起。 当学习用新语言开发复杂的代码时，find一种方法使我们的JS看起来类似于我们的PHP是有意义的。 我们可以在以后尽量减less，但我们需要能够快速切换语言，以保持我们的stream量。
所以PHP_CodeSniffer诞生了。 它可以帮助开发人员使用相同的编码风格，使格式化和其他火焰诱饵问题完全避开。 它允许你在一定程度上像你的PHP一样对待你的JS。 我使用它来检测产品特定的气味，如未翻译的string或开发人员不使用我们正确的类包含代码。 我也将它用于特定语言的气味，比如确保杀死IE的JS逗号不被留下。 你可以用它来任何你想要的。 它带有一堆容易使用XML规则集文件合并在一起的嗅探 。 你也可以自己写。 您可以集成第三方工具，使其成为静态代码分析的一站式商店。 你可以认真对待标准和代码的气味，只要你喜欢。
像任何开发工具一样，PHP_CodeSniffer应该为你工作。 你不为此工作。 如果它产生太多你不关心的错误，请自定义标准以删除不需要的标准，或将错误转换为警告。 但是，如果我的故事听起来像是将来经历的或将来可能发生的事情，那么值得仔细查看PHP_CodeSniffer，看看它是否可以帮助您。
我希望这可以帮助你和其他人理解为什么编码标准对于一些项目和开发者来说真的很重要。 这不是关于细节。 这是关于从导致开发人员失去重点的事情清单中删除编码风格。
编码风格约定是一个好主意，因为它可以帮助开发人员在编写代码时不会被不同风格的代码分散注意力。 这将使您的代码基础表面更清洁。 如果能够自动化，这是非常好的，但通常不需要花费很多时间来遵守（除非现在的风格是可怕的 ）。 如果你已经有一个足够好的标准，坚持下去。
代码气味是不同的，但它是（一组）症状，可能表明代码更深层的问题。 例如循环复杂性，长方法名称，大类，不具名的名称，重复的代码等。这通常更成问题，因为它可能会严重影响代码的可维护性。 你一定要解决这些问题。
PHP CodeSniffer似乎主要是为了检查样式习惯而开发的，而不是代码味道。 如果你可以用它来帮助强制执行风格约定，那么很好。 但要小心，它不会使你的代码基础更好 。 你会想做手动评论来完成。
如果你想用它来检查你是否符合你当前的标准，那看起来是可能的，看到这个问题的答案：“我不同意你的编码标准！我可以让PHP_CodeSniffer强制执行我自己的标准吗？ 在他们的FAQ中 。
在那些宣传CodeSniffer的人中算我一身。 经过多年的高度怀疑，现在我正在使用它在我正在进行的每个项目上。 为什么？
正如格雷斯霍珀和/或安德鲁Tanenbaum着名的说，
关于标准的奇妙之处在于你有很多select。
同样，创build您自己的编码标准几乎总是一个坏主意？ 创build一个足以涵盖所有代码的内容是很难的 ，更重要的是，下一个人不会喜欢维护你的代码，谁会试图“改善”你的标准，举行的编码风格。 采用适当的外部标准，无论是Zend还是PEAR或Kohana或JoeBobBriggsAndHisFifthCousin，都可以让您专注于内容而不是格式化 。 更好的是，像PHP CodeSniffer这样的工具要么支持标准的“新鲜”，要么已经去过的标准几乎可以肯定地实现了作为附加的支持。
将编码标准与未编写的标准混合使用，除非采用两个简单的补充规则，
通过
--ignore命令行选项或等效的configuration文件设置，排除在采用编码标准之前排除的文件。 但是，当您修改源文件的任何部分时，请更新整个文件以符合您select的标准。
我刚刚写了一篇关于这种事情的新博客文章 。
有很多案例需要人为判断，而CodeSniffer没有。
一致的括号，缩进改善了代码。 函数调用后逗号没有空格？ 大概可以被原谅，但这是根据CodeSniffer的错误 。
恕我直言，有太多的错误报告由CS。 即使是似乎有整齐的代码的项目，也可以轻易地遇到成千上万的CS问题。 它很快就会变得累赘，几乎不可能解决所有这些问题，特别是当它是一个真正的问题和强迫性的废话混合在一起的时候 – 同样经常被标记为错误 。
你可能最好忽略CS，花时间去实际改进代码（在devise，algorithm方面），而不仅仅是表面上的空白和注释的改变（ isAlpha函数是否真的需要8行注释？是的，如果你问CS）。
CS太容易变成腐蚀抛光工具。
这绝对是一件好事。 我们从SVN挂钩运行，这样所有的代码都必须通过内部标准（PEAR的一个修改），然后才能实现（这是我做过的最好的决定之一）。
当然，这对于一个新的项目来说效果最好，在这个项目中没有大量的遗留代码可以转换成新的标准。 解决这个问题的方法之一是修改你的SVN预提交钩子，只运行codesniffer的新增内容，忽略修改。 你可以通过添加下面这行来做到这一点：
$SVNLOOK changed "$REPOS" -t "$TXN" | grep "^A.*\.php " > /dev/null || exit 0
如果没有新的PHP代码parsing，这将退出钩子脚本。 因此，所有新文件都需要遵守标准，您可以在自己的时间将遗产代码提高到标准。
请注意，如果您使用的是Eclipse或Zend IDE，那么您可以从自动化工具中获益，从而使得标准的尊重成本更低。 您也可以使用像Hudson或PHPUndercontrol这样的持续集成工具。
- PDT是一个很酷的PHP编辑器
- PDT工具是一些自动格式化工具的PDT插件
- DTLK（dynamic工具包库）可用于启动一些外部脚本来检查您的文件。
你也可以看看我认为更容易configuration的PHP Checkstyle （免责声明：我已经开始了）
其他一些工具列在网站的“文档”页面上。
CodeSniffer是一个很好的实现，但你必须知道如何使用它。 除非由于您将工作提交给某个外部项目而必须遵守给定的编码标准，否则您可以自由地完全定义自己的编码标准。
PHP的CodeSniffer应该让你很容易，因为已经有很多单一的代码嗅探，你可以包含在你自己的编码标准定义，而不需要从头开始编写它们。 在探索现有法典的可能性的同时，如果你觉得有必要的话，你最终可以自己写一个扩展到现有的嗅探或嗅探。
如果你想从CodeSniffer开始，第一步是获取一组完全类似于你当前编码标准的嗅探，并检查产生的错误和警告。 不要应用其中一个预定义的标准，因为这很可能会导致太多的错误，如果修复的话太less的好处。 例如，如果您不使用PHPDoc生成文档，那么完成关于缺lessPHPDoc标记和注释的所有codesniffer错误将是没有用的。
您是否提供PEAR软件包，通过PEAR / PECL公开发行？ 如果是这样，那么你可能想坚持梨的习俗。
否则，我不能看到它是值得的大重构。 最重要的是同意你的团队的编码标准…不一定是PEAR的标准…只要确保有一些标准的惯例强制执行。
例如，我是一个粉丝
function foo () {
格式与PEAR标准..
function foo () {
底线，不要太担心符合他们的标准，如果它将是一个大量的工作，特别是如果你不是在PECL包。
