只有代碼會告訴你真相
程序的終極語義由它的運行代碼給出。如果它只有二進制的形式，那將非常難以閱讀！然而，如果是你的程序、任何典型的商業軟件開發、開源項目或者動態的解釋型語言程序，都是有源代碼的。看一下源代碼，程序的意思就應該清楚明瞭了。要了解一個程序做了什麼，源代碼是你最終肯定應該看的。即便是最精確的需求文檔也沒有說明全部真相：它沒有包含程序真正做什麼的詳細信息，只有需求分析中的高層意圖。設計文檔中可能會包含有計劃性的設計，但是缺乏實現的必需細節。這些文檔也可能與當前的實現不同步......或者可能已經弄丟了，或者一開始就沒有寫過。剩下的就只有源代碼了。
頭腦中有了這個觀點，問一下你自己，你的代碼有多清晰地向你或者其它程序員說明了它在做什麼？
你可能會說，“噢，我的註釋會告訴你需要知道的一切。”但是記住，註釋不是運行代碼，它們可能會像其它文檔一樣是錯誤的。有一種傳統說註釋無條件地是好的，因而無疑有些程序員寫了越來越多的潘秋，即便是在複述和解釋細微的已經很明顯的代碼。這不是讓代碼清晰的正確方法。如果你的代碼需要註釋，可以考慮通過重構讓它不需要。冗長的註釋可以弄亂你的屏幕空間，甚至可能會被IDE自動隱藏。如果你需要解釋一項修改，在版本控制系統的提交信息中做，而不要放在源代碼中。
怎麼做才能真正讓代碼儘可能地說明真相呢？努力選擇好的名字。結構化代碼使功能更內聚，也讓命名更輕鬆；解耦功能實現正交。編寫自動化的測試來解釋目的行爲並檢查接口。當知道如何編碼一個更容易、更好的解決方案時，毫不猶豫地重構代碼。讓代碼儘可能容易閱讀和理解。
像任何其它作品，如詩歌、小品文、公開博客或者重要的電子郵件一樣對待你的代碼。仔細、精心地表達，它就會做它應該做的，並且儘可能直接地傳達它正在做的，這樣它就會在你不在旁邊時也能傳達你的目的。記住有用的代碼往往比它計劃的要使用更多的時間。負責維護的程序員會感謝你。同時，如果你是一個負責維護的程序員，而代碼又不能清楚地告訴你其中的真相，積極主動地應用以上指導吧。在代碼中建立理智，並保持自己明智。