最近在閱讀公司舊代碼纷跛，發(fā)現(xiàn)了很多的魔法數(shù)字或者字符串喻括，突然想起幾年前和同事討論的《什么時候采用常量，什么時候采用enum》事情贫奠，于是回憶一下唬血，并加上對魔法字符的比較，并記錄一下叮阅。
先簡單的對比一下
-
直接使用字符串
-
好處
直觀明了刁品，一眼就知道了這個值是什么意思，如：
ServiceName意思就是服務(wù)名修改方便浩姥，且影響小挑随，只影響當(dāng)前修改的地方，不影響其他任何地方
-
壞處
如果值不是可讀性強的內(nèi)容勒叠，會導(dǎo)致理解起來費勁兜挨，如：
outopgro膏孟，這種才用了縮寫的字段，或者過長的字段分散在代碼中拌汇，不利于統(tǒng)一管理：如果同一個字符串使用的地方過多柒桑，那么需要修改字符串的時候，就容易漏掉一些
-
-
使用常量
-
好處
可以定義一個比較有意義的名字噪舀，這樣在使用的時候魁淳，比較容易理解起內(nèi)容
統(tǒng)一管理，維護起來比較方便
-
壞處
- 容易誤用与倡，導(dǎo)致修改時影響到不該影響的地方：這個只能靠規(guī)范化界逛、代碼review去要求好
-
-
使用enum
-
好處
與常量一樣，統(tǒng)一進行管理纺座，方便維護
相比上面兩種息拜，增加了類型的檢測，不僅僅是值的檢測净响，如檢查狀態(tài)時少欺，多了狀態(tài)類的類型檢查
-
壞處
- 一般同一個類型里面，不能夠不建議定義過多內(nèi)容
-
各種適配場景對比
根據(jù)上面的對比馋贤，簡單總結(jié)了下三種類型的不停的使用場景
-
字符串赞别、數(shù)字等直接的值：只要是可控、可維護的范圍掸掸，那么就可以使用氯庆，大體可以參照下面的東西
出現(xiàn)次數(shù)比較少，一般檢測工具要求不超過3次
出現(xiàn)范圍比較小扰付，例如只在一個class中或者一個方法中使用，不會在很多地方使用
需要動態(tài)拼接的字符串仁讨，或者需要直接看到內(nèi)容的地方羽莺，如拼接SQL，如報錯信息：“XXX服務(wù)洞豁，出現(xiàn)了XXX錯誤盐固，請注意！”
-
常量：范圍廣丈挟，變量以取值為主刁卜，不需類型匹配
一些全局性的變量，如定義系統(tǒng)的error code
與其他服務(wù)交互時的一些固定變量曙咽，如前端控件的名字蛔趴，其他服務(wù)的名字
一些動態(tài)屬性的靜態(tài)字段，如動態(tài)表單中的一些常見屬性
-
枚舉：取值比較固定例朱，專項引用的地方
- 如：單據(jù)狀態(tài)孝情、用戶狀態(tài)
