我正在考虑在我们的持续集成服务器上设置PHP CodeSniffer，以提高代码库的质量。在阅读文档后，我对标准化和执行我们的编码标准的想法感到非常兴奋。但是，我想知道我们产品的实际改进。我很清楚，嗅探器只检测违反规定的编码标准，但干净，一致的代码库提供了哪些类型的好处？使用100k +代码行重构项目以符合PEAR标准是否值得额外工作？
对于那些不熟悉PHP CodeSniffer或一般代码嗅觉的人，这里有一个示例输出：
文件：/path/to/code/myfile.php
发现5个错误（2）影响2行（S）
-
2 |错误|缺少文件doc评论
20 |错误| PHP关键字必须小写;预期“假”但发现“假” 47 |错误|线没有正确缩进;预期4个空格但发现1个 51 |错误|缺少功能文档评论
88 |错误|线没有正确缩进;预计9个空格，但发现6个
严格来说，用户/客户不会注意到重构为符合标准的产品有任何差异，但我想知道是否还有其他隐藏的好处
现在我们的代码绝不是草率的，我们试图遵循我们自己的个人标准，这些标准在很大程度上源自Pear's Coding Standards，但训练有素的眼睛可以发现差异。
所以我的问题是它们能提高产品质量的程度。它带来了什么样的潜在好处？
我是否只是因为我希望将我们的产品更接近一套标准而产生强迫症？它值得吗？如果是这样，您使用了什么样的策略来实现代码嗅探器并纠正后来检测到的违规行为？
答案 0 :(得分：104)
首先，我是PHP_CodeSniffer的维护者，所以我明显偏向这个领域。但是，作为一名PHP开发人员，我在10年的时间里也参与了一些重要的代码库，所以我希望能够为编码标准带来好处提供一些具体的理由。我可以写一个关于这个主题的博客系列，但我会给你一个关于PHP_CodeSniffer如何出现的故事，这样你就可以理解该工具为我解决的问题。
我参与了一些大型CMS项目。第一个有一堆代码，后面有一个相对较小的开发团队。我们没有标准。但我们没有真正的问题。团队规模很小，并且在一起待了很长时间。我们已经习惯了。
然后我们建立了一个新的CMS。我们刚开始只有几个开发人员。我当时只是两个开发人员团队的一员。同样，编码标准并没有给我们带来任何问题。我和另一个开发人员来自相同的背景，并且已经建立了我们遵循的一些指导方针。那时我们不需要PHPCS。
但该团队一次成长为一名开发人员，并最终达到了12名全职开发人员，并且不少有人来过去。有些来自旧的CMS，有些来自公司外部。所有人都有不同的背景和不同的发展方式。很明显谁写了什么代码，因为风格是如此不同。每当你处理复杂的事情时，你首先必须适应他们的风格，因为这不是你习惯看代码的方式。这就像是第一次读莎士比亚。在你以自然的节奏阅读之前，你需要习惯它。
对于开发人员来说，必须停下来并找出另一种编码风格的额外时间只是浪费时间。当你陷入间距，压痕和支架位置时，这是一个想法滑落的机会。在一天结束时，这些事情并不重要。但是，让我告诉你，如果它们导致开发人员打破他们的流量，他们会很重要。因此，我们需要一种方法让他们摆脱困境，让开发人员做他们最擅长的事情。
与此同时，我们正在深入研究JavaScript。一种通常抛出风格的新语言。代码从示例站点复制/粘贴并混合在一起。在学习用新语言开发复杂代码时，找到一种让我们的JS看起来与PHP类似的方法是有意义的。我们可以稍后将其最小化，但我们需要能够快速切换语言，以便保持流畅。
所以PHP_CodeSniffer就是为此而生的。它可以帮助开发人员使用相同的编码风格，使格式化和其他火焰诱饵问题完全不受影响。它允许您在一定程度上像对待PHP一样对待JS。我使用它来检测产品特定的气味，如非翻译字符串或开发人员不使用我们正确的类包含代码。我还将它用于特定于语言的气味，例如确保杀死IE的JS逗号不会遗留下来。你可以随意使用它。它带有大量的嗅探，很容易使用XML ruleset file合并在一起。你也可以自己写。您可以集成第三方工具，使其成为静态代码分析的一站式服务。你可以对标准和代码气味一样认真。
PHP_CodeSniffer，就像任何开发工具一样，应该适合你。你不适合它。如果它产生太多您不关心的错误，请自定义标准以删除您不想要的错误，或将错误转换为警告。但是，如果我的故事听起来像是你正在经历的事情，或将来可能会经历的事情，那么值得仔细研究一下PHP_CodeSniffer，看看它是否能帮到你。
我希望这有助于您和其他人理解为什么编码标准对某些项目和开发人员非常重要。这不是关于细节。它是关于从导致开发人员失去焦点的事物列表中删除编码风格。
答案 1 :(得分：32)
拥有编码样式约定是一个好主意，因为它可以帮助开发人员在处理他们没有编写的代码时不会被以不同风格编写的代码分心。它将使您的代码基础表面更清晰。如果你可以自动化它是很棒的，但通常没有必要花很长时间来遵守（除非当前的风格可怕）。如果你已经有足够好的标准，请坚持下去。
代码气味是不同的东西：它是（一组）症状，可能表明代码更深层次的问题。示例包括圈复杂度，长方法名称，大类，不具描述性的名称，重复代码等。这通常更成问题，因为它可能会彻底损害代码的可维护性。你绝对应该解决这些问题。
PHP CodeSniffer似乎主要用于检查样式约定，而不是代码嗅觉。如果您可以使用它来帮助实施样式约定，那就太好了。但请注意，它不会使您的代码基本上更好。您需要进行人工审核才能实现这一目标。
如果您想用它来检查您是否符合当前的标准，这似乎是可能的，请参阅问题的答案“我不同意您的编码标准！可以我让PHP_CodeSniffer强制执行我自己的？“ in their FAQ
答案 2 :(得分：11)
让我参与传播CodeSniffer的人。经过多年的高度怀疑，我现在在我正在研究的每个项目上使用它。为什么呢？
正如Grace Hopper和/或Andrew Tanenbaum所说，
关于标准的奇妙之处在于 你有这么多人可以选择。
同样，创建自己的编码标准几乎总是一个坏主意™;创建一个足以涵盖所有代码的内容是 hard ，更重要的是，它不会让下一个人喜欢维护你的代码，谁会试图“改进”你的标准这样它适合他长期的编码风格。采用适当的外部标准，无论是Zend还是PEAR或Kohana或JoeBobBriggsAndHisFifthCousin，都可以让您专注于内容而不是格式。更好的是，像PHP CodeSniffer这样的工具要么支持标准的“新鲜的”，要么那些已经过去的人几乎肯定已经实现了作为附件的支持。
将编码标准与未编写到该标准的现有代码相混合将使您适合，除非您采用两个简单的补充规则。
排除早于您的文件 采用编码标准 被检查，通过
--ignore命令行 选项或等同物 配置文件设置。但当 你修改了的任何部分 源文件，将整个文件更新到 符合您选择的标准。
我只是wrote a new blog post关于此类事情。
答案 3 :(得分：6)
有很多案例需要人为判断，CodeSniffer没有。
一致的括号，缩进改进了代码。函数调用后逗号后空格不足？可能会被原谅，但根据CodeSniffer，这是 ERROR 。
恕我直言，CS报道的错误太多了。即使是看似具有整洁代码的项目也很容易遇到数千个的CS问题。它很快就会变得很累，而且几乎不可能解决所有这些问题，特别是当它是真实问题和强迫性废话的混合时 - 两者同样经常被标记为 ERRORS 。
你可能最好忽略CS并花时间对代码进行实际改进（在设计，算法方面），而不仅仅是完全肤浅的空白和注释更改（1行isAlpha函数确实需要8注释？是的，如果你问CS）。
CS很容易成为粪便抛光工具。
答案 4 :(得分：3)
这绝对是件好事。我们从SVN钩子运行我们的所有代码，以便所有代码必须通过标准（PEAR的修改）才能提交（这是我做过的最好的决定之一）。
当然，这最适合新项目，因为没有大量遗留代码可以转换为新标准。解决此问题的一种方法是修改SVN预提交挂钩，以仅对代码提供程序运行新添加并忽略修改。您可以通过添加以下行来执行此操作：
$SVNLOOK changed "$REPOS" -t "$TXN" | grep "^A.*\.php " > /dev/null || exit 0
如果没有要解析的新PHP代码，这将退出钩子脚本。因此，所有新文件都需要遵守标准，您可以在自己的时间内将遗留代码提升到标准。
答案 5 :(得分：3)
请注意，如果您使用的是Eclipse或Zend IDE，您可以从自动化工具中受益，这样可以降低标准的使用成本。您还可以使用Hudson或PHPUndercontrol等持续集成工具。
您还可以查看我认为更容易配置的PHP Checkstyle（免责声明：我已经开展过工作）
网站的“文档”页面上列出了一些其他工具。
答案 6 :(得分：1)
CodeSniffer是一个很棒的实现，但你必须知道如何使用它。除非您因为将工作提交给某个外部项目而必须遵守给定的编码标准，否则您可以自由地完全定义自己的编码标准。
PHP CodeSniffer应该让你很容易，因为已经有许多单个代码嗅探可以包含在你自己的编码标准定义中，不需要从头开始编写。在探索现有Codesniffers的可能性时，如果您认为有需要，最终可能会自行编写现有嗅探或嗅探的扩展。
如果您想从CodeSniffer开始，第一步是获取一组完全类似于您当前编码标准的嗅探，并检查产生的错误和警告。不要应用其中一个预定义的标准，因为这很可能导致太多错误，如果修复的话，利益太少。例如，如果您不使用PHPDoc生成文档，则无法满足有关缺少PHPDoc标记和注释的所有代码错误。
答案 7 :(得分：0)
您是否通过PEAR / PECL提供PEAR包公开发行？如果是这样，那么你可能想要坚持PEAR惯例。
否则，我看不出它值得大型重构。最重要的是同意你的团队的编码标准......不一定是PEAR的标准......只要确保有一些标准的约定被强制执行。
例如，我是
的粉丝function foo () {
格式与PEAR标准相比..
function foo ()
{
最重要的是，如果要做大量的工作，不要太担心符合他们的标准，特别是如果你没有把包裹放在PECL上。