傳統(tǒng)的C++開(kāi)發(fā)中比較流行匈牙利命名法恬偷。這種方法最早有微軟的一個(gè)匈牙利程序員提出在辆，后來(lái)推而廣之规揪，大家都了解并且使用起來(lái)。變量/類變量簽名添加m/s前綴乍赫，就是從這種命名方法衍生出來(lái)的瓣蛀。
考慮匈牙利命名法的產(chǎn)生背景，我們可以大致了解這種方法的產(chǎn)生以及流行的原因：
- 該方法產(chǎn)生與上世紀(jì)80年代左右雷厂，當(dāng)時(shí)的IDE并沒(méi)有現(xiàn)代IDE這樣強(qiáng)大的功能基本與文本編輯器沒(méi)有多大的區(qū)別惋增。在這樣的IDE中，查詢一個(gè)變量的類型改鲫、作用域很不方便诈皿。
- 當(dāng)時(shí)的主流開(kāi)發(fā)語(yǔ)言是面向過(guò)程林束、貼近底層的。而微軟所使用的C/C++語(yǔ)言雖然名義上是強(qiáng)類型語(yǔ)言稽亏，但是實(shí)際提供了指針等功能(或者說(shuō)是騷操作)诊县，允許程序員偷摸的改變數(shù)據(jù)類型。所以在變量名中保留變量類型就有必要了措左。
而對(duì)于今天的Java程序員來(lái)說(shuō)，這種方法已經(jīng)可以廢棄了避除。因?yàn)槲覀冇袕?qiáng)大的IDE怎披，查看變量類型、作用域不再是障礙瓶摆；而且Java是強(qiáng)類型語(yǔ)言凉逛，任何錯(cuò)誤類型的轉(zhuǎn)換都將引發(fā)崩潰，這保證變量一旦聲明群井，其類型就不可能發(fā)生變化了状飞。(子類化作為面向?qū)ο箝_(kāi)發(fā)的基礎(chǔ)，其類型向上兼容书斜，且不應(yīng)該讓使用者區(qū)別對(duì)待诬辈。)
雖然在Java開(kāi)發(fā)中我們并不使用復(fù)雜完整的匈牙利命名法，但是給變量添加m/s前綴還在堅(jiān)強(qiáng)的活著荐吉。實(shí)際上焙糟，在現(xiàn)代IDE的加持下，這種方法已經(jīng)變得低效且多余了：
- 自動(dòng)補(bǔ)全功能會(huì)根據(jù)類名稱推薦對(duì)應(yīng)的變量名样屠。部分情況下穿撮，推薦的變量名是夠用的。
定義變量時(shí)的自動(dòng)補(bǔ)全功能
- 默認(rèn)的自動(dòng)生成get/set方法模板不能正確識(shí)別m前綴痪欲，導(dǎo)致生成的方法不合理悦穿。
自動(dòng)生成get/set方法-1
自動(dòng)生成get/set方法-2
自動(dòng)生成get/set方法-3
- 現(xiàn)代IDE提供了充足的字體與顏色效果，對(duì)類變量业踢、靜態(tài)變量栗柒、局部變量進(jìn)行區(qū)分。
使用顏色與字體對(duì)不同作用域的變量進(jìn)行區(qū)分
- 要想查看一個(gè)變量的具體信息陨亡，IDE也提供了方便的方法傍衡。而且通常情況下，一個(gè)m/s前綴并不能給我們更充足的信息负蠕。
在IDE中蛙埂，點(diǎn)一下就知道變量的全部信息了
- 雖然Android SDK內(nèi)使用m/s前綴，但是Java SDK源碼并沒(méi)有使用m/s前綴遮糖。所以我們很難說(shuō)那種風(fēng)格更標(biāo)準(zhǔn)或更官方绣的。
Android SDK中的變量定義，添加了m前綴
Java SDK中的變量定義
- 擔(dān)心與舊代碼風(fēng)格不一致？其實(shí)沒(méi)有必要屡江。代碼總是變化的芭概，隨著時(shí)間推移、開(kāi)發(fā)人員人事或素質(zhì)的變化惩嘉、開(kāi)發(fā)理念的變化(比如今天流行MVP模式罢洲、明天流行MVVM模式，昨天大家討論supportV4文黎，明天就要遷移AndroidX等等等等)惹苗。相比這些，一個(gè)命名風(fēng)格的變化就顯得微不足道了耸峭。所以桩蓉，擁抱變化吧。
