※ 引述《meokay (我可以)》之銘言：
: 如題
: 現在常常會Review別人的程式碼
: 發現大家的命名習慣都好不同
: 舉例來說
: 一個Func是Check Status
: 有的人會寫 void check_status()
: 也有的人寫 void checkStatus()
: 也有看過寫 void CStatus()
: 姑且不論第三種
: 那大致上就是分成底線派跟非底線派
: 大家的命名是哪種風格啊？
: 有沒有大大願意分享一下～
: 或是有什麼堅持xDD
: 我先投非底線派一票QQ
命名規則是為了增加識別和可讀性，沒有強制的規定，但一旦選擇其中一種，會建議編寫
時統一格式；而化學、天文、生物也有其慣用的命名方法；大部分的程式語言也有對此進
行建議，以統一風格。
在程式設計的命名上，當變數、函式及類別等名稱由兩個以上的單字組合，就可以使用現
有的命名方法，增加識別和可讀性。目前已經出現的命名方法，可以分為Underscore(底
線式)、Camel-case(駝峰式)及Hungarian notation(匈牙利命名法)三大類。此文進行彙
整，並以個人經驗，探討其優缺點。

匈牙利命名對現代IDE有多餘嗎？ 當有一堆membervariable或可選的變數時，我反而會直接從型別類型找szXXX這種C-String命名法 取stringZero我反而會誤會

我現在也不用匈牙利命名法了

不熟sz的慣用命名 應該只是寫得不夠多 看得不夠多有些idiom是廣為流傳 命名就看語言使用者/團隊習慣像pimpl 如果你不懂C++的idiom 當然看不懂

你列的這些約定成俗我都沒用過......is做input stream...?? 我是都當boolean變數啦 像isValid

if/is/of/os我都看過 這真的看習慣 如果scope不大我是直接取stream 反正你function不超過20行不會有困擾 因為型別已經告訴你

型別我會放後面 像amt/amtStr 這樣傳json就放在一起了

匈牙利我覺得用在built-in type就好 OOP太多抽象的東西強迫自己想個有鑑別性的縮寫只是徒增困擾

amount->amt, member->mbr...之類的約定成俗反而更常見

member我看到比較多都寫m耶 C++啦 WunoW是寫哪個語言？

只寫m我也看過 但我都會盡量要求縮寫也要明確C和C++派大概是我見過變數名稱最懶的...不然其實ide有按tab自動完成功能 變數長一點不會麻煩但命名明確一點我覺得還是對開發和維護都有好處不然專案多人開發 你的m不是我的m 不太好

XDDDD

三種我都有用過，大家有共識統一用什麼就用什麼，member variable近年多加底線來區分

amt mbr 是啥鬼有人的約定俗成不太一樣

維護老屁股系統 各種命名都會遇到 還能在這挑是幸福啊

今年初專案的會議結果光是命名規則就討論快3小時XDD最後共識還是駝峰式為主

命名規則竟然能討論到三個小時 還 滿 屌 ㄉ

svc 我覺得當service的變數不錯啊

能不縮寫就不縮寫

我也覺得不縮寫的好 以方便看為主if input file這還真少見開頭大寫的駝峰式也愈來愈常見 因為很多protocol文件都是開頭大寫駝峰式 變數命名也直接照搬ZoneNameString 這種放後面的也愈來愈常見

匈牙利命名稍微有碰過win32 api應該都知道在幹嘛，但可能不知道那個叫匈牙利命名

有人說匈牙利命名很難閱讀，是真的嗎？

https://www.slideshare.net/mobile/kylinfish/clean-code-72688451

PHP PSR-2規範是小寫開始的駝峰命名

Java派方法也是小寫開始駝峰，類別名大寫駝峰

能不要縮寫就不要用

縮寫只有那個專案原始開發者自以為約定俗成...

直接看guideline或是看公司規定，大學生學寫code的話，直接看guideline。像google的python guideline 就有寫很多原因不推薦的寫法。像很多新鮮人喜歡寫expect:這樣所有的錯誤都會被忽略掉，所以不推薦這樣寫。新手不想養出壞習慣就按照guideline 來避免寫出亂七八糟的code。所謂的命名也是高手之間約定俗成的寫法，除非公司特別規定，要不然就盡量照高手之間的寫法，未來管理也會方便一點。