PHP Zend Framework 编码标准，哪种方式更易读？答案

【问题标题】：PHP Zend Framework coding standard, which is the more readable approach?PHP Zend Framework 编码标准，哪种方式更易读？
【发布时间】：2010-03-04 20:45:35
【问题描述】：

这是一个主观问题，我需要您对编码标准和格式化实践的感受和想法。

PHP Zend 编码标准要求编写这样的多行函数调用：

$returnedValue = $object->longMethodName(
    $argument1,
    $otherArgument,
    42
);

我认为下面的方法更具可读性：

$returnedValue = $object->longMethodName($argument1,
                                         $otherArgument,
                                         42);

因为左边只有一行，这说明这只是一条语句，而且参数更接近方法名。

你更喜欢哪一个？

【问题讨论】：

第二种方法在使用比例字体时严重失败。是的 - 有些人确实使用它，这种选择与使用固定宽度字体一样好。

标签： php zend-framework coding-style

【解决方案1】：

第二种方法会给您带来一个额外的问题：行长。 Zend 编码标准建议“任何 PHP 代码行的最大长度为 120 个字符。”

这意味着，如果您想要好的（长的、描述性的）变量名称，并且您碰巧有一个用于返回值、对象、一个好的命名函数和一个长参数，那么您更有可能达到 120 个字符的限制。

除此之外，根据您的标准，最大长度可能只有 80 个字符或介于两者之间。

另外，如果重复使用，我更喜欢第一个

$returnedValue = $object->longMethodName(
    $argument1,
    $otherArgument,
    42
);
$returnedValue = $object->longMethodName(
    $argument1,
    $otherArgument,
    42
);
$returnedValue = $object->longMethodName(
    $argument1,
    $otherArgument,
    42
);
$returnedValue = $object->longMethodName(
    $argument1,
    $otherArgument,
    42
);

$returnedValue = $object->longMethodName($argument1,
                                         $otherArgument,
                                         42);
$returnedValue = $object->longMethodName($argument1,
                                         $otherArgument,
                                         42);
$returnedValue = $object->longMethodName($argument1,
                                         $otherArgument,
                                         42);
$returnedValue = $object->longMethodName($argument1,
                                         $otherArgument,
                                         42);

就像佩卡说的，少跳眼。

【讨论】：

是的，这很明显哪个更好看。

【解决方案2】：

我更喜欢第一种方法。后者需要更多的打字，并且对 IMO 的眼睛更加紧张。我认为眼睛 - 至少对于人类的“西方”，从左到右阅读的部分 - 在到达当前行的末尾时倾向于跳到下一行的开头，并且有太多的空白在第二个例子中跳过。它在语义上可能不是 100% 正确，但提供了良好的阅读流程。

【讨论】：

我期待你的回答 Pekka ;) 好的，我考虑了这些论点。

【解决方案3】：

我喜欢 PEAR 的标准，它提倡您的第一个示例

$returnedValue = $object->longMethodName(
    $argument1,
    $otherArgument,
    42
);

但我可能会为这么短的一组参数这样做：

$returnedValue = $object->longMethodName(
    $argument1, $otherArgument, 42
);

编辑：哦！以恒星为例：

$notInlined = longInlinedMethod($argFoo, $argBar) + otherLongInlinedMethod();
$returnedValue = $object->longMethodName(
    $arg1, $notInlined, $arg3, $arg4
);
while ($val) {
    someStatement();
}

【讨论】：

【解决方案4】：

在你提供的两个中，我更喜欢第一个。

如果有合适的编码标准，我会遵循它。但是，在我的工作中没有，我更喜欢以下内容：

$returnedValue = $object->longMethodName(
                                $argument1,
                                $otherArgument,
                                42
                            );

对我来说，更容易立即看到正在执行的变量赋值（因为参数和右括号的缩进方式。使用 Zend 标准，您必须实际查找等号才能看到它是赋值，否则它可能会与普通的多行函数调用混淆。

还有一条评论...我的函数调用只有在超过 120 个字符时才会变为多行，在工作区浏览器和代码导航器窗格打开的情况下，在 1600x1200 分辨率的 IDE 中，超过 120 个字符将不可见。

这行代码只有 74 个字符，所以我会这样做：

class myClass
{
    public function myFunction(...)
    {
        $returnedValue = $object->longMethodName($argument1, $otherArgument, 42);
    }
}

【讨论】：

Zend cs（或至少我的 phpcs/Zend 验证程序）在一行中只允许 80 个字符。
80 个字符是推荐的最大长度。 120 是实际最大值（@see framework.zend.com/manual/en/…）。如果您的代码通常包含诸如 $descriptivelyNamedVariable = $descriptivelyNamedObject->descriptivelyNamedMethod($descriptivelyNamedParameter); 之类的内容，则很难坚持 80

【解决方案5】：

也没有？选项 A 可能会造成混淆，因为单缩进用于代码块。选项 B 对于长参数名称和/或深度缩进的代码存在问题。

对于连续的参数列表，我更喜欢双缩进。

示例，根据 erenon 的要求：

$returnedValue = $object->longMethodName(
        $arg1, longInlinedMethod($argFoo, $argBar) + otherLongInlinedMethod(),
        $arg2, $arg3);
while ($val) {
    someStatement();
}

【讨论】：

说实话，这也是我要去的地方。如果块缩进与参数缩进相同，我发现略读有点困难。
这是主要的理由。此外，我不喜欢将 end-paren 放在自己的行上以及需要为每个参数单独一行而导致的过多空格。您无需享受 perl 级别的代码密度就可以一次在屏幕上看到超过一两个功能。

【解决方案6】：

我通常使用第一个，但右括号在同一行或至少与上述相同的缩进。

$returnedValue = $object->longMethodName(
    $argument1,
    $otherArgument,
    42
    );

$returnedValue = $object->longMethodName(
    $argument1,
    $otherArgument,
    42);

对我来说，这似乎避免了嵌套时的级别混淆。

但是：我在 vim 中的缩进器开始执行与 paren 相同级别的操作（2，以上），我喜欢它。我在需要包装帮助的长行上打破了它，但总的来说，如果您主要扫描方法名称而不是参数，我认为它会导致代码可读。

顺便说一句，对嵌套的布尔语句进行这种缩进也很有效。

如果参数不是太长，我也会将它们分组在一行中，并且它们对分组有意义。

【讨论】：

【解决方案7】：

我更喜欢第一个，原因有两个：

它允许您使用 Tab 键进行缩进（或使用热键进行缩进/取消缩进），而无需担心添加额外的空格以使您的参数对齐。
更重要的是，如果变量、对象或方法名称的长度在第一行发生变化，您不必修改参数缩进。

【讨论】：