作者lion741205 (獅子)
看板Soft_Job
標題Re: [討論] 大家的命名習慣 - 現有命名方法彙整及比較
時間Sun Aug 18 17:31:43 2019
※ 引述《meokay (我可以)》之銘言：
: 如題
: 現在常常會Review別人的程式碼
: 發現大家的命名習慣都好不同
: 舉例來說
: 一個Func是Check Status
: 有的人會寫 void check_status()
: 也有的人寫 void checkStatus()
: 也有看過寫 void CStatus()
: 姑且不論第三種
: 那大致上就是分成底線派跟非底線派
: 大家的命名是哪種風格啊？
: 有沒有大大願意分享一下～
: 或是有什麼堅持xDD
: 我先投非底線派一票QQ
命名規則是為了增加識別和可讀性，沒有強制的規定，但一旦選擇其中一種，會建議編寫
時統一格式；而化學、天文、生物也有其慣用的命名方法；大部分的程式語言也有對此進
行建議，以統一風格。
在程式設計的命名上，當變數、函式及類別等名稱由兩個以上的單字組合，就可以使用現
有的命名方法，增加識別和可讀性。目前已經出現的命名方法，可以分為Underscore(底
線式)、Camel-case(駝峰式)及Hungarian notation(匈牙利命名法)三大類。此文進行彙
整，並以個人經驗，探討其優缺點。
------
Underscore(底線式)：
------
單字之間使用底線分隔，GNU/Linux環境中最常見，例如：string_name。
優點：使用底線取代空格，閱讀上比較直覺易懂。
缺點：比起Camel-case使用字首大寫取代空格，底線比較少在日常輸入，因此需要適應。
------
Camel-case(駝峰式)：
------
單字之間使用大寫分隔，又可以分為Lower Camel-case(小駝峰式)，或Upper
Camel-case(大駝峰式)，而後者又稱為Pascal-case(帕斯卡式)。
Lower Camel-case(小駝峰式)：
第一個字母用小寫，此變化常用在變數名稱上，例如stringName。
Upper Camel-case(大駝峰式)：
第一個字母用大寫，此變化常用在函數、類別、屬性及命名空間上，例如StringName。
優點：
可以利用名稱前綴的大小寫，區分變數，以及函數、類別等其他型別。
單字之間使用大寫取代底線，能夠減少名稱的長度，減少程式碼超出視窗被遮擋的情況。
缺點：
比起Underscore使用底線取代空格，閱讀上較不直覺易懂。
------
Hungarian notation(匈牙利命名法)
------
在Camel-case(駝峰式)的基礎上，在名稱前綴添加預先約定好的縮寫，例如約定如下：
b boolean
c character
str C++ String
si short integer
i integer
li long integer
f floating point
d double-precision floating point
ld long double-precision floating point
sz Old-Style Null Terminated String
if Input File Stream
is Input Stream
of Output File Stream
os Output Stream
S declaring a struct
C declaring a class
Source:
http://web.mst.edu/~cpp/common/hungarian.html
根據縮寫用途的不同，又可分為Systems Hungarian，以及Apps Hungarian。
Systems Hungarian：
名稱前前綴代表的是實際的資料型別，例如：strName。
Apps Hungarian：
名稱前綴代表的是目的或其他提示，例如：usName，其中us代表unsafe，為了避免Code
injection或XSS，之後必須進行過濾處理。
優點：
不需要IDE支援，就能夠從名稱能看出型別。
制定好的編碼規則，能夠在搜尋時更加統一易找。
制定好的編碼規則，能夠在命名及輸入上更快。
缺點：
需要另外學習編碼規則。
現代IDE已經可以輕易的區分型別，在資料型別上，此方法稍嫌多餘。
變數型別修改時，名稱也必須修正維護。
採用縮寫來命名，對新手較不友善，例如szName，不如stringZeroName。
也更容易造成歧義，例如szName，更容易被誤讀成其他意思，也難以Google。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.13.41.25 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1566120705.A.C1F.html
※ 編輯: lion741205 (101.13.41.25 臺灣), 08/18/2019 17:52:55
1F：→ EricTCartman: 匈牙利命名對現代IDE有多餘嗎？ 當有一堆member 08/18 18:05
2F：→ EricTCartman: variable或可選的變數時，我反而會直接從型別類型找 08/18 18:05
3F：→ EricTCartman: szXXX這種C-String命名法 取stringZero我反而會誤會 08/18 18:06
4F：推 abc0922001: 我現在也不用匈牙利命名法了 08/18 18:07
5F：→ EricTCartman: 不熟sz的慣用命名 應該只是寫得不夠多 看得不夠多 08/18 18:07
6F：→ EricTCartman: 有些idiom是廣為流傳 命名就看語言使用者/團隊習慣 08/18 18:09
7F：→ EricTCartman: 像pimpl 如果你不懂C++的idiom 當然看不懂 08/18 18:10
嗯，有些約定俗成的縮寫，有時候會造成新手混淆，但對老手來說很方便
※ 編輯: lion741205 (101.13.41.25 臺灣), 08/18/2019 18:16:13
8F：→ WunoW: 你列的這些約定成俗我都沒用過...... 08/18 18:15
9F：→ WunoW: is做input stream...?? 我是都當boolean變數啦 像isValid 08/18 18:16
只是為了講匈牙利命名找的範例，裡面的縮寫我也不全用的 XD
10F：→ EricTCartman: if/is/of/os我都看過 這真的看習慣 如果scope不大 08/18 18:18
11F：→ EricTCartman: 我是直接取stream 反正你function不超過20行不會有 08/18 18:19
12F：→ EricTCartman: 困擾 因為型別已經告訴你 08/18 18:19
※ 編輯: lion741205 (101.13.41.25 臺灣), 08/18/2019 18:20:50
13F：→ WunoW: 型別我會放後面 像amt/amtStr 這樣傳json就放在一起了 08/18 18:20
14F：→ EricTCartman: 匈牙利我覺得用在built-in type就好 OOP太多抽象的 08/18 18:21
15F：→ EricTCartman: 東西強迫自己想個有鑑別性的縮寫只是徒增困擾 08/18 18:21
16F：→ WunoW: amount->amt, member->mbr...之類的約定成俗反而更常見 08/18 18:21
17F：→ EricTCartman: member我看到比較多都寫m耶 C++啦 WunoW是寫哪個語 08/18 18:22
18F：→ EricTCartman: 言？ 08/18 18:22
19F：→ WunoW: 只寫m我也看過 但我都會盡量要求縮寫也要明確 08/18 18:30
20F：→ WunoW: C和C++派大概是我見過變數名稱最懶的... 08/18 18:30
21F：→ WunoW: 不然其實ide有按tab自動完成功能 變數長一點不會麻煩 08/18 18:32
22F：→ WunoW: 但命名明確一點我覺得還是對開發和維護都有好處 08/18 18:34
23F：→ WunoW: 不然專案多人開發 你的m不是我的m 不太好 08/18 18:35
24F：→ EricTCartman: XDDDD 08/18 18:37
25F：推 doranako: 三種我都有用過，大家有共識統一用什麼就用什麼，memb 08/18 19:14
26F：→ doranako: er variable近年多加底線來區分 08/18 19:14
27F：→ LinuxKernel: amt mbr 是啥鬼 08/18 19:42
28F：→ LinuxKernel: 有人的約定俗成不太一樣 08/18 19:42
29F：→ jej: 維護老屁股系統 各種命名都會遇到 還能在這挑是幸福啊 08/18 20:25
30F：推 bill0205: 今年初專案的會議結果光是命名規則就討論快3小時XDD 08/18 20:55
31F：→ bill0205: 最後共識還是駝峰式為主 08/18 20:55
32F：→ EricTCartman: 命名規則竟然能討論到三個小時 還 滿 屌 ㄉ 08/18 21:37
33F：→ MOONY135: svc 我覺得當service的變數不錯啊 08/18 21:50
34F：推 steve1012: 能不縮寫就不縮寫 08/19 03:42
35F：→ shooter555: 我也覺得不縮寫的好 以方便看為主 08/19 09:29
36F：→ shooter555: if input file這還真少見 08/19 09:31
37F：→ shooter555: 開頭大寫的駝峰式也愈來愈常見 因為很多protocol文件 08/19 09:32
38F：→ shooter555: 都是開頭大寫駝峰式 變數命名也直接照搬 08/19 09:33
39F：→ shooter555: ZoneNameString 這種放後面的也愈來愈常見 08/19 09:34
40F：推 jason710068: 匈牙利命名稍微有碰過win32 api應該都知道在幹嘛，但 08/19 09:49
41F：→ jason710068: 可能不知道那個叫匈牙利命名 08/19 09:49
42F：→ eva19452002: 有人說匈牙利命名很難閱讀，是真的嗎？ 08/19 09:52
我覺得編碼約定做得好，能夠統一寫法，反而有利團隊閱讀、搜尋和命名，
只是對專案新人或以後接手的人比較不友善，還要另外去了解那些縮寫的含意；
比起寫清楚講明白，更容易造成歧義，所以有些書提倡不要使用匈牙利命名法。
44F：→ hooll111: de-72688451 08/19 10:25
45F：推 leveger0903: PHP PSR-2規範是小寫開始的駝峰命名 08/19 12:58
46F：→ pttworld: Java派方法也是小寫開始駝峰，類別名大寫駝峰 08/19 15:03
47F：推 tennyleaz: 能不要縮寫就不要用 08/20 12:52
48F：→ ssccg: 縮寫只有那個專案原始開發者自以為約定俗成... 08/20 13:44
49F：推 sxy67230: 直接看guideline或是看公司規定，大學生學寫code的話， 08/20 13:58
50F：→ sxy67230: 直接看guideline。像google的python guideline 就有寫 08/20 13:58
51F：→ sxy67230: 很多原因不推薦的寫法。像很多新鮮人喜歡寫expect:這樣 08/20 13:58
52F：→ sxy67230: 所有的錯誤都會被忽略掉，所以不推薦這樣寫。新手不想養 08/20 13:58
53F：→ sxy67230: 出壞習慣就按照guideline 來避免寫出亂七八糟的code。 08/20 13:58
54F：推 sxy67230: 所謂的命名也是高手之間約定俗成的寫法，除非公司特別規 08/20 14:01
55F：→ sxy67230: 定，要不然就盡量照高手之間的寫法，未來管理也會方便一 08/20 14:01
56F：→ sxy67230: 點。 08/20 14:01
57F：推 sxy67230: 還有一點就是變數用縮寫盡量避免，原因是像py這種dict是 08/20 14:21
58F：→ sxy67230: 一種宣告型別，我看過一堆人把dict當變數使用。這樣雖然 08/20 14:21
59F：→ sxy67230: 可以跑，但是日後管理真的會很混亂，你可以取word_dicti 08/20 14:21
60F：→ sxy67230: onary，但不要用縮寫，看得人會很痛苦 08/20 14:21
※ 編輯: lion741205 (49.218.17.17 臺灣), 08/20/2019 15:27:33