使用 _ 作为私有成员变量前缀

关于编码规范，每个程序员都有自己的看法，他们通常相信自己所奉行的规范是好的并且早已养成习惯，有些看法的意念特别强大，以至于上升到了一种信仰层面。
我个人觉得，编码规范不是个人习惯，比较好的态度是，信奉编码规范可以提升大家的效率，而坚守一个团队的编码规范，而不是，坚守某种固有的做法。至于
某种规范的条例是不是“很奇怪”，“不合理”，我们都可以讨论，但是讨论不代表不遵守，这才是比较职业化的态度。或者说，即便通过讨论，认定某个规范不合理，
我个人觉得，也应遵守这条不合理的规范，直到整个团队一致变更编码规范。

其实，我觉得，一个团队变更编码规范是几乎不可能的。首先，一个团队在制定编码规范的时候不是盲目的，一种做法在某些地方不合理，势必在另一些地方有好处，
一般不会有那种纯粹为了降低生产效率而设计的编码规范。其次，一旦编码规范固定下来，意味着，很多历史的代码都是奉行这一编码规范，一旦变更编码规范，可能
的坏处是，新写的代码使用新的编码规范，以前写的代码使用老的编码规范，两种规范，可能导致代码看起来没有规范，最终导致对规范的放任和代码的腐烂。

这里，想讨论一个 PHP 的编码规范，就是使用下划线，标记访问受限的成员变量和成员方法。我们团队使用的是 PSR-2 编码规范，主要是因为这个规范，比较
普遍，而且比较有影响力，我觉得这是一种不错的实践。这个规范中提到，不应（SHOULD NOT）使用下划线来标记成员的私有属性。

这个规范设立的理由是，以前，在 PHP 4 时代，因为类没有访问限制的特性，所以，需要通过命名规范来携带这个意思，就是不建议外部调用者来修改成员的值。
但是，到了 PHP 5 的时代，已经完美支持了访问限制的特性，所以，不应该再使用下划线前缀来达到同样的目的了。使用下划线区别公有私有的成员变量，仅仅
在视觉上仍然有意义了。

但是，我想说的是，似乎视觉上的区分，还是有意义的，因为，我自己使用的 NetBeans，还不能很有效从视觉上区分私有还是公有成员变量的区别，所以，在阅读
代码的时候，我还不能有效区分这个成员的访问控制，有时候，快速区分这个，还是有助于代码的理解的。

Visibility MUST be declared on all properties.

The var keyword MUST NOT be used to declare a property.

There MUST NOT be more than one property declared per statement.

Property names SHOULD NOT be prefixed with a single underscore to indicate protected or private visibility.

A property declaration looks like the following.

以上引用部分，是 PSR-2 的节选，可以看到不建议使用下划线。当然还没有上升到 MUST NOT 的程度，也就是并不绝对禁止这种写法，我看了 Yii 2.x 里面，
仍然有违反这条的地方，尽管 Yii 框架也是 PSR 的成员项目之一，也一定程度不完全接受这个条例。所以，我觉得，这种条例就可以拿出来仔细讨论一下了。

如果问我的建议，我觉得，这个标准奉行也行，不奉行也行，理由是，这个规范关乎的是私有的成员变量和成员方法，并不是影响提供给外部的接口，所以，即便
违反了，也不会给同伴带来困扰，毕竟，真正的可见性维护是靠语言层面去解决的。当然，局部性原则，也是在编码规范并不绝对反对的情况下，自由裁量的一个
依据。

从编码规范的制定，给出的这些建议的级别，我们可以得到的收获是，即便在编码这个形式语言的领域，完全客观的领域，也存在比较模糊的边界，可见，模糊才是
这个世界的本质，但是，约束仍然是要有的，在约束下，每个人才能达到最大的自有。