传统的C++开发中比较流行匈牙利命名法。这种方法最早有微软的一个匈牙利程序员提出，后来推而广之，大家都了解并且使用起来。变量/类变量签名添加m/s前缀，就是从这种命名方法衍生出来的。
考虑匈牙利命名法的产生背景，我们可以大致了解这种方法的产生以及流行的原因：
- 该方法产生与上世纪80年代左右，当时的IDE并没有现代IDE这样强大的功能基本与文本编辑器没有多大的区别。在这样的IDE中，查询一个变量的类型、作用域很不方便。
- 当时的主流开发语言是面向过程、贴近底层的。而微软所使用的C/C++语言虽然名义上是强类型语言，但是实际提供了指针等功能(或者说是骚操作)，允许程序员偷摸的改变数据类型。所以在变量名中保留变量类型就有必要了。
而对于今天的Java程序员来说，这种方法已经可以废弃了。因为我们有强大的IDE，查看变量类型、作用域不再是障碍；而且Java是强类型语言，任何错误类型的转换都将引发崩溃，这保证变量一旦声明，其类型就不可能发生变化了。(子类化作为面向对象开发的基础，其类型向上兼容，且不应该让使用者区别对待。)
虽然在Java开发中我们并不使用复杂完整的匈牙利命名法，但是给变量添加m/s前缀还在坚强的活着。实际上，在现代IDE的加持下，这种方法已经变得低效且多余了：
- 自动补全功能会根据类名称推荐对应的变量名。部分情况下，推荐的变量名是够用的。
定义变量时的自动补全功能
- 默认的自动生成get/set方法模板不能正确识别m前缀，导致生成的方法不合理。
自动生成get/set方法-1
自动生成get/set方法-2
自动生成get/set方法-3
- 现代IDE提供了充足的字体与颜色效果，对类变量、静态变量、局部变量进行区分。
使用颜色与字体对不同作用域的变量进行区分
- 要想查看一个变量的具体信息，IDE也提供了方便的方法。而且通常情况下，一个m/s前缀并不能给我们更充足的信息。
在IDE中，点一下就知道变量的全部信息了
- 虽然Android SDK内使用m/s前缀，但是Java SDK源码并没有使用m/s前缀。所以我们很难说那种风格更标准或更官方。
Android SDK中的变量定义，添加了m前缀
Java SDK中的变量定义
- 担心与旧代码风格不一致？其实没有必要。代码总是变化的，随着时间推移、开发人员人事或素质的变化、开发理念的变化(比如今天流行MVP模式、明天流行MVVM模式，昨天大家讨论supportV4，明天就要迁移AndroidX等等等等)。相比这些，一个命名风格的变化就显得微不足道了。所以，拥抱变化吧。
网友评论