PHP_CodeSniffer 每个文件嗅探许多类答案

【问题标题】：PHP_CodeSniffer Many Classes per file sniffPHP_CodeSniffer 每个文件嗅探许多类
【发布时间】：2012-12-05 22:10:48
【问题描述】：

我们有一个正在使用的标准，我们在主类中创建异常以返回错误等...问题是，所有标准嗅探都不喜欢这样。我们正在为此编写自己的嗅探器，但我想我会问为什么这是不可取的？

例如，我们有：

<?php
class FOO_EXCEPTION extends Exception   {   }
class FOO_EXCEPTION_BAR extends FOO_EXCEPTION   {   }
class FOO_EXCEPTION_POLE extends FOO_EXCEPTION  {   }

class FOO
{
    public function MethodDoingSomething()
    {
        if('some condition happens')    {
            throw new FOO_EXCEPTION_BAR();
        }

        if('some other condition')  {
            throw new FOO_EXCEPTION_POLE();
        }
        ...
    }
}
?>

这允许我们的代码返回不同的异常来指示调用者发生了什么，但是如果专用的 try/catch 不可用，那么基本的 Exception 仍然可能被捕获。

这在处理数据库或其他外部对象时会派上用场，因为错误的性质可能会返回到调用堆栈更高的组件来处理错误。

例如，如果您正在删除一个文件，而该文件不存在，则代码可能会抛出异常，但调用者可以选择忽略此异常，如果它不担心该文件不存在，因为它无论如何都试图删除它。但是，另一个调用者可能会因缺少删除时假定存在的文件而出错。

【问题讨论】：

如果您使用自动加载器，那么您不需要将异常类放在同一个文件中；每个都可以位于自己的单独文件中，并且在实际引用之前不需要加载（使用 PHP 内存）
没错，但我们将它们放在一起是出于逻辑原因，即它们在文件中定义并且对于每个开发人员都清晰可见，并且知道可以抛出什么。另一个问题是，如上所示，通常异常只不过是要捕获的定义，因此在可以通过自动加载加载的外部文件中创建它似乎也有点过头了。
这就是一个很好的简单文件夹结构有帮助的地方：您的类文件夹中有 Foo 类文件；然后是您拥有 Foo_Exception 类文件的 Foo 文件夹；和一个 Exception 子文件夹，在你有 Foo_Exception_Bar 和 Foo_Exception_Pole 类文件的地方......同样合乎逻辑，而且很容易阅读
我知道你要去哪里。这将非常简单，尽管有很多目录和非常短的文件。我最关心的是确保我们所有的开发人员都遵循这一点并意识到创建了哪些异常。我猜这种格式也适用于 PHP 5.3 的命名空间结构。
是很多目录和短文件；但是如果您使用的是自动加载器和 APC，这不会对性能产生任何不利影响（相反，它通常会好很多，因为只有实际需要的内容才会包含在内存中，并且没有加载的开销不需要的其他包括）。切换到这样的结构的最大问题是开发人员对结构的理解；但它应该相当直观

标签： php exception codesniffer

【解决方案1】：

在我看来，您在问题中描述的编码标准是完全合理的。而且我认为为了您的项目的目的，最好调整“每个文件的标准多个类”嗅探，以便它在这种特殊（特殊）情况下与您的代码一起使用，而不是浪费您的时间调整您的代码库以符合此特定嗅探的“法律条文”。

我同意一般最好避免将多个类定义放在一个文件中的断言。但是（到目前为止）我读过的关于将每个异常派生类移动到其自己的单独文件中的每一个论点，都让我觉得通过降低可读性来“改进”代码。作为人类，我没有从将代码与包含单行的文件混在一起而获得可维护性的好处。

确实，编写自动加载器更容易，例如，如果每个类都存在于自己的文件中。如果你从某种元语言生成/编译你的 PHP 代码，那么在你的目录结构中添加额外的级别不需要任何成本。但我拒绝接受这样的结论，即这种组织代码的方式实际上可以以任何对人类有用的方式改进它。

编辑： 作为记录，我可以看到将异常派生类的定义移动到它自己的文件中是个好主意如果它实际上包含一些“可测试”逻辑。在这种情况下，您可能需要在为使用该类的逻辑编写自动化测试时模拟/存根该类，这将要求您能够将类定义与使用它的逻辑分开加载.但这不是原始问题中描述的情况，异常派生类都是“空的”。

【讨论】：

谢谢。我们在顶部使用异常只是为了让它们抛出，因为它看起来比所有这些基本上什么都不做的小文件更清晰。必须包含主类才能获得功能，因此它也会自动引入异常，而无需定义自动加载器等......我们同意它不会使代码更易于维护，并且在内部，相信它使它变得不那么重要。一个外部文件可能会被遗忘，也不会被更新/引用，等等……有近 100 万行代码，没有人能全部记住。
我们在我工作的情况下（数百万 L.O.C. 有数万个文件），目前正在使用 PHP 异常编码标准，这似乎与你在你的问题中描述。
你现在有嗅觉吗？我正在写一个，它会确保多个类的名称中有异常，不是万无一失的，而是我正在尝试的。我目前也根据文件名匹配类名编写了一个嗅探（需要针对异常进行修改）。
@StevenScott - 我目前没有使用任何嗅探来检查单个文件中的多个类，因为我们还没有（还）决定将任何相关规则添加到我们的编码标准中。但是通过实现 PHP_CodeSniffer_Sniff 接口来编写一个并不难——您可以使用 T_OPEN_CURLY_BRACKET 的 'backet_opener' 和 'bracket_closer' 标记来检查空类主体。一个问题：识别扩展在另一个文件中定义的异常派生类的类。要么禁止这样做，要么要求异常派生类的名称以“异常”结尾。
Out classes for Exception 已经以 Exception 结尾（编码标准 - 但必须为它编写一个嗅探），然后我将向该类添加一个嗅探，因此一个空类是一个异常，必须扩展，并以异常结束。感谢您的帮助。