Php PSR-2第4.2节解释

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

他引用了《公约》第4.2节“财产”

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

var关键字不能用于声明属性

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

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

当我听到这个消息时，我很愤怒，因为我是私人和受保护的VAR前缀的忠实粉丝，我不敢相信社区会接受这样的标准

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

虽然我不同意这一点，并建议每个人在其私有和受保护的变量前面加一个下划线，但我怀疑这背后的原因是为了防止人们忽略scope关键字（Public、protected、private）而只依赖命名约定。这是因为，正如我们所知，没有范围变量PHP，一切都是公开的

总结一下问题：类PSR-2上私有变量和受保护变量的“u”前缀是否符合要求

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

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

我可以想出一些其他的例子来证明不应该：

• 项目依赖于一些第三方工具、框架，无论什么。。。这依赖于名称来识别可见性

• 类方法名称需要模仿使用这种约定的其他项目的名称（例如，因为它是另一种语言的端口）

• 项目是在PHP/5之前启动的。重命名将破坏向后兼容性

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

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

让我们结合并：

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

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

警告|属性名称“$\u foo”不应以下划线作为前缀以表示可见性

---

AFAIR“389;”来自PHP没有任何可见性语言构造的时代。我不知道PSR“u”政策的用意是什么，但在我看来，原因很可能是在引入可见性之后，再也没有有效的理由使用“u”。

永远不要使用它，当人们在变量名称中使用“uu”时，就讨厌它。好吧，不应该也不应该意味着两件不同的事情，对吗？@Dave我希望我的变量名尽可能具有描述性。我认为@MikeSherrill'CatRecall'（以及你自己的解释）一针见血。如果它只是说

属性名称不应该加前缀[…]

，那么这可能会引起争论。但他们列出了三条

不得

规则，然后说

不应

。对我来说似乎很清楚……如果你不是在“寻找个人偏好辩论”，那么就不要把你的个人偏好带进辩论中，比如：“我听到这件事时很愤怒，因为我非常喜欢私人和受保护的VAR的前缀，我不相信社区会接受这样的标准。”在办公室里进行了多次辩论后，人们认定这是最正确的答案。很难过看到这一切都消失了。。。我会想念它的。