代碼規範、本次衝刺任務與計劃

• 課程名稱：軟件工程1916|W（福州大學）
• 做業要求：項目Alpha衝刺——代碼規劃、衝刺任務與計劃
• 團隊名稱：葫蘆娃隊
• 做業目標：制定代碼規範、衝刺任務與接下來的計劃
• 團隊博客彙總：

隊員學號	隊員暱稱	博客地址
041602421	der himmel	https://www.cnblogs.com/wenghaoo
221600225	wuliaoBoring	https://www.cnblogs.com/wuliaoBoring/
221600424	BW.LIN	https://www.cnblogs.com/lbwblog/
221600432	QZY	https://www.cnblogs.com/nuomituanzi/ 組長
221600431	OFY	https://www.cnblogs.com/ofy666/
221600434	北風5620	https://www.cnblogs.com/beifeng5620/
221600435	XBN	https://www.cnblogs.com/xbnhhh/

---

1、註釋規約（重）

• 【強制】全部的方法要完成返回值、參數、異常說明外，還必須指出該方法作什麼事情，實現什麼功能。這種描述不該該包括執行過程細節（它是怎麼作的）
• 【強制】方法內部單行註釋，在被註釋語句上方另起一行，使用//註釋。方法內部多行註釋 使用/* */註釋，注意與代碼對齊。
• 【推薦】與其「半吊子」英文來註釋，不如用中文註釋把問題說清楚。專有名詞與關鍵字保持英文原文便可。
  反例：「TCP鏈接超時」解釋成「傳輸控制協議鏈接超時」，理解反而費腦筋。
• 【推薦】代碼修改的同時，註釋也要進行相應的修改，尤爲是參數、返回值、異常、核心邏輯等的修改。
  說明：代碼與註釋更新不一樣步，就像路網與導航軟件更新不一樣步同樣，若是導航軟件嚴重滯後，就失去了導航的意義。

• 【參考】謹慎註釋掉代碼。在上方詳細說明，而不是簡單地註釋掉。若是無用，則刪除。

• 說明：代碼被註釋掉有兩種可能性：
  • 後續會恢復此段代碼邏輯。
  • 永久不用。
  • 前者若是沒有備註信息，難以知曉註釋動機。後者建議直接刪掉（代碼倉庫保存了歷史代碼）。

、2、命名風格

• 【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不容許直接使用中文的方式。
  • 說明：正確的英文拼寫和語法可讓閱讀者易於理解，避免歧義。注意，即便純拼音命名方式也要避免採用。國際通用的名稱，可視同英文。
  • 反例：
    • DaZhePromotion [打折] 。
    • getPingfenByName() [評分] 。
    • int 某變量 = 3。
• 【強制】方法名、成員變量、類名使用 UpperCamelCase 風格，但如下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。
  • 正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
  • 反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
• 【強制】參數名、局部變量都統一使用 lowerCamelCase 風格，必須聽從駝峯形式。
  • 正例： localValue / getHttpMessage() / inputUserId
• 【強制】常量命名所有大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。
  • 正例：MAX_STOCK_COUNT反例：MAX_COUNT
• 【強制】抽象類命名使用 Abstract 或 Base 開頭；異常類命名使用 Exception 結尾；測試類 命名以它要測試的類的名稱開始，以 Test 結尾。
• 【強制】杜絕徹底不規範的縮寫，避免望文不知義。反例：AbstractClass「縮寫」命名成AbsClass；condition「縮寫」命名成 condi，此類隨 意縮寫嚴重下降了代碼的可閱讀性。
• 【推薦】爲了達到代碼自解釋的目標，任何自定義編程元素在命名時，使用盡可能完整的單詞組合來表達其意。
  • 正例：在 JDK 中，表達原子更新的類名爲：AtomicReferenceFieldUpdater。
  • 反例：變量 int a 的隨意命名方式。
    
    

---

3、任務與計劃安排