代碼整潔之道-有解無憂

軟體質量不但依賴于架構及專案管理，還與代碼質量緊密相關，

代碼質量與整潔度成正比，干凈的代碼即在質量上較為可靠，也為后期維護、升級奠定良好基礎，

另一種概念叫做極限編程

原則

SOLID
DRY
KISS

童子軍軍規

讓營地比你來時更干凈

有意義的命名

名副其實，表達真實意義
不誤導
做有意義的區分，避免 a、b、c
可讀、可搜索

函式

單一職責
行數 20-100

函式引數

0引數最佳，3個引數已經勉為其難
標識引數丑陋不堪，向引數傳入布林值駭人聽聞
如果函式需要三個以上的引數，說明這些引數應該封裝為類了

Circle makeCircle(double x,double y,double radius);
Circle makeCircle(Point center,double radius);

class Foo {
    public function bar($flag = true) {
    }

無副作用

函式承諾只做一件事，實際上還做了其他的，

public class UserValidator {
private Cryptographer cryptographer;

public boolean checkPassword(String userName, String password){
    User user = UserGateway.findByName(userName) ;
    if (user != User.NULL) {
    String codedPhrase = user.getPhraseEncodedByPassword();
    String phrase = cryptographer.decrypt (codedPhrase,password );
    if("Valid Password".equals(phrase)){
    Session.initialize(); //實際上還做了session 初始化的操作
    return true;
    }
    return false;
}

要么抽離Session.initialize(),要么重命名為checkPasswordAndInitializeSession 不要給人誤導，

使用例外代替錯誤碼

使用錯誤碼就要定義錯誤碼列舉，列舉類被大量匯入呼叫，一旦增加或修改錯誤列舉，就要對所有引入的檔案進行編譯，

 if (deletePage(page)==E_OK){
        if (registry.deleteReference(page.name)==E_OK){
            if (configKeys.deleteKey(page.name.makeKey())==E_OK){
            logger.log("page deleted");
        } else {
            logger.log("configKey not deleted");
        } else {
            logger. log("deleteReference from registry failed");
        } else {
            logger.log("delete failed");
        }
      return E_ERROR;
    }

try {
    deletePage(page);
    registry.deleteReference(page.name);
    configKeys.deleteKey(page.name.makeKey());
}
catch (Exception e) {
    logger.log(e.getMessage());
}

注釋

注釋并不像辛德勒的名單，它們并不“純然地好”，實際上，注釋最多也就是一種必須的惡，若編程語言足夠有表達力，或者我們長于用這些語言來表達意圖，就不那么需要注釋——也許根本不需要，

注釋掉的代碼

20世紀60年代，曾經有那么一段時間，注釋掉的代碼可能有用，但我們已經擁有優良的源代碼控制系統如此之久，這些系統可以為我們記住不要的代碼，我們無需再用注釋來標記，刪掉即可，它們丟不了，我擔保，

格式

檔案長度

200-500

行字符數

上限120

物件和資料結構

德莫特定律

著名的得墨式耳律（The Law of Demeter)認為，模塊不應了解它所操作物件的內部形，如上節所見，物件隱藏資料，曝露操作，這意味著物件不應通過存取器曝露其內部結構
因為這樣更像是曝露而非隱藏其內部結構，
更準確地說，得墨式耳律認為，類C的方法f只應該呼叫以下物件的方法：

C
由f創建的物件；
作為引數傳遞給f的物件；
由C的物體變數持有的物件，

null

別傳null值
別回傳null值

系統

“復雜要人命，它消磨開發者的生命，讓產品難以規劃、構建和測驗，”
——Ray Ozzie,微軟公司首席技術官

依賴注入

在依賴管理情景中，物件不應負責物體化對自身的依賴，反之，它應當將這份權責移交給其他“有權力”的機制，從而實作控制的反轉，因為初始設定是一種全域問題，這種授權機制通常要么是main例程，要么是有特定目的的容器，

擴容

“一開始就做對系統”純屬神話，

代理

AOP有時會與實作它的技術相混淆，例如方法攔截和通過代理做的“封包”，AOP系統的真正價值在于用簡潔和模塊化的方式指定系統行為，

并發編程

并發編程很難，非常難，如果你不那么細
心，就會搞出不堪入目的東西來，看看以下常見的迷思和誤解：

并發總能改進性能
并發有時能改進性能，但只在多個執行緒或處理器之間能分享大量等待時間的時候管用，
事情沒那么簡單，
撰寫并發程式無需修改設計
事實上，并發演算法的設計有可能與單執行緒系統的設計極不相同，目的與時機的解藕往往對系統結構產生巨大影響，
在采用Web或EJB容器的時候，理解并發問題并不重要
實際上，你最好了解容器在做什么，了解如何對付本章后文將提到的并發更新、死鎖等問題，

下面是一些有關撰寫并發軟體的中肯說法：

并發會在性能和撰寫額外代碼上增加一些開銷；
正確的并發是復雜的，即便對于簡單的問題也是如此；
并發缺陷并非總能重現，所以常被看做偶發事件而忽略，未被當做真的缺陷看待；
并發常常需要對設計策略的根本性修改，

味道建議

命名常量代替魔術數

準確

用浮點數表示貨幣幾近于犯罪，
因為你不想做并發更新就避免使用鎖和/或事務管理往好處說也是一種懶惰行為，在代碼中做決定時，確認自己足夠準確，
明確自己為何要這么做，如果遇到例外情況如何處理，
別懶得理會決定的準確性，如果你打算呼叫可能回傳null的函式，確認自己檢查了null值，
如果查詢你認為是資料庫中唯一的記錄，確保代碼檢查不存在其他記錄，
如果要處理貨幣資料，使用整數！并恰當地處理四舍五入，
如果可能有并發更新，確認你實作了某種鎖定機制，
代碼中的含糊和不準確要么是意見不同的結果，要么源于懶惰，無論原因是什么，都要消除，

回傳例外

   /**
     * 
     * @param array $awbnos
     * @throws Exception|ConnectionTimeOutException
     * @return array Description
     */
    public function fetchTrace(array $awbnos):array
    {
    }

php 利用 phpdoc 和 php7 特性能支持讓呼叫者注意例外和回傳值的正確處理，

 public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception{
 }

java 函式定義語法天生支持，

避免過多嵌套

基本法

單一職責，貫徹落實
短、少，類1000行，方法120行，引數3個，嚴格要求，
消滅mess,有1個就會有無數個
Later equals never 稍后等于永不，別等現在就去做
打磨，分解函式、修改名稱、消除重復，縮短和重新安置方法，有拆散類，同時保持測驗通過，保持重構、熱愛重構、注意單元測驗回歸測驗

代碼整潔之道

原則