如果你在團隊中，格式一定要團隊一起決定，然後每個人都去遵從同樣的格式，這樣在閱讀時才不會感覺吃力。約定格式用不了多長時間，大概十分鐘就能完成約定，包括縮排、命名方法、注釋方法等。
**格式很重要，不可忽略，必須嚴肅對待。**格式關乎溝通，而溝通是專業開發者的頭等大事。或者你認為「讓**能工作」才是專業開發者的頭等大事。然而這是不對的，你今天編寫的功能，極有可能在下一版本中被修改，但**的可讀性卻會對以後可能發生的發生的修改行為產生深遠影響。原始**修改之後很久，其**風格和可讀性仍會影響到可維護性和擴充套件性。即使**已不復存在，你的風格和律條仍存活下來。
什麼樣的書寫格式比較好呢？
1） 向報紙學習，報紙會用大字型給出乙個標題，然後標題下第一段文字會有一段概述，再往下才是詳細描述。原始檔也要像報紙文章那樣，名稱應當簡單且一目了然。名稱本身應該足夠告訴我們是否在正確的模組中。原始檔最頂部應該給出高層次概念和演算法。細節應該往下漸次展開，直至找到原始檔中最底層的函式和細節。前面我們講過應該給函式分出抽象層級，抽象層級越高，越接近使用者語言描述，應該放在頂部，抽象層級越低，越接近底層實現，應放在後面。可能的話，抽象層級高的才設為公有，抽象層級低的應盡量設為私有。像報紙文章一般，我們指望最重要的概念先出來（抽象層級高的），指望以包括最少細節的方式表述它們。我們指望底層細節最後出來。這樣，我們就能掃過源**檔案，自最前面的幾個函式獲知要旨，而不至於沉溺到細節中。
2） 可以利用**的疏密表現出「功能模組」，功能集中的**之間不要插入空行，而功能分散，相對獨立的**應用空行來進行分隔，加上函式應該盡量短小的原則，從而在視覺上一眼能看出功能的邏輯分布。
3）功能相關的函式應該放到一起，例如前面乙個抽象層級高一些的函式，內部呼叫了乙個抽象層級低的函式，應在抽象層級高的函式之後緊跟著抽象層級低的被呼叫函式，形成乙個自頂向下貫穿模組的良好資訊流。應避免在類中摸索，從乙個函式跳到另乙個函式，上下求索，中斷思緒。
4）每個程式設計師都有自己喜歡的格式規則，但如果在乙個團隊中工作，就是團隊說了算。一組開發者應當認同一種格式風格，每個成員都應該採用那種風格。我們想要讓軟體擁有一以貫之的風格。我們不想讓它顯得是由一大票意見相左的個人所寫成。
高質量的類 《clean code》讀後感
類應該短小，從這個意義上來說，類和函式有很多相似點，但衡量函式的 小 可以通過 行數，而衡量類的大小是通過 權責 類的名稱應當描述其權責，實際上，命名正是幫助判斷類的長度的第乙個手段，如果無法為某個類命以精確的名稱，這個類大概就太長了。如果類的命名越含混，不夠精確，該類越有可能擁有過多權責。我們也應...
高質量的測試 《clean code》讀後感
tdd讓你的 可擴充套件 可維護 可復用，有了測試你就不擔心對 的修改！沒有測試，每次修改都可能帶來缺陷。無論架構多有擴充套件性，無論設計劃分得有多好，沒有了測試，你就很難做改動，因為你擔心改動會不會引入不可預知的缺陷。tdd有三定律 1 在編寫不能通過的單元測試前，不可編寫生產 2 只可編寫剛好無...
《監控》讀後感
監控 讀後感 監控 更合適被定義為一本偵探 它非常引人入勝地描述了幾起錯綜複雜的案件，描寫得棒極了，以致我夜以繼日地讀完了它，為的是找到事情的真相。它使用了倒序的方式，一開始，作者就用不安的口氣說道 到現在為止，我都無法從那些恐怖中掙脫開來。呵呵，到底是什麼事情呢，這麼勾人？很難為情，但我不得不說，...