編程初學者總是把大量的時間用在學習編程語言，語法，技巧和編程工具的使用上。他們認爲，如果掌握了這些技術技巧，他們就能成爲不錯的程序員。然 而，計算機編程的目的並不是關於精通這些技術、工具的，它是關於針對特定領域裏的特定問題創造出相應的解決方案，程序員通過相互合作來實現這些。所以，很 重要的一點，你需要能精確的用代碼表達出你的思想，讓其他人通過代碼能明白你的意圖。
讓我們先看看編程大師Robert C. Martin的傑作《Clean Code》裏的一句話：
“註釋的目的是爲了彌補代碼自身在表達上的不足。”
這句話可以簡單的理解爲如果你的代碼需要註釋，最有可能是你的代碼寫的很爛。同樣，如果在沒有註釋的情況下你無法用代碼完整的表達你對一個問題或一個算法的思路，那這就是一個失敗的信號。最終，這意味着你需要用註釋來闡明一部分的思想，而這部分在代碼裏是看不出來的。好的代碼能夠讓任何人在不需要任何註釋的情況下看懂。好的編碼風格能將所有有助於理解這個問題的所有信息都蘊含在代碼裏。
在編程理論中，有一個概念叫做“自我描述的源代碼”。對於一段代碼，一種常見的自我描述機制是遵循某種非嚴格定義的變量、方法、對象命名規則。這樣做的主要作用就是使源代碼更易讀易懂。所以，也就更容易維護和擴展。
這篇文章裏，我將舉出一些例子，說明什麼是“不好的代碼”，什麼是“清楚的代碼”
命名要能揭示意圖
如何命名，在編程中這永遠都是個老大難問題。有些程序員喜歡簡化、縮短或加密名稱，使得只有他們自己能懂。下面讓我們看一些例子：
不好的代碼：
1.int d;2.//
天數3.int ds;4.int dsm;5.int faid;“d”可以表示任何東西。作者使用註釋來表明他的意圖，卻沒有選擇用代碼來表示。而“faid”很容易導致誤解爲ID。
清楚的代碼：
1.int elapsedTimeInDays;2.int daysSinceCreation;3.int daysSinceModification;4.int fileAgeInDays;命名時避免含義引起誤解的信息
錯誤的信息比沒有信息更糟糕。有些程序員喜歡“隱藏”一些重要信息，有時候他們也會寫出一些讓人誤解的代碼。
不好的代碼：
1.Customer[]
customerList;2.Table
theTable;變量“customerList”其實不是個list。它是一個普通的array(或客戶集合)。除此之外，“theTable”是一個Table類型的對象(你可以用IDE容易的發現它的類型)，“the”這個詞是個不必要的干擾。
清楚的代碼：
1.Customer[]
customers;2.Table
customers;命名要有合適的長度
在高級編程語言中，變量名的長度通常不太限制。變量名幾乎可以任何長度。雖然如此，這也可能使代碼變得鬧心。
不好的代碼：
1.var
theCustomersListWithAllCustomersIncludedWithoutFilter;2.var
list;好的名稱應該只含有必要的詞彙來表達一個概念。任何不必要的字詞都會使名稱變長、難於理解。名稱越短越好，前提是能在上下文中表達完整的意思(下訂單這個場景中，“customersInOrder” 要比 “list” 好)。
清楚的代碼：
1.var
allCustomers;2.var
customersInOrder;命名時編碼規範保持一致，讓規範幫助理解代碼
所有的編程技術(語言)都 有自己的“風格”，叫做編碼規範。程序員應該在寫代碼時遵循這些習慣，因爲其他的程序員也知道這些，並按這種風格編寫。下面我們看一個沒有明顯規範的不好 的代碼例子。下面的這段代碼沒有遵循很好的已知的“編碼規範”(比如PascalCase, camelCase, Hungarian規範)。更糟糕的是，這有一個毫無意義的bool變量“change”。這是個動詞(用來描述動作)，但這裏的bool值是來描述一個 狀態，所以，這裏應該用一個形容詞更合適。
不好的代碼：
1.const int maxcount
= 12.bool change
= true3.public interface Repository4.private string NAME5.public class personaddress6.void getallorders()一段代碼，只看它的一部分，你就應該直接明白它是什麼類型，只需要看它的命名方法。
例如：你看到了“_name”，你就能知道它是個私有變量。你應該在任何地方都利用這種表示方法，沒有例外情況。
清楚的代碼：
1.const int MAXCOUNT
= 12.bool isChanged
= true3.public interface IRepository4.private string _name5.public class PersonAddress6.void GetAllOrders()命名時相同的概念用相同的詞表達
定義概念很難。在軟件開發過程中，很多時間都花在分析業務場景、思考正確的定義裏面所有的元素。這些概念永遠都是讓程序員頭痛的事。
不好的代碼：
1.//1.2.void LoadSingleData()3.void FetchDataFiltered()4.Void
GetAllData()5.//2.6.void SetDataToView();7.void SetObjectValue(int value)首先：
代碼的作者試圖表達“get the data”的概念，他使用了多個詞“load”，“fetch”，“get”。一個概念只用一個詞表達就行了(在同一個場景中)。
第二：
“set”這個詞用在了2個概念裏：第一是“data loading to view”，第二個是“setting a value of object”。這是兩個不同的概念，你應該使用不同的詞。
清楚的代碼：
1.//1.2.void GetSingleData()3.void GetDataFiltered()4.Void
GetAllData()5.//2.6.void LoadDataToView();7.void SetObjectValue(int value)命名時使用跟業務領域相關的詞
程序員寫的所有代碼都是跟業務領域場景邏輯相連的。爲了讓所有關係到這個問題的人都能更好的理解，程序中應該使用在領域環境中有意義的名稱。
不好的代碼：
1.public class EntitiesRelation2.{3.Entity
o1;4.Entity
o2;5.}當在編寫針對某個領域的代碼時，你應該始終考慮使用領域有聯繫的名稱。在將來，當另外一個人(不僅是程序員，也許是測試人員)接觸你的代碼時，他能輕鬆的理解這個業務領域裏你的代碼是什麼意思(不需要業務邏輯知識)。你首先考慮的應該是業務問題，之後纔是如何解決。
清楚的代碼：
1.public class ProductWithCategory2.{3.Entity
product;4.Entity
category;5.}命名時使用在特定環境裏有意義的詞
代碼里名稱都有自己的上下文。上下文對於理解一個名稱非常重要，因爲它能提供額外的信息。讓我們來看看一個典型的“地址”上下文：
不好的代碼：
1.string addressCity;2.string addressHomeNumber;3.string addressPostCode;在大多數情況中，“Post Code”通常是地址的一部分，很顯然，郵政編碼不能單獨使用(除非你是在開發一個專門處理郵編的應用)。所以，沒有必要在“PostCode”的前面加 上“address”。更重要的，所以的這些信息都有一個上下文容環境，一個命名空間，一個類。
在面向對象編程中，這裏應該用一個“Address”類來表達這個地址信息。
清楚的代碼：
1.class Address2.{3.string city;4.string homeNumber;5.string postCode;6.}命名方法總結
概述起來，做爲一個程序員，你應該：
- 命名是來表達概念的
- 注意名稱長度，名稱裏只該含有必要的詞語
- 編碼規範有助於理解代碼，你應該使用它
- 名稱不要混用
- 名稱在業務領域裏要有意義，在上下文裏有意義