第1條：一個實體應(yīng)該只有一個緊湊的職責
    單一職責原則。這個原則并不那么容易執(zhí)行，即使是STL這樣的程序庫，也一樣會犯違反該原則的錯誤。在這里，舉了兩個違反這一原則的實現(xiàn)：realloc和stl 中的basic_string。不過，對于basic_string，我想比起MFC中的CString還是好了不少。在《Exceptional C++ style》中，對basic_string作了剖析，并且得出一個普遍的原則：盡量將函數(shù)實現(xiàn)為獨立的函數(shù)而不是成員函數(shù)。
     嘗試用一句話來說明一個模塊的功能，既不多，也不少。如果無法用這樣的一句話加以概括，那么重新考慮規(guī)劃該模塊的職責?！　?BR>    第2條：正確、簡單和清晰第一
    簡單的說，堅持KISS原則：正確優(yōu)于速度，簡單優(yōu)于復(fù)雜，清晰優(yōu)于機巧，安全優(yōu)于不安全。
    程序必須為閱讀它的人編寫，只是順便用于機器執(zhí)行 * 編寫程序應(yīng)該以人為本，計算機第二
    計算機系統(tǒng)中、最快速、最可靠的組件都還不存在
    ......簡單設(shè)計的重要性怎么強調(diào)也不過分
    使一個正確的程序變快，比使一個快速的程序正確要容易的多
    避免使用程序設(shè)計語言的冷僻特性，應(yīng)該使用最簡單的有效技術(shù)
    不要毫無節(jié)制地重載運算符。
    不要濫用匿名變量，合理使用命名變量。當然，這不是說連vector().swap(other)這樣的慣用法也要排斥?！?BR>    第3條：編程中應(yīng)知道何時和如何考慮可伸縮性
    從字面上來看，這差不多等于外交辭令。答案無非是“適當?shù)摹睍r候“適當?shù)亍笨紤]可伸縮性。這非常依賴于軟件工程師的經(jīng)驗和知識。所以，本條目也“適當?shù)亍被乇芰四欠N缺乏營養(yǎng)的教導(dǎo)，著重討論算法復(fù)雜度的選擇問題。
    基本上，線性復(fù)雜度可以作為一個算法是否可選的分界點。值得花費精力避免選擇差于線性復(fù)雜度的算法，而不差于線性復(fù)雜度的算法則可以接受。所以，把性能放在嘴邊的兄弟們注意了，你的精力可別放錯了地方，高德納言猶在耳：不成熟的優(yōu)化是程序設(shè)計中的萬惡之源。必要時，先努力優(yōu)化復(fù)雜度（選擇好的算法----算法無用論者，去面壁?。?。
    順便提一句排序算法，通用排序算法的復(fù)雜度是O(NlgN)，但是特定領(lǐng)域完全可以有更好復(fù)雜度的算法