一.不整潔代碼的壞處:
1.趕着推出產品，代碼寫得亂七八糟。特性越加越多，代碼也越來越爛，最後再也沒法管理這些代碼了。是糟糕的代碼毀了這家公司。
2.隨着混亂的增加，團隊生產力也持續下降，趨向於零。當生產力下降時，管理層就只有一件事可做了：增加更多人手到項目中，期望提升生產力。可是新人並不熟悉系統的設計。他們搞不清楚什麼樣的修改符合設計意圖，什麼樣的修改違背設計意圖。而且，他們以及團隊中的其他人都揹負着提升生產力的可怕壓力。於是，他們製造更多的混亂，驅動生產力向零那端不斷下降
3.糟糕的代碼引發混亂！別人修改糟糕的代碼時，往往會越改越爛。
4.編寫代碼的難度，取決於讀周邊代碼的難度。
5.單字母名稱和數字常量有個問題，就是很難在一大篇文字中找出來。 用常量名稱去說
6.好的代碼讓別人一眼就能明白
二.簡潔代碼原則:
1.每個函數、每個類和每個模塊都全神貫注於一事。
2.取名時名副其實、見名知意
a.變量的意義要體現在代碼段中，可那就是它們該在的地方
b.用常量而不是一個數字/字符串來表示邏輯關係。
c.變量名要提供導向作者意圖的線索
d.類名和對象名應該是名詞或名詞短語
e.方法名應當是動詞或動詞短語
3.函數:
a.函數的第一規則是要短小。第二條規則是還要更短小。20行以內
b.只做一件事
c.如果函數看來需要兩個、三個或三個以上參數，就說明其中一些參數應該封裝爲類了
d.函數要麼做什麼事，要麼回答什麼事: 函數應該修改某對象的狀態，或是返回該對象的有關信息。兩樣都幹常會導致混亂。
e.別返回以及傳遞null值
f.不要void,難讀懂
g.長表達式變成方法
4.格式:
a.封包聲明，導入聲明，變量聲明，每個函數之間用空白行隔開
b.變量聲明儘量靠近其使用的位置
c.有調用關係的函數儘量放在一起.調用者儘量在被調用者上面
5.對象和數據結構
a.變量私有，get/set
6.類:
a.類應該短小，有且只有一個加以修改的理由
b.類應該只有少量實體變量，類中的每一個方法都應該操作一個或多個這種變量。如果類的每個變量都被每個方法所使用，則該類具有最大的內聚性
c.希望內聚性保持在較高的位置
7.併發：
a.分離併發代碼和其它代碼
b.限制對可能被共享的數據的訪問(synchronized)
c.儘量只讀
d.多個線程收集副本的結果，在單個線程中合併
e.線程儘可能獨立,使用內部自己的變量