Re: [討論] 大家的命名習慣 - 現有命名方法彙整及比較

看板Soft_Job作者 (獅子)時間4年前 (2019/08/18 17:31), 4年前編輯推噓11(11推 0噓 49→)
留言60則, 18人參與, 4年前最新討論串1/1
※ 引述《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://www.ptt.cc/bbs/Soft_Job/M.1566120705.A.C1F.html ※ 編輯: lion741205 (101.13.41.25 臺灣), 08/18/2019 17:52:55
→
08/18 18:05, 4年前 , 1F
匈牙利命名對現代IDE有多餘嗎？ 當有一堆member
08/18 18:05, 1F
→
08/18 18:05, 4年前 , 2F
variable或可選的變數時，我反而會直接從型別類型找
08/18 18:05, 2F
→
08/18 18:06, 4年前 , 3F
szXXX這種C-String命名法 取stringZero我反而會誤會
08/18 18:06, 3F
推
08/18 18:07, 4年前 , 4F
我現在也不用匈牙利命名法了
08/18 18:07, 4F
→
08/18 18:07, 4年前 , 5F
不熟sz的慣用命名 應該只是寫得不夠多 看得不夠多
08/18 18:07, 5F
→
08/18 18:09, 4年前 , 6F
有些idiom是廣為流傳 命名就看語言使用者/團隊習慣
08/18 18:09, 6F
→
08/18 18:10, 4年前 , 7F
像pimpl 如果你不懂C++的idiom 當然看不懂
08/18 18:10, 7F
嗯，有些約定俗成的縮寫，有時候會造成新手混淆，但對老手來說很方便 ※ 編輯: lion741205 (101.13.41.25 臺灣), 08/18/2019 18:16:13
→
08/18 18:15, 4年前 , 8F
你列的這些約定成俗我都沒用過......
08/18 18:15, 8F
→
08/18 18:16, 4年前 , 9F
is做input stream...?? 我是都當boolean變數啦 像isValid
08/18 18:16, 9F
只是為了講匈牙利命名找的範例，裡面的縮寫我也不全用的 XD
→
08/18 18:18, 4年前 , 10F
if/is/of/os我都看過 這真的看習慣 如果scope不大
08/18 18:18, 10F
→
08/18 18:19, 4年前 , 11F
我是直接取stream 反正你function不超過20行不會有
08/18 18:19, 11F
→
08/18 18:19, 4年前 , 12F
困擾 因為型別已經告訴你
08/18 18:19, 12F
※ 編輯: lion741205 (101.13.41.25 臺灣), 08/18/2019 18:20:50
→
08/18 18:20, 4年前 , 13F
型別我會放後面 像amt/amtStr 這樣傳json就放在一起了
08/18 18:20, 13F
→
08/18 18:21, 4年前 , 14F
匈牙利我覺得用在built-in type就好 OOP太多抽象的
08/18 18:21, 14F
→
08/18 18:21, 4年前 , 15F
東西強迫自己想個有鑑別性的縮寫只是徒增困擾
08/18 18:21, 15F
→
08/18 18:21, 4年前 , 16F
amount->amt, member->mbr...之類的約定成俗反而更常見
08/18 18:21, 16F
→
08/18 18:22, 4年前 , 17F
member我看到比較多都寫m耶 C++啦 WunoW是寫哪個語
08/18 18:22, 17F
→
08/18 18:22, 4年前 , 18F
言？
08/18 18:22, 18F
→
08/18 18:30, 4年前 , 19F
只寫m我也看過 但我都會盡量要求縮寫也要明確
08/18 18:30, 19F
→
08/18 18:30, 4年前 , 20F
C和C++派大概是我見過變數名稱最懶的...
08/18 18:30, 20F
→
08/18 18:32, 4年前 , 21F
不然其實ide有按tab自動完成功能 變數長一點不會麻煩
08/18 18:32, 21F
→
08/18 18:34, 4年前 , 22F
但命名明確一點我覺得還是對開發和維護都有好處
08/18 18:34, 22F
→
08/18 18:35, 4年前 , 23F
不然專案多人開發 你的m不是我的m 不太好
08/18 18:35, 23F
→
08/18 18:37, 4年前 , 24F
XDDDD
08/18 18:37, 24F
推
08/18 19:14, 4年前 , 25F
三種我都有用過，大家有共識統一用什麼就用什麼，memb
08/18 19:14, 25F
→
08/18 19:14, 4年前 , 26F
er variable近年多加底線來區分
08/18 19:14, 26F
→
08/18 19:42, 4年前 , 27F
amt mbr 是啥鬼
08/18 19:42, 27F
→
08/18 19:42, 4年前 , 28F
有人的約定俗成不太一樣
08/18 19:42, 28F
→
08/18 20:25, 4年前 , 29F
維護老屁股系統 各種命名都會遇到 還能在這挑是幸福啊
08/18 20:25, 29F
推
08/18 20:55, 4年前 , 30F
今年初專案的會議結果光是命名規則就討論快3小時XDD
08/18 20:55, 30F
→
08/18 20:55, 4年前 , 31F
最後共識還是駝峰式為主
08/18 20:55, 31F
→
08/18 21:37, 4年前 , 32F
命名規則竟然能討論到三個小時 還 滿 屌 ㄉ
08/18 21:37, 32F
→
08/18 21:50, 4年前 , 33F
svc 我覺得當service的變數不錯啊
08/18 21:50, 33F
推
08/19 03:42, 4年前 , 34F
能不縮寫就不縮寫
08/19 03:42, 34F
→
08/19 09:29, 4年前 , 35F
我也覺得不縮寫的好 以方便看為主
08/19 09:29, 35F
→
08/19 09:31, 4年前 , 36F
if input file這還真少見
08/19 09:31, 36F
→
08/19 09:32, 4年前 , 37F
開頭大寫的駝峰式也愈來愈常見 因為很多protocol文件
08/19 09:32, 37F
→
08/19 09:33, 4年前 , 38F
都是開頭大寫駝峰式 變數命名也直接照搬
08/19 09:33, 38F
→
08/19 09:34, 4年前 , 39F
ZoneNameString 這種放後面的也愈來愈常見
08/19 09:34, 39F
推
08/19 09:49, 4年前 , 40F
匈牙利命名稍微有碰過win32 api應該都知道在幹嘛，但
08/19 09:49, 40F
→
08/19 09:49, 4年前 , 41F
可能不知道那個叫匈牙利命名
08/19 09:49, 41F
→
08/19 09:52, 4年前 , 42F
有人說匈牙利命名很難閱讀，是真的嗎？
08/19 09:52, 42F
我覺得編碼約定做得好，能夠統一寫法，反而有利團隊閱讀、搜尋和命名， 只是對專案新人或以後接手的人比較不友善，還要另外去了解那些縮寫的含意； 比起寫清楚講明白，更容易造成歧義，所以有些書提倡不要使用匈牙利命名法。
推
08/19 10:25, 4年前 , 43F
08/19 10:25, 43F
→
08/19 10:25, 4年前 , 44F
de-72688451
08/19 10:25, 44F
推
08/19 12:58, 4年前 , 45F
PHP PSR-2規範是小寫開始的駝峰命名
08/19 12:58, 45F
→
08/19 15:03, 4年前 , 46F
Java派方法也是小寫開始駝峰，類別名大寫駝峰
08/19 15:03, 46F
推
08/20 12:52, 4年前 , 47F
能不要縮寫就不要用
08/20 12:52, 47F
→
08/20 13:44, 4年前 , 48F
縮寫只有那個專案原始開發者自以為約定俗成...
08/20 13:44, 48F
推
08/20 13:58, 4年前 , 49F
直接看guideline或是看公司規定，大學生學寫code的話，
08/20 13:58, 49F
→
08/20 13:58, 4年前 , 50F
直接看guideline。像google的python guideline 就有寫
08/20 13:58, 50F
→
08/20 13:58, 4年前 , 51F
很多原因不推薦的寫法。像很多新鮮人喜歡寫expect:這樣
08/20 13:58, 51F
→
08/20 13:58, 4年前 , 52F
所有的錯誤都會被忽略掉，所以不推薦這樣寫。新手不想養
08/20 13:58, 52F
→
08/20 13:58, 4年前 , 53F
出壞習慣就按照guideline 來避免寫出亂七八糟的code。
08/20 13:58, 53F
推
08/20 14:01, 4年前 , 54F
所謂的命名也是高手之間約定俗成的寫法，除非公司特別規
08/20 14:01, 54F
→
08/20 14:01, 4年前 , 55F
定，要不然就盡量照高手之間的寫法，未來管理也會方便一
08/20 14:01, 55F
→
08/20 14:01, 4年前 , 56F
點。
08/20 14:01, 56F
推
08/20 14:21, 4年前 , 57F
還有一點就是變數用縮寫盡量避免，原因是像py這種dict是
08/20 14:21, 57F
→
08/20 14:21, 4年前 , 58F
一種宣告型別，我看過一堆人把dict當變數使用。這樣雖然
08/20 14:21, 58F
→
08/20 14:21, 4年前 , 59F
可以跑，但是日後管理真的會很混亂，你可以取word_dicti
08/20 14:21, 59F
→
08/20 14:21, 4年前 , 60F
onary，但不要用縮寫，看得人會很痛苦
08/20 14:21, 60F
※ 編輯: lion741205 (49.218.17.17 臺灣), 08/20/2019 15:27:33
‣ 更多 lion741205 的文章
文章代碼(AID): #1TMHi1mV (Soft_Job)