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