代碼編寫原則
這應(yīng)該是我第一次使用簡書發(fā)文章，之前一直都在CSDN上寫文章，無意之中看到了簡書這個平臺，發(fā)現(xiàn)其展示效果更加符合我的預(yù)期風(fēng)格，于是開始嘗試在這上面發(fā)布一些自己的文章。
以下內(nèi)容均來自我日常寫代碼過程之中的理解以及讀過Code Complete 2[代碼大全2]之后真正沉淀下來的東西。
變量命名
變量命名是所有編程人員都必須要做的工作，每個公司和個人也都有自己的風(fēng)格(我也不例外)，及時一千個人眼里有一千個哈姆雷特，這里面還是有一定的通用規(guī)則，下面我們一一道來。
(1).命名長度：個人認(rèn)為合適的命名長度應(yīng)該是在10-17個字符之間，當(dāng)然有一些簡單的變量可能通過更短的命名解決，但是這里希望給出的一種通用的規(guī)則。太長的名字例如:numberOfPeopleOnTheUsOlypicTeam,numberOfSeatsInTheStadium等等，這些雖然可以清楚的反映出變量名字的含義，但是不管是閱讀還是書寫上都有很大的障礙。太短的例如:n,np,max等等，很多都是我們初學(xué)時候使用的變量，這種變量估計只有當(dāng)事人才可以真正的理解其含義。長度適中的有:numTeamMembers,teamMembersTotal,seatCount這種，既能看出變量的具體含義(當(dāng)然需要結(jié)合變量出現(xiàn)的大環(huán)境)，長度又保持了適中。
(2).計算值限定詞： 計算值限定詞就是我們平時使用的解釋數(shù)量相關(guān)的一些詞語，比如我們經(jīng)常使用的Sum,Max,Average這種類型的詞語。我們經(jīng)常需要從一系列數(shù)據(jù)中產(chǎn)出如何我們要求的數(shù)據(jù)，比如均值，最大最小值等等。那么我們在變量中如何表示呢，我曾經(jīng)在公司中看到過這樣的變量:personCount,totalPerson,maxGrade，gradeMin...這種問題是我經(jīng)常遇到的不規(guī)范問題，每個人與每個人的編寫習(xí)慣都不一樣，有的人習(xí)慣把限定詞放到前面，有的人喜歡放后面，這導(dǎo)致了我們編寫過程之中遇到麻煩。就上的例子而言，其實personCount和totalPerson變量的意思一樣，都是用戶總量的意思，但是由于是不用的人編寫，所以導(dǎo)致了重復(fù)。現(xiàn)在給出常用的規(guī)范:personCount,gradeMax,gradeMin,gradeAverage。把限定詞都放在后面使用，這樣根據(jù)我們從左往右讀數(shù)據(jù)的習(xí)慣，我們首先看到的是變量的屬性，這往往也是我們首先關(guān)心的，然后看到的是限定詞，在代碼排布上也顯的比較整齊。還有一點就是關(guān)于num 的使用，經(jīng)?？吹絥umCustomers，customerNum這種，前者的num表示總量，后面的num代表下標(biāo)，這種num的通用會影響我們的使用，所以建議廢棄num，使用更合適的量詞代替。表示總量時候可以是用Count或者Total，表示下標(biāo)時候使用Index。
(3).變量風(fēng)格：變量風(fēng)格指的是我們在項目中編寫變量的習(xí)慣，例如下劃線類型:person_count,user_alive;駝峰類型:personCount,userAlive?；旧线@些都是我們經(jīng)常遇到的，在java中普遍使用的是駝峰類型，其他語言例如C++中我們看到下劃線類型會多一點。所以我們在項目中一定要采用統(tǒng)一的命名類型，要么是下劃線，要么是駝峰，不能同時出現(xiàn)。
(4).全局狀態(tài)變量：全局狀態(tài)變量值得是一些特定的數(shù)據(jù)變量(基本上是定值)，我們一般會在類的開頭或者一個專門的文件中聲明這些變量方便后面調(diào)用。針對這類變量我們采用默認(rèn)約定的變量命名規(guī)則：大寫加下劃線. 例如:ALIVE_STATUS,CONNECTION_NAME.
(5).枚舉類型變量:枚舉類型的變量采用的統(tǒng)一模型是:大寫字母開頭加小寫字母，中間用下劃線分割。例如:Color_Red,Color_Blue.但是這里有一點需要強調(diào)的是為了防止過多枚舉類型的帶來的疑惑，我們統(tǒng)一都在枚舉類型變量前面加上前綴，相當(dāng)于對變量歸屬的進一步說明，比如上面的Color就是我們添加的前綴。
(6).布爾類型變量:在這里我首先需要強調(diào)的是對于status的使用，很多同學(xué)習(xí)慣使用status表示某個變量的狀態(tài)，而不管它有多少個狀態(tài)。在這里給出規(guī)范性建議:如果變量有多于兩個狀態(tài)則可以使用Status，如果僅有兩個或者少于兩個的狀態(tài)則嚴(yán)禁使用Status,應(yīng)該使用更用描述性的詞語.例如:success,found,done,alive等等.這種變量的好處是我們在做If判斷的時候可以這樣子:if(found)-->含義一目了然。盡量不使用否定的變量，例如:notFound,notDone,這樣我們在做判斷的時候就要if(!notFound)-->雙重否定帶來的結(jié)果是不方便閱讀，因此應(yīng)該盡量避免。
(7).對仗詞:對仗詞就是一些同時出現(xiàn)的前后照應(yīng)的詞語組合,下面給出這些常用的組合:begin/end,first/last,locked/uplocked,min/max,next/pervious,old/new,opened/closed,visible/invisible,source/target(destination),up/down,head/tail....
函數(shù)編寫
(1).函數(shù)命名:函數(shù)一般是作為一個功能代碼塊，首選要保證的是其功能的單一性，所以函數(shù)名稱要一定體現(xiàn)出其功能。例如process(),compute()這種函數(shù)的命名其實就太過粗糙，我們?nèi)菀桩a(chǎn)生疑惑就是process what,compute what?看起來這種詞語具有很強的描述性，其實太過粗糙，我們往往應(yīng)該進一步去描述其方法名:computeUserStatus,processHandleResult等等。當(dāng)然函數(shù)單一性這個規(guī)范也有一定例外，但是只限于少數(shù)，例如我們就在ORM中經(jīng)常看到saveOrUpdate()這種方法。
(2).函數(shù)（代碼）內(nèi)容控制:其實這一塊內(nèi)容可以放到函數(shù)里面講，也可以放到代碼內(nèi)容里面講。我就稍微偷個懶統(tǒng)一在這里說一下好了。
? (2.1):避免跳來跳去的代碼:首先我們看下什么是跳來跳去的代碼:
這中代碼就出現(xiàn)在同類處理事件中，我們看起來往往會非常費勁，如果類似的步驟多了之后看起來就更費勁了，往往一頁還處理不了需要翻頁處理。為了能夠從頭往尾閱讀，我們通常把相關(guān)的代碼組織在一起:
現(xiàn)在我們完全不用跳躍地閱讀了，我們把相關(guān)的代碼都集中寫在一個位置了，這樣的話我們?nèi)菀讓⒉煌念惙指铋_來檢查，而且也更符合人么的閱讀習(xí)慣。這種代碼我們也成為直線型代碼。
? (2.2)：變量定義盡量靠近使用的地方:其實這里是一個稍微有爭議的地方，因為大多數(shù)的成員變量我們都習(xí)慣在類的開始就進行定義或者處理花，然后變量下面才是方法的聲明和邏輯的編寫，這樣的好處就是變量在統(tǒng)一的地方定義，檢查起來方便；但是弊端就是某些變量使用時候距離定義的位置相隔太遠(yuǎn)，在對業(yè)務(wù)代碼不熟悉的情況下往往需要到一個類的頂部才能確定這個變量。及時有這種弊端存在，為了代碼的整潔性，我還是支持這種結(jié)構(gòu)的?，F(xiàn)在我要說的函數(shù)內(nèi)的變量定義。因為函數(shù)的長度一般都保持在百行以內(nèi)，很多人覺得這時候變量定義的位置都隨意了，反正代碼這么短隨便在哪里都能一眼看得到，但是作為一個優(yōu)秀的編程人員，一定對自己是嚴(yán)格要求的。下面給出我的建議:變量定義盡量靠近初次使用變量的位置。這樣做的好處是我們能夠?qū)⒕植看a更加緊湊化的展現(xiàn)出來，在視覺上也不會產(chǎn)生跳躍感，更不會因為變量多的時候產(chǎn)生疑惑或者健忘。在代碼大全中還給出了一種衡量規(guī)則，有興趣的同學(xué)可以參考一下。
? (2.3)：if-else編寫的注意事項:平時我們在寫if-else語句時候可能沒有注意到的一個問題就是判斷邏輯的順序問題。例如:
這種寫法我相信大家不會陌生，眨眼一看沒有什么大問題。但是我現(xiàn)在給定一個適用場景，這是一個中國消費人群年齡普查計算，那么這里就有一點問題了。我們知道消費人群的大多數(shù)比例都在10歲以上，也就是說10歲以上的比重占得最多，其次是50歲以上和10歲以下，下面對這個語句進行改變:
改進的地方就是將出現(xiàn)比例最高的選項放在If判斷的最前位置，這樣做的好處就是可以盡快結(jié)束if判斷。當(dāng)然有些時候無法判斷哪個判斷條件成立的條件更大點，這時候就只能"隨性"一點書寫了。所以整體的建議就是:將成立概率高的條件寫在判斷的最前面，然后根據(jù)成立概率依次往下書寫。同樣的建議也適用于case編寫。
以上的說明都是我印象最深刻也是記憶最深刻的地方，至于類編寫過程的保證類功能單一，合理的內(nèi)部類抽象，類的劃分等等這些感覺都不太好講清楚，而且也是自己對這方面理解還不到位，所以暫時沒有寫出來。如果有哪位大牛對這方面也有自己的見解可以貼出來大家共同學(xué)習(xí)一下。
