在碼農(nóng)中有兩種人：程序員與好的程序員。也許我們從事編程工作已經(jīng)很多年了，并不是所有人都可以像稱職的好程序員那樣寫出高效的代碼。下面是Mehreen Tahir在 他的博客里 總結(jié)出幾種不講碼德的壞習慣，給我們編程拖了后腿。
1.注釋凌亂
我們經(jīng)常被告知需要認真在自己的代碼中加上注釋，使得其他人容易理解代碼的功能。但做的不合時宜，注釋反而顯得代碼更蠢。比如下面的例子：
/*
set the value of the number integer to 32
*/
int number = 32;
對于可以不言自明的編程代碼完全不必要畫蛇添足增加注釋。這些注釋被編譯器忽略掉，通常編程人員么會將其忽略。如果代碼已經(jīng)一目了然，你還會看這些注釋嗎？大學教授代碼編程的老師會講：“具有自釋性的代碼就是好的代碼?！?如果你的代碼本身復雜，難道覺得你可以只使用一兩句話就能夠解釋的明白嗎？
通常一個誤區(qū)就是認為編寫繁瑣代碼的人能夠通過注釋將它解釋很清楚。不過，這并不是說你永遠不用寫代碼注釋了。正確的做法就是在書寫簡介、緊湊、自釋性強的代碼同時，懂得選擇合適的地方、合適的方法給出代碼注釋。比如下面的一個例子：
function addSetEntry(set, value) {
/*
Don't return `set.add` because it's not chainable in IE 11.
*/
set.add(value);
return set;
}
2.代碼過寬
是不是見過下面這樣的代碼？
for (int i = 0; i < 10; ++i) { if (i % 2 * 0) continue; array[i] += 2; }
看似上面代碼寫的緊湊，但如不書寫成下面代碼更加易讀：
for (int i = 0; i < 10; ++i)
{
if (i % 2 * 0) continue;
array[i] += 2;
}
3.膠合詞語
原文作者使用Agglutination來說明在代碼簡單將多個詞語連寫在一起形成復雜的變量、函數(shù)名稱的臭習慣。比如下面的代碼：
public interface ConditionChecker
{
boolean checkCondition();
}
這個代碼就不如修改成下面的形式：
public interface Condition
{
boolean isTrue();
}
對比一下，就可以看出代碼的好壞。對于一些具有確定功能的函數(shù)名稱，比如對Exception的捕獲處理的函數(shù)，實際上就不需要總是將后綴加上Exception：
- OverflowException
- IndexOutOfRangeException
- InvalidOperationException
將它們直接寫成下面的形式更直接明了：
- Overflow
- IndexOutOfRange
- InvalidOperation
在任何時候省略冗余詞語，可以形成更加高效的代碼。
4.欠抽象
在編程中的抽象（Abstraction）是指通過函數(shù)、類、庫來將復雜算法進行封裝，對外提供簡明使用接口。就像我們駕駛汽車，無需過多了解發(fā)動機和傳統(tǒng)原理那樣。如果編程時代碼欠抽象，將過多的細節(jié)留給使用者，就像需要每位司機都需要懂得汽車工作原理那樣。比如下面的代碼：
If (profileByUserId.get(user.getId())
.containsKey(profile.getId())
{
……
}
除非有必要，實現(xiàn)函數(shù)調(diào)用的接口越簡潔越好。比如下面的代碼就是的代碼更加優(yōu)雅易讀。
if (user.canView(profile))
{
……
}
5.上帝類
人們通常將過大的類（class）稱為上帝類，是指維護了太多的功能，違反了單一職責原則，連上帝都看不懂你的代碼。
一般一個類同時滿足以下3個條件就是上帝類：
（1）CPFD (Capsules Providing Foreign Data) 從多個不相關(guān)類（模塊）中引用數(shù)據(jù)。
（2）WOC (Weighted Operation Count) 類的所有函數(shù)的圈復雜度之和超過65。
（3）TCC (Tight Capsule Cohesion) TCC < 1/3 類需要具有低內(nèi)聚的特性（類中直接相關(guān)的方法與全部方法之比小于1/3），也就是較少的private方法。
為什么編寫上帝類是壞的碼德呢？這是因為過大的類往往會有很多重復代碼，且被子類繼承時也會造成大量內(nèi)存浪費。
6.拷貝粘貼
重復代碼一般是由于復制粘貼造成的。需求迭代過程中為了不影響已有功能，通常是將別人代碼copy一份改改。這種壞毛病最大弊端是最直接的弊端就是如果你想修改一段代碼邏輯，可能會遺漏，甚至需要多次修改才能確保全部修改完。當然，那種只是拷貝粘貼，連代碼都不審查的做法更是人神共憤了。
7.過長的參數(shù)
全局變量是個邪惡的東西，數(shù)據(jù)是共享的并且每個線程都可以修改，太多了容易導致程序不可控，所以大家喜歡將變量以行參的方式傳遞，久而久之參數(shù)列越來越長了。
為什么過長參數(shù)列是一種不好的碼德呢？
方法參數(shù)的數(shù)量太多會導致代碼可讀性非常差，如果有多個重載方法它們的方法參數(shù)都非常多，在寫代碼時很難判斷該調(diào)用哪一個。當一個方法需要新增功能，每次都可能會新增一個方法參數(shù)，這樣導致調(diào)用方每次都要重新適配，小心被打哦，耗子尾汁。
那么，當參數(shù)過長怎么辦？可以使用一個數(shù)據(jù)傳輸對象來進行傳輸?；蛘呖紤]重構(gòu)函數(shù)來解決過長參數(shù)傳遞。
8.虛榮的預留特性
有的時候會聽到合作開發(fā)的小伙伴夸夸其談，講什么在設計程序代碼中預留了擴展性，但這些擴展特性在當下實屬聾子的耳朵-擺設。關(guān)鍵這種預留擴展特性 一旦成為風氣，過度的抽象和預留擴展最終可能會讓軟件代碼難以理解，提前背上包袱，使得軟件開發(fā)變得復雜，進展速度慢下來。
此時，需要堅持簡單設計原則（Simple Design），刪除那些覺的可能未來有用的參數(shù)、代碼、調(diào)用等。
如果代碼的改動確實是未來必然會發(fā)現(xiàn)的，那么還是建議保留?？淇淦湔勎磥硇愿嗍侵搁_發(fā)人員無依據(jù)臆測未來，導致代碼模塊被過度設計。
免責聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
