PSR-2 第 4.2 节解释答案

【问题标题】：PSR-2 Section 4.2 InterpretationPSR-2 第 4.2 节解释
【发布时间】：2014-05-24 10:25:27
【问题描述】：

我的一位同事最近告诉我，PSR-2 编码标准规定不允许使用“_”字符来指示变量是私有的还是受保护的。

必须在所有属性上声明可见性。

不得使用 var 关键字声明属性。

每个语句声明的属性不得超过一个。

属性名称不应以单个下划线为前缀指示受保护或私有可见性。

当我听到这个消息时我非常愤怒，因为我非常喜欢私有和受保护变量上的 _ 前缀，我无法相信社区会接受这样的标准。

我基于“不应”关键字对此的解释是，在声明类的属性时必须使用范围关键字，并且建议您不要使用 _ 字符，但它仍然是允许的，而且您仍然可以PSR-2 投诉，如果您选择使用它。

虽然我不同意这一点并建议每个人都在其私有和受保护的变量前加上下划线，但我怀疑这样做的原因是为了防止人们遗漏范围关键字（Public、Protected、Private）而只依赖于命名习俗。这是因为，因为我们都知道没有范围变量，PHP 使所有内容都公开。

总结问题：类 PSR-2 上私有和受保护变量的“_”前缀是否符合？

编辑：另外，我不是在这里寻找个人偏好辩论，我只是想知道使用 _ 前缀在技术上是否符合 PSR-2。

【问题讨论】：

永远不要使用它，当人们在变量名中使用 _ 时讨厌它
嗯，must not 和 should not 是两个不同的意思，对吧？
@Dave 我希望我的变量名尽可能具有描述性。
我认为@MikeSherrill'CatRecall'（以及您自己的解释）一针见血。如果它只是说Property names SHOULD NOT be prefixed[...]，那么这可能是有争议的。但他们在说SHOULD NOT 之前列出了三个MUST NOT 规则。对我来说似乎很清楚..
如果您不是“寻找个人偏好辩论”，请不要将您的个人偏好带入 cmets 中，例如：“当我听到这个时我很愤怒，因为我是 _ 前缀的忠实粉丝在私有和受保护的变量上，我无法相信社区会接受这样的标准。”

【解决方案1】：

我认为“我更喜欢它”不属于存在正当理由的特定情况，因为该理由适用于您本人，而不是代码库或项目。

我能想到一些其他的例子来证明不应该：

因此它不是严格禁止的，但显然是不鼓励的；可能是因为它提供了冗余信息，这些信息可能会在进一步重构的过程中出现，甚至可能是错误的：

// r12345 Expose HTML escaping
public function _escapeHtml(){
}

【讨论】：

【解决方案2】：

让我们结合PSR-2 和RFC 2119：

在特定情况下可能存在正当理由使用单个下划线作为属性名称的前缀是可以接受的，甚至是有用的，但应了解全部含义并仔细权衡案件在使用单个下划线作为属性名称前缀之前。

所以回答你的问题：是的，它在技术上是合规的。 phpcs --standard=PSR2 仅发出警告也反映了这一点：

警告 |属性名称“$_foo”不应带有下划线前缀以表示可见性

AFAIR "_" 来自 PHP 没有任何可见性语言结构的时代。我不知道 PSR “_”政策的意图是什么，但 IMO 很可能是因为在引入可见性之后，没有正当理由再使用“_”了。

【讨论】：