有人問：規范的命名風格真的能讓你程序員少出bug？
當遇到這方面的教訓時，就會想到這句話還是有點道理的。
工作快三年多了，從剛開始的什么都不懂，到慢慢發現積累知識點的重要性。關於程序的命名規范之前也做過一些筆記，只是感覺不全面，就一直沒有寫出來。
直到前段時間看了鄒溪源老師的這篇成就卓越代碼,從關注細節開始
引發了我的感觸，再不總結，都快2020年了，頭發都掉了不少。
曾經剛工作的時候，命名也挺隨意的，現在看起來，都有點想打過去的自己。總有這樣的一個過程，有些知識點，在潛意識里並不知道要去了解深入它。
看看這些10中詭異的程序命名，你遇到幾個？
03 自己的姓名來命名類和方法
這一case來自鄒溪源老師文章成就卓越代碼,從關注細節開始的第一段落
用自己姓名來命名，我是真沒遇到過，鄒老師是一位80后程序員，見多識廣。所以碰到過這樣case，我就分享一下
/// <summary>
/// author:zhangsan
/// </summary>
class ZhangsanTest
{
private void TestGetData()
{
int a, b, c;
}
private int ZhangsanGet(int s1, int s2)
{
int s3 = s1 + s2;
return s3;
}
private List<string> GetData()
{
return null;
}
}
這是一個喜歡用自己的姓名來命名類和方法的作者，在他的代碼中，經常可以看到這樣奇怪的對象定義，而且他還喜歡用a,b,c,d,e,f或者s1,s2這樣的命名，仿佛他的代碼自帶混淆特效。這樣的代碼嗅起來會不會覺得充斥着奇怪的味道？
建議：名字來命名這事兒挺嚴肅的，畢竟后面接手的人可能會認識你這個沙雕
04 加了魔幻的方法命名
private void GetData()
{
int a, b, c;
}
這個我是真的見過，看到鄒老師分享，我抽了根煙，相見恨晚.png。
另外，有沒有發現有許多開發者喜歡用 GetData() 來定義獲取數據的方法？然后這個方法就成為一個萬金油的方法，不管是爬蟲采集、或者數據綁定，無論是 C# 寫的后端或者 Java 寫的后端代碼，或者用 vue 寫的前端代碼，仿佛在任何場景、任何數據應用都可以看到這樣的方法。
如果一個項目中，有十幾個地方都出現了這個** GetData() **方法，那種感覺一定非常難受
熟悉的名字，卻是千變萬幻的味道。
建議：這不是寫那個GetData的碼農嗎？你品，你細品！
05 歧義的命名
這也是我遇到的真實案例，為此付出了無意義的1個小時調試。將一個頁面的命名成this，可能覺得this好用，this挺喜歡好用。
比如這個：
x:Name="this"
調用的時候
Command="{Binding Source={x:Reference this},Path=BindingContext.EditCmd}"
當時就有點懵逼，這個this到底指的是什么。這種以關鍵字來命名的，估計是想報復同事。
良好的命名如這樣的：
<CheckBox x:Name="chkBoxChinese" />
<Label Text="chinese">
<Label.Triggers>
<DataTrigger TargetType="Label" Binding="{Binding Source={x:Reference chkBoxChinese}, Path=IsChecked}" Value="true">
<Setter Property="FontAttributes" Value="Italic, Bold" /> <Setter Property="FontSize" Value="Large" />
</DataTrigger>
</Label.Triggers>
</Label>
建議：禁止使用關鍵字來命名
06 數字化的命名
不要覺得，這事我最多也就上學時候干過。
全面發展，數字一體化。的卻挺全面，曾經做xamarin的時候，在一個activity的里面有5，6個按鈕，點了一個其他按鈕顯示不同狀態，於是每個按鈕變成dialog1、dialog2、dialog3
建議：根據實際的作用進行命名。
07 考驗眼神的命名
int materialFirstNum = 8;
int materialSecondNum = 11;
int materialSumNum = materialFirstNum + materialSecondNum ;
歡迎大家來找茬，良好的命名變量是讓人一看就明白，顧名思義。把不同的部分寫在中間，書寫時容易了，但是不容易檢查。（ps：這里指的書寫容易指的是寫material時，各種IDE會有提示）
比如這樣：
int firstMaterialNum = 8;
int secondMaterialNum = 11;
int sumMaterialNum = firstMaterialNum + secondMaterialNum ;
建議：如果有相似的名字，請把他們不同的部分卸載開頭，其次是結尾。
08 直接以類型來命名
List<MaterialModel> list =new List<MaterialModel>();
string[] array = { "","",""};
這種名字不好的地方有兩個
- 命名根本就不知道代表什么意思，毫無意義
- IDE提示也容易混淆，不容易輸入
有經驗的程序員肯定會寫出這個變量是代表什么意思的，比如這樣的
List<MaterialModel> materialList =new List<MaterialModel>();
string[] titleIdArray = { "","",""};
建議：不要寫與系統定義類型關鍵字的命名，命名要有意義。
09 不規范的方法名
比如這個命名：
public static int TwoNumSubtraction(int firstNum,int secondNum){
return firstNum - secondNum;
}
最好改成 動詞+名詞格式，subtraction的縮寫sub，這樣的好處是合適的縮寫顧名思義，SubTwoNum就知道是做兩個數的減法運算。
public static int SubTwoNum(int firstNum,int secondNum){
return firstNum - secondNum;
}
建議：方法名最好動詞+名詞格式
10 單詞拼錯的命名
SendMassage(...)看到這個，我感覺當時這哥們應該壓力挺大的。
data和date 組合拳式混寫，可能當時這個當事人自己也寫蒙了吧！
form、from 。這個我也曾經常容易寫錯，傻傻分不清！
dataOne, dataTwo, dataThree, DataFour (手動捂臉)
建議：這個我真啥建議的.....
結語：林子大了，什么鳥都有！最后問一句，什么是工作啊？
下篇會寫到，代碼命名方式有哪些？代碼規范會寫成一個系列