译者：
本文来自 Android 大神 Jake Wharton,他是 ButerKnife 和 RxBinding 的开发者,
OkHttp，RxJava，Retrofit 等流行的 Android 开发库的重要贡献者，对安卓编程风格的演进具有不可磨灭的影响
每一天都会有为安卓应用和库编写的java代码携带着一种传染病诞生，这种传染病的名字就叫做匈牙利命名法。
匈牙利命名法在安卓领域的推广纯粹是个意外，然而它依然受到错误的辩护。让我们先来推垮几个常见的主张：
- “《安卓 java 代码风格指南》推荐使用匈牙利命名法”
根本就不存在所谓指导程序员如何编写java代码的《安卓java代码风格指南》，绝大部分人口中子虚乌有的编码风格指南来自于 《面向贡献者的 AOSP 代码样式指南》
你可不是在为AOSP项目编写代码，因此你并不需要遵循他们的指南。
即便你正在编写未来可能纳入AOSP的代码，你也不需要遵循这份指南,
几乎所有AOSP所导入的java库都没有遵循它，甚至AOSP项目中的一部分开发人员都没有这么做
- “Android 样例使用匈牙利命名法”
一些样例诞生于AOSP项目的开发平台所以它们奉行AOSP的风格。而那些不来自AOSP的样例，它们的作者要么错误地相信了别的主张，要么只是单纯地忘了纠正编写这些样例时所使用的风格
- “那些额外的信息为 code review 提供了帮助”
使用变量名前缀m和s分别可以声明变量是private/package的非静态成员或静态成员①，不然进行code review时将无法得知这些信息。这种方式能够推断那些代码改动②中不可见的变量。从而，不管怎样，一个变量的可见性都可以被显而易见地得知。
在我反驳这种观点之前，我们先来定义一下匈牙利命名法。根据维基百科，匈牙利命名法有两种：
- 系统命名法将变量的数据类型加入到变量名当中。
一个long类型的用户id在java中将被一个名为lUser的变量代表，以此来表示它的用途和数据类型
- 系统命名法将变量的数据类型加入到变量名当中。
- 应用命名法将变量在语义上的用途而不是逻辑上的用途或目的加入到变量名中。
保存私有信息的变量带有某种前缀（如mUserId）而保存公有信息的变量则有另一种前缀，或者压根没有前缀
- 应用命名法将变量在语义上的用途而不是逻辑上的用途或目的加入到变量名中。
那么当你看见一个成员变量被使用时，究竟哪一种信息对code review来说更重要，是它的可见性还是数据类型？
可见性在code review当中是一种无需关注的属性。成员变量已经出现并且能够被使用，而且它的可见性大概也已经在上一个改动中被审阅过了
然而，成员变量的类型对于其在代码改动中如何被使用有更加直接的影响。被正确调用的方法名，参数的位置，可以被调用的方法，这些全都与变量的类型直接相关。
因此提出应用匈牙利命名法是错误的不单只是因为它没有用处，还因为系统匈牙利命名法能提供更多有关的信息。这可不是在说你应该使用系统匈牙利命名法，数据类型和可见性时常改动，而你将会忘记修改它们的名字。毕竟并不难发现静态的mContext成员变量
- “额外的信息有助于开发”
Android Studio和IntelliJ IDEA会根据成员身份（静态或非静态）在视觉上区分非成员变量
IDE默认强制使用正确的可见性和数据类型，所以一个命名规定不会带来任何东西。简单敲击键盘，就会有弹窗显示变量的那三种（以及更多）属性。
- “我想像谷歌官方一样编写java代码”
尽管安卓和AOSP都是该公司的一部分，谷歌在他们的编码风格指南中积极明确地禁止了匈牙利命名法的使用。公开的java风格指南是AOSP经年累月的内部习惯固化的产物。
安卓起源于谷歌之外，AOSP团队早已染上了匈牙利命名的顽疾。现在对其进行修改将是一种无用的扰乱并且会给分支和第三方合作者带来冲突。
但你对下面这个观点的持续支持与实践能够让我们在人生中根除这种疾病
朋友就不该再让朋友使用匈牙利命名法③
— Jake Wharton
译者注：
① field(成员): 根据oracle提供的文档，field这个词在未特指的情况下指的是非静态的成员变量，
而在本文单纯指成员变量，没有额外的限定
② change(代码改动)：在该文中应指git等svn中的提交差异
③ 该文中标题中的不以及结尾处的两个朋友原文中分别使用的是 mNo,mFriends,sFriends,
这里直接舍弃了匈牙利命名法的前缀来翻译，至于作者使用这些前缀的意图，感兴趣的读者可以自行借助原文进行思考
网友评论