90%的程序員都犯過(guò)的代碼錯(cuò)誤
最近參加了多次的代碼review會(huì)，在review的過(guò)程中，發(fā)現(xiàn)有些問(wèn)題幾乎每次都出現(xiàn)。挑了幾個(gè)比較典型的問(wèn)題講解下。這幾個(gè)問(wèn)題都是初級(jí)問(wèn)題，解決方法都很容易。只要掌握了方法，有意識(shí)避免，能讓短時(shí)間內(nèi)迅速提高代碼質(zhì)量。真所謂投入小，見(jiàn)效快。
變量命名不清晰，一詞多義
為變量命名時(shí)最重要的考慮事項(xiàng)是，該名字要 完全、準(zhǔn)確地描述出該變量所代表的事務(wù) 。容易閱讀，不會(huì)與其他事務(wù)混淆。
例如：
- if(staff_id == 0)
- {
- printf("系統(tǒng)歸檔，不是員工歸檔");
- }
上面這段代碼，staff_id是員工號(hào)的意思，用staff_id為0表示是系統(tǒng)歸檔。一詞多義，本來(lái)應(yīng)該把系統(tǒng)和人分開(kāi)，但是混用到了一個(gè)變量。如果調(diào)用方出現(xiàn)個(gè)bug忘記把初始化的變量賦值，還會(huì)走到意外的邏輯。
解決方法是變量名稱(chēng)首先要符合變量的實(shí)際意義，沒(méi)有歧義；對(duì)于一個(gè)變量名，不用特定值表示特殊邏輯。
有些代碼會(huì)把變量取不到的值賦予其他的意義，感覺(jué)是省事了，實(shí)際后患無(wú)窮。例如用戶(hù)名不可能為空，就用空值表示這個(gè)用戶(hù)數(shù)據(jù)已經(jīng)被刪除了。而且判定數(shù)據(jù)是否刪除的代碼看著也讓人莫名其妙。
總之，變量命名要保證沒(méi)有「潛規(guī)則」，防止給自己挖坑。
使用魔數(shù)
命名不清晰更嚴(yán)重的是，沒(méi)有命名，直接用魔數(shù)。如果連注釋都沒(méi)有，就只能靠猜。
使用魔數(shù)有兩個(gè)不好的地方：
1、不方便修改。
使用常量替換魔數(shù)是一種將程序「參數(shù)化」的方法，需要修改改動(dòng)一處就可以了，而不必代碼中到處修改。
例如在代碼中默認(rèn)綁定的端口是80，如果不用一個(gè)常量代替，哪天軟件升級(jí)默認(rèn)端口變成443了。要整個(gè)代碼搜索80這個(gè)數(shù)字，既耗時(shí)，又容易改錯(cuò)。
2、代碼不方便閱讀。
只有一個(gè)數(shù)字，很難了解到具體的意思。
- for(int i = 0; i < 13; ++i)
- {
- ...
- }
上面這段代碼，只看13，誰(shuí)能猜出來(lái)是什么意思呢，為什么用13這個(gè)數(shù)值？可能只有寫(xiě)代碼的人和上帝知道，如果天長(zhǎng)日久，寫(xiě)代碼的人忘記了，就只有上帝知道了。
也有同學(xué)會(huì)問(wèn)，有的數(shù)字只用到一個(gè)地方，也起個(gè)常量的名字會(huì)不會(huì)太麻煩了？
答案是：不麻煩。給魔數(shù)起個(gè)好名字是應(yīng)該的，這是對(duì)的事，不要因?yàn)槁闊┚筒蛔觥Ｓ袝r(shí)為了起個(gè)準(zhǔn)確的名字，甚至要查下詞典。
有一個(gè)常用的判定方式：
一、如果引用魔數(shù)的地方不超過(guò)3個(gè)，直接用數(shù)字影響也不大。如果超過(guò)了3個(gè)，都是表示同一個(gè)數(shù)值意義，還是乖乖地用有意義的變量名代替。
二、如果魔數(shù)本身就是表示一個(gè)純粹的數(shù)字定義，例如是幾米、幾千克這種，作為參數(shù)傳遞。在函數(shù)的定義明確表示了形參數(shù)所代表的意義。大家看用到的地方和函數(shù)定義，就知道數(shù)字是表示多少個(gè)單位的意思，可以用魔數(shù)。但是如果用數(shù)字表示種類(lèi)，例如
- const int ieBrowser=1;
- const int chromeBrowser=2;
表示瀏覽器的種類(lèi)，如果直接只是看到1或2，是不明白什么意思的。即使在函數(shù)聲明的地方已經(jīng)說(shuō)過(guò)是瀏覽器種類(lèi)了，也不要用魔數(shù)。
魔數(shù)解決的辦法很簡(jiǎn)單： 用枚舉、常量等方式，代替魔數(shù) 。
if else 或switch等邏輯判斷語(yǔ)句太長(zhǎng)
例如下面的偽代碼代碼，條件分支很多，用很長(zhǎng)的if else語(yǔ)句或者switch語(yǔ)句才能表達(dá)完整的邏輯，要思考下是否能用「表驅(qū)動(dòng)」方式來(lái)優(yōu)化。
- const int CN=1;
- const int US=2;
- const int UK=3;
- string language;
- if(country==CN)
- {
- language="中文";
- }
- else if(country==US)
- {
- language="english";
- }
- else if(country==UK)
- {
- language="english";
- }
- else
- {
- language="";
- }
條件分支太多太長(zhǎng)有幾點(diǎn)不好：
1、代碼太長(zhǎng)，不易閱讀。
如果超過(guò)了一個(gè)屏幕能表示的長(zhǎng)度，要翻頁(yè)才能看完代碼，會(huì)大大降低看代碼的效率。因?yàn)榇a的信息密度太低了。
2、不易擴(kuò)展，修改代碼。
就像上面的例子，如果又增加了新的條件判斷，那么要增加新的if else語(yǔ)句，由于修改了邏輯，要重新測(cè)試，也要防止改錯(cuò)。
可以用「表驅(qū)動(dòng)」的方式替代太長(zhǎng)的邏輯分支。
把每個(gè)條件要用到的數(shù)據(jù)放到一個(gè)「表」里。用條件分支的判斷條件來(lái)索引到表中的數(shù)據(jù)。
上面的代碼可以修改為
- const int CN=1;
- const int US=2;
- const int UK=3;
- string languageTable[]={"","中文","English","English"};
- //先判斷country變量是否在定義的CN、US、UK范圍內(nèi)，如果在繼續(xù)
- language = languageTable[country];
經(jīng)過(guò)修改，代碼變得很短，一眼就能看出代碼所表示的邏輯。而且以后更新的只有數(shù)據(jù)，邏輯部分不用修改。
使用「表驅(qū)動(dòng)」后，邏輯和數(shù)據(jù)分離。使得新增數(shù)據(jù)修改簡(jiǎn)單，而且一目了然。
總結(jié)
上面只是簡(jiǎn)單的說(shuō)明了幾種常見(jiàn)的代碼書(shū)寫(xiě)錯(cuò)誤。稍加注意，就能夠在短時(shí)間內(nèi)迅速提升代碼質(zhì)量。具體的方法可以參考一些代碼規(guī)范，或者重構(gòu)的書(shū)籍，例如「表驅(qū)動(dòng)」會(huì)有更詳盡的介紹。
最本質(zhì)的還是要從意識(shí)上有足夠的認(rèn)識(shí)。 代碼是寫(xiě)給人看的 ，寫(xiě)代碼時(shí)要有同理心，想到以后讓閱讀代碼的人盡量能夠不費(fèi)力讀懂。換位思考，如果你就是review人，或后面接手這個(gè)代碼的人，你會(huì)喜歡這段代碼嗎？
畢竟代碼閱讀的次數(shù)遠(yuǎn)遠(yuǎn)超過(guò)編寫(xiě)的次數(shù)。確保代碼閱讀方便，而不僅是編寫(xiě)方便。
