目錄

• 01 措不及防的縮寫
• 02 中文命名
• 03 自己的姓名來命名類和方法
• 04 加了魔幻的方法命名
• 05 歧義的命名
• 06 數字化的命名
• 07 考驗眼神的命名
• 08 直接以型別來命名
• 09 不規範的方法名
• 10 單詞拼錯的命名

有人問：規範的命名風格真的能讓你程式設計師少出bug？
當遇到這方面的教訓時，就會想到這句話還是有點道理的。
工作快三年多了，從剛開始的什麼都不懂，到慢慢發現積累知識點的重要性。關於程式的命名規範之前也做過一些筆記，只是感覺不全面，就一直沒有寫出來。

直到前段時間看了鄒溪源老師的這篇成就卓越程式碼,從關注細節開始
引發了我的感觸，再不總結，都快2020年了，頭髮都掉了不少。

曾經剛工作的時候，命名也挺隨意的，現在看起來，都有點想打過去的自己。總有這樣的一個過程，有些知識點，在潛意識裡並不知道要去了解深入它。

01 措不及防的縮寫

一般來說如果單詞過長的話，會採用縮寫的方式，比如number 》num
CurrentUser>currUser。可是工作中，經常會遇到這種“便祕式”命名，給人一種措不及防的感覺。有時候還要利用想象的空間的，猜一下這個命名到底是個什麼玩意。
寫完整的算了，他不他偏要來個縮寫，縮寫後，我就看不懂（本身就不長，幹就萬事了。）
這是一段xaml引入名稱空間的程式碼，一個6個字元，縮寫後成功地變成5個字元，最終為大家節省了點選一個鍵的卡路里。common完美縮寫成comon

xmlns:comon="clr-namespace:SGS.SIO.Common.Utilities;assembly=SGS.SIO.Common"

建議：縮寫乾脆點，實在想不到好的縮寫，那就直接寫完整的單詞

02 中文命名

（ps:無法展示類似程式碼.png)不要覺得中文命名不可思議，我以前也是這樣覺得居然還有中文命名的，上一家公司就有這樣的例子。工作一段時間後，你可能會遇到一些幾年前甚至十年前的程式碼，什麼是工作啊？工作嘛......
每一種存在，都有他的存在的理由（ps：不管是好還是壞）。我的思考是，上一家公司採用中文命名是有一定的原因的，那些名詞如果英文來翻譯的話，非常容易歧義、難以理解、甚至跑偏，工作嘛，不能改變的時候，就只能去接受它。
建議：不要使用中文命名，萬不得已的情況下也不要，打上註釋也行啊

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 (手動捂臉)
建議：這個我真啥建議的.....

結語：林子大了，什麼鳥都有！最後問一句，什麼是工作啊？
下篇會寫到，程式碼命名方式有哪些？程式碼規範會寫成一個系列