php代码嗅探器有多有用?规范标准的一般实施?[关闭]

首先,我是php代码嗅探器的维护者,所以我在这方面明显有偏见。但是在我作为PHP开发人员的10年中,我还在一些大型的代码库中工作,所以我希望我能给出一些具体的原因来说明为什么编码标准是一件好事。我可以写一个关于这个主题的博客系列,但是我会给你一个小故事,关于PHPY-CODESNIFFER是怎么来的,这样你就能理解这个工具为我解决的问题。

我曾参与过几个大型CMS项目。第一个有一堆代码和一个相对较小的开发团队。我们没有标准。但我们没有真正的问题。队伍很小,在一起呆了很长一段时间。我们已经习惯了。

然后我们建立了一个新的CMS。我们刚开始时只有几个开发人员。当时我只是一个团队的一部分。同样,编码标准并没有给我们带来任何问题。我和另一个开发人员来自同一个背景,已经建立了一些我们遵循的指导原则。那时我们不需要phpc。

但这个团队一次培养了一个开发人员,最终达到了12个全职开发人员,有不少人来去匆匆。有的来自老CMS,有的来自公司外。他们都有不同的背景和不同的发展方式。很明显,谁写了什么代码,因为风格是如此不同。每当你处理复杂的事情时,你首先必须调整自己的风格,因为这不是你习惯于看到代码的方式。就像是第一次读莎士比亚。在你能以自然的速度阅读之前,你需要习惯它。

对于开发人员来说,必须停止并找出另一种编码风格的额外时间纯粹是浪费时间。这是一个机会,一个想法溜走,而你陷入了间距,压痕和括号的位置。归根结底,这些都无关紧要。但是让我告诉你,如果它们导致开发人员中断他们的流程,那么它们很重要。因此,我们需要一种方法,让他们马上离开,让开发人员做他们最擅长的事情。

同时,我们还深入研究了javascript。一种新的语言,风格通常被扔出窗外。代码是从示例站点复制粘贴的,并被一起捣碎。当学习用一种新语言开发复杂代码时,找到一种使js看起来与php相似的方法是有意义的。我们可以稍后将其最小化,但是我们需要能够快速地在语言之间切换,以保持我们的流动。

所以,菲普科德尼弗天生就是这么做的。它可以帮助开发人员使用相同的编码风格,使格式化和其他flame-bait问题完全偏离正轨。在某种程度上,它允许你像对待php一样对待js。我使用它来检测特定于产品的气味,比如未翻译的字符串,或者开发人员没有使用正确的类包含代码。我还使用它来处理特定语言的气味,比如确保杀死ie的js逗号不被留下。你可以随心所欲地使用它。它带有大量的嗅探,使用 XML ruleset file . 你也可以自己写。您可以集成第三方工具,使之成为静态代码分析的一站式商店。你可以认真对待标准和代码的气味,因为你喜欢。

php_代码嗅探器,就像任何开发工具一样,应该适合您。你不是为它工作的。如果它产生了太多您不关心的错误,请自定义标准以删除不需要的错误,或者将错误转换为警告。但是,如果我的故事听起来像是你正在经历的或者将来可能经历的事情,那么仔细看看PHPY-CODESNIFFER,看看它是否能帮到你。

我希望这有助于您和其他人理解为什么编码标准对某些项目和开发人员非常重要。这与细节无关。它是关于从导致开发人员失去关注的事情列表中删除编码风格。

有编码风格约定是一个好主意,因为这有助于开发人员在处理他们没有编写的代码时,不会被用不同风格编写的代码分散注意力。它会使你的代码库表面上更干净。如果你能使它自动化,那就太好了,但是通常不需要经过很大的时间来遵守(除非当前的风格是)。 可怕的 )如果你已经有了足够好的标准,那就坚持下去。

不过,代码气味是不同的:它是(一组)症状,可能表明代码有更深层次的问题。例如圈复杂度、长方法名、大类、不可描述的名称、重复代码等等。这通常会造成更大的问题,因为这可能会彻底损害代码的可维护性。你一定要解决这些问题。

php代码嗅探器似乎主要用于检查样式约定,而不是代码气味。如果你能用它来帮助执行风格惯例,那就太好了。但请注意,它不会使您的代码基 更好的 . 你需要做手工检查来完成这项工作。

如果你想用它来检查你是否遵守 你当前 标准,这似乎是可能的,请看问题的答案“我不同意你的编码标准!我能让PHP-CODEDENIFER执行我自己的吗?” in their FAQ 。

把我算在那些传播代码嗅探器的人当中。经过多年的高度怀疑,我现在把它用在我正在做的每一个项目上。为什么?

正如格雷斯·霍珀和/或安德鲁·坦鲍姆所说,

标准的美妙之处在于 你有很多选择。

同样,创建自己的编码标准几乎总是一个坏主意;创建一个足够全面的标准来覆盖所有的代码是 坚硬的 ,而且,更重要的是,维护代码的下一个人不会喜欢,他会试图“改进”您的标准,使之适合他长期以来的编码风格。采用一个 适当的 外部标准,无论是zend、pear、kohana还是joebbbriggsandhisfifth cousin,都能让你专注于 内容 而不是 格式化 . 更好的是,像php代码嗅探器这样的工具要么支持标准的“新鲜出炉”,要么以前的那些工具几乎肯定已经将支持作为一个插件实现了。

将编码标准与未按该标准编写的现有代码混合使用将给您带来适合性,除非您采用两个简单、互补的规则。

排除早于 采用的编码标准 正在检查,通过 --ignore 命令行 期权或等价物 配置文件设置。但是,什么时候 你确实修改了 任何部分 A的 源文件,将整个文件更新为 遵守您选择的标准。

我只是 wrote a new blog post 关于这类事情。

有很多情况需要人类的判断,而代码嗅探器没有。

一致的括号,缩进改进了代码。函数调用中逗号后缺少空格?也许可以原谅,但那是 误差 根据代码嗅探器。

我知道CS报告的错误太多了。即使是具有整洁代码的项目也可以很容易地运行。 数千 关于CS问题。很快就会变得很累,几乎不可能解决所有这些问题,特别是当它是一个真正的问题和顽固的强制性废话的混合体时,两者通常都被标记为 错误 。

你最好忽略cs,把时间花在代码的实际改进上(在设计、算法上),而不是仅仅是表面上的空白和注释的改变(一行代码 isAlpha 函数真的需要8行注释吗?是的,如果你问CS)。

CS可以很容易地变成研磨抛光工具。

这绝对是件好事。我们从一个VPN钩子运行我们的所有代码必须通过众议院标准(修改梨)之前,它可以承诺(这是我做过的最好的决定之一)。

当然,这对于一个新项目最有效,因为在这个项目中没有大量的遗留代码可以转换成新的标准。解决此问题的一种方法是修改svn预提交挂钩,使其仅运行对代码嗅探器的新添加并忽略修改。你可以这样做:

$SVNLOOK changed "$REPOS" -t "$TXN" | grep "^A.*\.php " > /dev/null || exit 0

如果没有要解析的新php代码,这将退出hook脚本。因此,所有新文件都需要遵守标准,您可以将遗留代码在您自己的时间内达到标准。

请注意,如果您使用Eclipse或Zide IDE,您可以从自动化工具中获益,这使得标准的成本降低。您还可以使用一个连续的集成工具,如哈德森或。

• pdt是一个很酷的php编辑器
• pdt工具是一些带有自动格式化工具的pdt插件。
• DTLK(动态工具包库)可以用来启动一些外部脚本来检查文件。

你也可以看看 PHP Checkstyle 我认为这更容易配置(免责声明:我已经做过了)

其他一些工具列在网站的“文档”页上。

代码嗅探器是一个很好的实现,但你必须知道如何使用它。除非您必须遵守给定的编码标准,因为您要将工作提交给某个外部项目,否则您可以完全定义自己的编码标准。

PHP CODESNIFFER应该使您非常容易,因为已经有许多单代码嗅探器,您可以在自己的编码标准定义中包含,而不必从头开始编写它们。在探索现有代码嗅探器的可能性时,如果您觉得有必要,您可能会编写一个现有嗅探器的扩展,或者自己编写一个嗅探器。

如果您想从代码嗅探器开始,第一步是获取一组与当前编码标准完全相似的嗅探器,并检查产生的错误和警告。不要应用其中一个预定义的标准,因为这很可能会导致太多的错误,如果修复的话,好处太少。例如,如果不使用phpdoc生成文档,那么就没有必要完成关于丢失phpdoc标记和注释的所有代码嗅探器错误。

您是否提供梨包装供公众通过梨/山核桃分发?如果是这样的话,你可能会坚持梨的习俗。

否则,我看不出它是值得的。最大的问题是为您的团队商定一个编码标准…不一定是梨的标准…只要确保有一些标准的惯例得到执行。

例如,我是

function foo () {

格式与PEAR标准。

function foo ()
{

总之,如果要做大量的工作,不要太担心是否符合他们的标准,特别是如果你不把包放在pecl上。