1、引言：
這個(gè)標(biāo)準(zhǔn)是衡量代碼本身的缺陷，也是衡量一個(gè)研發(fā)人員本身的價(jià)值。華為作為一家全球化的 IT 公司，十幾萬員工，無論是人事管理，還是代碼管理，都是一件不容易的事情，沒有規(guī)范的約束，想想都是件可怕的事情。下面挑選了一些網(wǎng)上流傳的編程規(guī)范，一起來學(xué)習(xí)下，以下內(nèi)容不涉及基礎(chǔ)的語法規(guī)范（請(qǐng)見 Refer），更側(cè)重于一些編程習(xí)慣，如何提高程序的健壯性、可維護(hù)性等。（PS：以下內(nèi)容未經(jīng)官方考證，如閱讀者出現(xiàn)不適，請(qǐng)選擇立即關(guān)閉本頁 -_-||| ）
2、軍規(guī)簡(jiǎn)介：
軍規(guī)一：【避免在程序中使用魔鬼數(shù)字，必須用有意義的常量來標(biāo)識(shí)?！?/span>
軍規(guī)二：【明確方法的功能，一個(gè)方法僅完成一個(gè)功能?！?/span>
軍規(guī)三：【方法參數(shù)不能超過5個(gè)】
軍規(guī)四：【方法調(diào)用盡量不要返回null，取而代之以拋出異常，或是返回特例對(duì)象（SPECIAL CASE object，SPECIAL CASE PATTERN）；對(duì)于以集合或數(shù)組類型作為返回值的方法，取而代之以空集合或0長(zhǎng)度數(shù)組?！?/span>
軍規(guī)五：【在進(jìn)行數(shù)據(jù)庫(kù)操作或IO操作時(shí)，必須確保資源在使用完畢后得到釋放，并且必須確保釋放操作在finally中進(jìn)行?！?/span>
軍規(guī)六：【異常捕獲不要直接catch (Exception ex) ，應(yīng)該把異常細(xì)分處理?！?/span>
軍規(guī)七：【對(duì)于if ? else if ?(后續(xù)可能有多個(gè)else if …)這種類型的條件判斷，最后必須包含一個(gè)else分支，避免出現(xiàn)分支遺漏造成錯(cuò)誤；每個(gè)switch-case語句都必須保證有default，避免出現(xiàn)分支遺漏，造成錯(cuò)誤?！?/span>
軍規(guī)八：【覆寫對(duì)象的equals()方法時(shí)必須同時(shí)覆寫hashCode()方法?！?/span>
軍規(guī)九：【禁止循環(huán)中創(chuàng)建新線程，盡量使用線程池?！?/span>
軍規(guī)十：【在進(jìn)行精確計(jì)算時(shí)(例如:貨幣計(jì)算)避免使用float和double，浮點(diǎn)數(shù)計(jì)算都是不精確的，必須使用BigDecimal或?qū)⒏↑c(diǎn)數(shù)運(yùn)算轉(zhuǎn)換為整型運(yùn)算?！?nbsp;
3、軍規(guī)說明
軍規(guī)一：【避免在程序中使用魔鬼數(shù)字，必須用有意義的常量來標(biāo)識(shí)?！?/strong>
說明：是否是魔鬼數(shù)字要基于容易閱讀和便于全局替換的原則。0、1作為某種專業(yè)領(lǐng)域物理量枚舉數(shù)值時(shí)必須定義常量，嚴(yán)禁出現(xiàn)類似NUMBER_ZERO的“魔鬼常量”。
軍規(guī)二：【明確方法的功能，一個(gè)方法僅完成一個(gè)功能?！?/strong>
說明：方法功能太多，會(huì)增加方法的復(fù)雜度和依賴關(guān)系，不利于程序閱讀和將來的持續(xù)維護(hù)，無論是方法還是類設(shè)計(jì)都應(yīng)符合單一職責(zé)原則。
軍規(guī)三：【方法參數(shù)不能超過5個(gè)】
說明：參數(shù)太多影響代碼閱讀和使用，為減少參數(shù)，首先要考慮這些參數(shù)的合理性，保持方法功能單一、優(yōu)化方法設(shè)計(jì)，如果參數(shù)確實(shí)無法減少，可以將多個(gè)參數(shù)封裝成一個(gè)類（對(duì)象），同時(shí)考慮在新的類（對(duì)象）中增加相應(yīng)的行為，以期更符合OOP。
軍規(guī)四：【方法調(diào)用盡量不要返回null，取而代之以拋出異常，或是返回特例對(duì)象（SPECIAL CASE object，SPECIAL CASE PATTERN）；對(duì)于以集合或數(shù)組類型作為返回值的方法，取而代之以空集合或0長(zhǎng)度數(shù)組?！?/strong>
說明：返回null會(huì)增加不必要的空指針判斷，遺漏判斷也會(huì)導(dǎo)致嚴(yán)重的NullPointerException錯(cuò)誤。
軍規(guī)五：【在進(jìn)行數(shù)據(jù)庫(kù)操作或IO操作時(shí)，必須確保資源在使用完畢后得到釋放，并且必須確保釋放操作在finally中進(jìn)行?！?/strong>
說明：數(shù)據(jù)庫(kù)操作、IO操作等需要關(guān)閉對(duì)象必須在try -catch-finally 的finally中close()，如果有多個(gè)IO對(duì)象需要關(guān)閉，需要分別對(duì)每個(gè)對(duì)象的close()方法進(jìn)行try-catch,防止一個(gè)IO對(duì)象關(guān)閉失敗其他IO對(duì)象都未關(guān)閉。推薦做法如下：
Connection jdbcConnection = null;
Statement stmt = null;
try
{
........
}
catch(SQLException e)
{
........
}
finally
{
if(stmt != null)
{
try
{
stmt.close();
}
catch(SQLException e)
{
logger.log(Level.WARNING,"異常說明", e);
}
}
if(jdbcConnection != null)
{
try
{
jdbcConnection.close();
}
catch(SQLException e)
{
logger.log(Level.WARNING,"異常說明", e);
}
}
}軍規(guī)六：【異常捕獲不要直接 catch(Exception ex) ，應(yīng)該把異常細(xì)分處理?！?/strong>
說明：catch (Exception ex)的結(jié)果會(huì)把RuntimeException異常捕獲，RuntimeException是運(yùn)行期異常，是程序本身考慮不周而拋出的異常，是程序的BUG，如無效參數(shù)、數(shù)組越界、被零除等，程序必須確保不能拋出RuntimeException異常，不允許顯示捕獲RuntimeException異常就是為了方便測(cè)試中容易發(fā)現(xiàn)程序問題。
軍規(guī)七：【對(duì)于if ? else if ?(后續(xù)可能有多個(gè)elseif …)這種類型的條件判斷，最后必須包含一個(gè)else分支，避免出現(xiàn)分支遺漏造成錯(cuò)誤；每個(gè)switch-case語句都必須保證有default，避免出現(xiàn)分支遺漏，造成錯(cuò)誤?！?/strong>
軍規(guī)八：【覆寫對(duì)象的equals()方法時(shí)必須同時(shí)覆寫hashCode()方法?！?/strong>
說明：equals和hashCode方法是對(duì)象在hash容器內(nèi)高效工作的基礎(chǔ)，正確的覆寫這兩個(gè)方法才能保證在hash容器內(nèi)查找對(duì)象的正確性，同時(shí)一個(gè)好的hashCode方法能大幅提升hash容器效率。
軍規(guī)九：【禁止循環(huán)中創(chuàng)建新線程，盡量使用線程池?！?/strong>
軍規(guī)十：【在進(jìn)行精確計(jì)算時(shí)(例如:貨幣計(jì)算)避免使用float和double，浮點(diǎn)數(shù)計(jì)算都是不精確的，必須使用BigDecimal或?qū)⒏↑c(diǎn)數(shù)運(yùn)算轉(zhuǎn)換為整型運(yùn)算?！?/strong>
說明：浮點(diǎn)運(yùn)算在一個(gè)范圍很廣的值域上提供了很好的近似，但是它不能產(chǎn)生精確的結(jié)果。二進(jìn)制浮點(diǎn)對(duì)于精度計(jì)算是非常不適合的，因?yàn)樗豢赡軐?.1——或者10的其它任何次負(fù)冪精確表示為一個(gè)長(zhǎng)度有限的二進(jìn)制小數(shù)。
具體案例請(qǐng)參考：浮點(diǎn)數(shù)加法引發(fā)的問題：浮點(diǎn)數(shù)的二進(jìn)制表示
http://my.oschina.net/leejun2005/blog/156793
4、有關(guān)開發(fā)效率和協(xié)作的幾點(diǎn)建議與心得體會(huì)
今天看到某同學(xué)寫給團(tuán)隊(duì)成員的一封郵件，發(fā)現(xiàn)比較通用，分享出來吧:
1. 小提交:
把大的任務(wù)拆分成多個(gè)獨(dú)立小任務(wù)，每完成小任務(wù)確保無 Bug 后就可以提交合并到主分支甚至發(fā)布；頻繁提交有利于自己把控項(xiàng)目進(jìn)度、降低風(fēng)險(xiǎn)、同其他人協(xié)作和代碼 Review ; 每天可以提交合并多次。每個(gè)小任務(wù)是 1-2 個(gè)小時(shí)可以完成的粒度，最大的一天完成。并行做多個(gè)任務(wù)的時(shí)候，優(yōu)先做最短時(shí)間能夠?qū)崿F(xiàn)的任務(wù)。
2. 命名規(guī)范:
盡量避免無意義的字符做變量 比如 a, b, t ?？梢灾鸩礁纳?，可以參考:
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html
3. 避免過度設(shè)計(jì):
能夠用簡(jiǎn)單方式實(shí)現(xiàn)的功能，不引入復(fù)雜的類，對(duì)象，避免不必要的 new 對(duì)象，避免引入不必要的泛型、線程。開發(fā)初期冗余大于抽象和依賴。避免自己重新實(shí)現(xiàn)比較通用的組件和函數(shù)。調(diào)研多種實(shí)現(xiàn)方式的時(shí)候，選用做簡(jiǎn)單的實(shí)現(xiàn)方式。盡量少寫代碼。
4. Web 工程盡量避免在應(yīng)用內(nèi)部保存“狀態(tài)”，這樣可以適應(yīng)頻繁發(fā)布、重啟無影響。
5. 善于用打日志的方式調(diào)試，在程序關(guān)鍵點(diǎn)打日志。盡量少用斷點(diǎn)方式，日志方式可以批量調(diào)試一批功能，效率相對(duì)高。
6. 避免一屏顯示不下的超大函數(shù)。
7. 添加必要、簡(jiǎn)潔的注釋：
循環(huán)中的 continue, break 盡量加上單行注釋；盡量避免非函數(shù)結(jié)尾的 return，必要的時(shí)候加注釋。類自動(dòng)生成 toString() 方法，方便調(diào)試和打日志。
8. 不把自己局限到做某個(gè)功能，每個(gè)人都是整個(gè)項(xiàng)目的 Owner ，盡量交叉 Review ，交叉開發(fā)。
9. 遇到問題及時(shí)和其他人溝通，避免浪費(fèi)時(shí)間。
10. 從最終產(chǎn)品的目標(biāo)審視自己細(xì)小的設(shè)計(jì)，熟悉自己負(fù)責(zé)部分的上下游代碼。時(shí)刻關(guān)注最終產(chǎn)品(Web 界面和日志)，發(fā)現(xiàn) Bug 和可以改善的地方。
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問題，請(qǐng)聯(lián)系我們，謝謝！
下載文檔
