[請益] 要如何說服同事停止命名類似iID的變數

[FukadaKyoko (小毛哥)]

現在的專案中很多人會使用例如:
int iID = 0;
bool bVisible = false;
struct Vector2
{
    int iX;
    int iY;
}
這種命名法,
個人看了真的覺得很痛苦.


我的看法是:
我們專案使用visual studio, 此情形下若要知道型態滑鼠上去就知道了,
並不需要依賴變數前面型別的縮寫.
而且很多討論命名的文章也支持直接針對變數意義命名,
型別的縮寫並不能帶來更好的理解, 也不對於變數本身帶來任何意義.
如: http://chinesetrad.joelonsoftware.com/Articles/Wrong.html
或者搜尋Clean Code.


我在專案中提過希望不要再加縮寫,
但大家的反應是"有差嗎"或者"習慣了".
不過大家也不反對我把一些舊的/共用的class裡面的code重新命名去掉縮寫,
所以實際上同事可以接受也沒有閱讀困難,
而且也並不真的需要那個縮寫幫助寫作,
只是好像不加縮寫不行.
而且因為專案並無coding規範,
所以光是提出這種命名沒有意義的說詞是沒人鳥的...


想請問板友的專案狀況是如何呢?
有沒有人也支持不加縮寫並且有一套更強而有力的說詞可以提供?
謝謝!

P.S. 如果有同事認出小弟的話也歡迎直接推/回文討論.

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.133.45.115
→ andymai:加縮寫也是coding規範吧?只要大家達成共識就好了~不過個人
→ andymai:是支持加縮寫的~不需要移上去就很直覺的知道那是什麼~如果
→ andymai:都用有提示的IDE寫~那這個規範當然可有可無~但若像我同事
→ andymai:都用vim寫~那這個規範就很有用...
推 Baternest:你可以試看看訂一份命名原則甚至是coding style的文件
→ Baternest:給所有人參考 不過老闆沒要求的話 大概是堆不動...
→ FukadaKyoko:不是 我們"沒有"規範 所以這就是討厭的地方
→ FukadaKyoko:個人用個人的方法做 code很亂
→ FukadaKyoko:B大 沒錯 就是推不動...
→ FukadaKyoko:andy, 我們用vs所以有提示, 因此要在意的應為變數意義
→ TonyQ:"實際上同事可以接受也沒有閱讀困難"
→ TonyQ:我是建議你別找團隊麻煩
→ TonyQ:可以用 vs 有提示跟一看到就知道型別還是有差
→ TonyQ:幾乎所有 IDE 除動態語言外，都是有提示型別的。
→ TonyQ:對開發團隊而言，要改變重視除非有迫切性的需求，不然只是
→ TonyQ:看不爽看不順眼這種理由是最最最最最最最最最爛的理由
→ FukadaKyoko:板大 但我實際詢問下 也沒有人在依靠縮寫判斷型別
→ FukadaKyoko:這個算不算"重視"我不確定 因為大家只是看舊的code有
→ FukadaKyoko:就都跟著加上 如他們所說只是"習慣" 而非"必需"
→ FukadaKyoko:甚至有的人是來了專案之後才跟著加的
→ FukadaKyoko:至於我的理由是"這種命名沒有意義" 如文中所述
→ TonyQ:"迫切性" :Q
→ FukadaKyoko:所以想問一下 板大也會加嗎?
→ TonyQ:我會。
→ TonyQ:不過如果團隊有規範是不加、我也不加。
→ FukadaKyoko:迫切性應該是針對時間點? 這個改變任何時候都可以做啊
→ TonyQ:重點在遵守團隊既有規範，這種規範除非是 boss 去推，不然很
→ TonyQ:難強硬去推。理由在於，如果團隊一個人看某件事不爽就要改
→ TonyQ:那要改得可多的是...
→ FukadaKyoko:那所以加或不加的理由呢? 我想討論不只是規範的問題
→ TonyQ:像這種 coding rule 一般來講是不會有迫切性的需求，也就是
板大說的沒錯, 遵循規範
但我們專案現在就是沒有規範
而我們主管又不強硬推行
所以我自己個人想嘗試一步一步進行
而在縮寫這邊有個卡關

我是看這件事不爽
但我也有提出我的看法以及引用網路文章/書本做為佐證
並非單純情緒性的要求
但同事只是因為"習慣", "反正就是這樣寫"
我覺得這樣不是要做一件事的理由

再說, 團隊中有人覺得任何事要改
我覺得很OK, 只要提出正確的理由
為什麼不能改?
就算有團隊規範, 規範也可能是不好/過時的
難道不該有人出來說要改嗎?
舉個極端的例子
如果團隊規範說每行的分號要用2個
難道我們不該出來指責這件事情的荒謬?

在以vs編輯C++的狀況下, 我自己是認為"不加"大於"要加"
板大自己會加, 我也很想聽看看為什麼"要加"大於"不加"
望請指教
※ 編輯: FukadaKyoko     來自: 220.133.45.115       (05/23 13:29)
→ TonyQ:說基本上是不會改。
→ TonyQ:實際上的意義，就幾個點來看
→ TonyQ:就意含命名而言，非常容易衝名。
→ TonyQ:像是 labelName , txtName 之類的，一個是姓名標籤，一個是
→ TonyQ:textbox 的標籤。
→ TonyQ:另一個是視覺上就能分辨型別（這個的問題相對小一點，前面的
→ TonyQ:比較顯著。），不過也有另一票是不用型別。
→ realmeat:到了管理整個project的位置時, 你就可以要求了
→ TonyQ:當然如果你說的是改用意義性的 prefix , ex. 之前有人在說得
→ TonyQ:所謂"正確的"(也只是自己說爽的)駱駝式命名法的意含
→ TonyQ:對 unsafe/unescape safe/escaped data 加上一些意義性的
→ TonyQ:prefix 的作法，那倒也不無不可。但是說到底，這些全都是團
→ TonyQ:隊規範，團隊規範在團隊沒有共識的情況下是一點意義也沒有的
→ TonyQ:我打個比方吧，這就像是用 SVN 的團隊要轉換成 GIT 的團隊
→ TonyQ:「難道不應該有人出來說要改嗎？」
→ TonyQ:你已經說了，而且其他人也已經回應他們的看法了，
→ TonyQ:不是不應該說，是不應該強硬去推。:P
→ TonyQ:然後你說得書本跟網路上的資料，對我來講跟情緒沒啥兩樣，
→ TonyQ:因為命名法這種問題並沒有任何資料可以證明他是最好的。
→ TonyQ:習慣的確不是個好的做事態度，但沒事找事作也不是。XD
→ andymai:連主管都說服不了~怎麼推?而且你有意識到你在做你們主管的
→ TonyQ:btw 你的例子讓我想到有些語言跟團隊認為打分號是一種荒謬。
→ andymai:事嗎?其它人也表態了~有當過兵的應該都知道怎麼做...
→ FukadaKyoko:因為主管不做 我只好靠自己的力量走多少算多少囉
→ realmeat:我總覺得規則一套就好了, 除非有太多規則, 不然沒必要
→ TonyQ:我覺得你同事可能只是懶得跟你討論，有些人會這樣。
→ ken1325:這種事等你當上他們的主管再來講
→ realmeat:至於啥種方式命名沒多大意義, 統一才是重點
→ FukadaKyoko:沒錯 就是希望統一 但現在就無法
→ realmeat:那這種維護可能會造成問題的專案管理未來不會出問題嗎?
→ realmeat:沒想過在出問題前另謀高就, 去重視這些問題的公司就好
→ TonyQ:我比較好奇的是如果團隊規定就是要用這種匈牙利式命名法，
→ TonyQ: FukadaKyoko 會繼續抗爭還是遵守規定。XD
→ FukadaKyoko:我會先弄清楚為什麼要加啊 因為我怎想都不覺得加較好
→ TonyQ:在吵命名法這種大事之前，還有很多功能開發這種小事得處理，
→ TonyQ:主要只有作 framework 的 team 會對這件事情比較要求。
推 TonyQ:在其他專案的狀況下，其實就算不統一也不會有太大問題。
→ TonyQ:(啊，動態語言除外，因為沒有 content assit)
→ TonyQ:@FukadaKyoko 所以說到底就是沒人說服你這樣比較好你就不想
→ TonyQ:用咩，這樣講比較實際。
→ FukadaKyoko:功能開發還是會照做啦 只是每次看code還是會想到規範
→ realmeat:匈牙利命名法有他的歷史背景, 以前IDE沒那麼強
→ TonyQ:我是覺得 name conflick 是自由發揮(啊? 你說意含命名?)最大
→ TonyQ:的問題。
→ FukadaKyoko:可以這麼說 本來就是要說服別人呀 我也正想這麼做
→ realmeat:不靠匈牙利命名法其實還真的不好做事
→ TonyQ:*name conflict
→ TonyQ:用匈牙利命名法至少可以解決一些笨蛋造成的衝名的問題
→ realmeat:不過還是老話一句沒啥好不好, 統一才是最重要
→ FukadaKyoko:先來上班 謝謝各位前輩的指點
→ astt88:如果團隊有規範就依團隊規範
→ astt88:大家有統一就好了
→ shortoneal:這種都大家講好就好，你自己有問題就只能吞下去=_=
→ shortoneal:你怎麼知道下一個style其他人會更容易看
→ shvanta:我是老人，匈牙利命名法到現在都還在用~
→ astt88:style就是要讓大家都容易看而且認同，沒有什麼對錯
→ shvanta:沒有型別提示我真的會超不習慣的
→ astt88:若看不順眼，以後這專案只有你維護時，可以改成你的style
→ astt88:當你要讓別人維護這個專案時再改成團隊的style就行了
→ shvanta:開發或review時,用滑鼠去"指"來確認型別我覺得又慢又麻煩
→ astt88:不過這樣不覺得累嗎？時間應該要花在其他更有價值的地方
→ shvanta:而且有時後會直接使用文字編輯器開source code
→ FukadaKyoko:當要知道型別又用文字編輯器確實會有這問題
→ FukadaKyoko:但我們專案內 目前沒這需求 而且
→ FukadaKyoko:我自己再看code時 很少需要去知道型別
→ shvanta:就我的立場,沒反過來說服原po改用匈牙利命名法就不錯了 :Q
→ FukadaKyoko:因為通常都是在看code的邏輯 只要知道變數代表的意義
→ FukadaKyoko:可以說服呀...我也很想被說服XD 我就是想知道兩方想法
→ shvanta:嗯，你不需要不太表其他人不需要囉，像我是很依賴~
→ shvanta:優缺點其實wiki就有囉 : http://ppt.cc/NrjJ
→ shvanta:話說我以前寫MFC,那時候一般都是鼓勵用匈牙利命名法
→ shvanta:時代真的不一樣了~
→ astt88:有時在客戶端沒有IDE可以開，只有記事本可以用時就知道了
→ astt88:去客戶那邊處理問題時，不見得可以帶電腦設備去
→ kuope:你不覺得型態+名稱可以了解這個變數更深的意義嗎？
→ kuope:比如說int開頭，我就知道他可以用來做數學運算
→ astt88:所以臨時要看code時只有記事本了
→ kuope:bln開頭的，我就知道後面要接 = t or f。而不是文字
→ kuope:把bln跟str開頭的用文字串在一起肯定有問題！
→ astt88:不過在正常情況下，正式環境應該只會放已包裝好的檔案
→ FukadaKyoko:astt88謝謝 我理解這個case
→ FukadaKyoko:kuope: 我覺得意義只要看他怎麼被用就可以知道了
→ FukadaKyoko:比如CashAmount = 100那他自然是int
→ FukadaKyoko:當然也可能是unsinged int 不過這應該算一個問題
→ FukadaKyoko:google c++ guide裡面有提到統一signed/unsigned
→ FukadaKyoko:而且我的意思是 CashAmount的意義在於Amount
→ FukadaKyoko:用Amount就可以代表iCashAmount的prefix i了
→ astt88:另外還有個好處，當在寫沒有明確宣告型態的語寫時
→ astt88:                                          言
→ astt88:像JavaScript在宣告時用var
→ astt88:匈牙利命名法可以提供一點關於它儲存內容的資訊
→ astt88:當然了，匈牙利命名法沒有強制性
→ astt88:若程式寫成var iID; iID="N201305230000000001";
→ SecretWhale:小弟的一點淺見，這個命名方式本身還是有自己的涵意，
→ astt88:反而會造成錯誤的認知
→ astt88:所以習慣匈牙利命名法後
→ SecretWhale:也不是說用在VS上會造成什麼讓人誤解什麼東西的情況，
→ astt88:我反而希望IDE能有可以檢查上述問題的功能
→ SecretWhale:只是，VS上提供了某些替代的方式，如此而己。
→ SecretWhale:但以小弟自己的經驗，這種加上型態的命名方式，適用的
→ SecretWhale:範圍其實很廣，因為除了i這個型態之外，還有其他的型
→ SecretWhale:如果要修正掉這種命名方式，是不是也考慮過其他的情況
→ SecretWhale:如同Tonq大大所言的。
→ SecretWhale:既然命名方式只是一種習慣，又沒犯什麼錯誤，不如先專
→ SecretWhale:注在Code Style的其他部份上面，這種枝微末節，小弟是
→ SecretWhale:建議過一陣子再拿出來討論。
→ SecretWhale:以下所言有點失禮，但我覺的原po有點在興頭上，等稍微
→ SecretWhale:冷靜一點再思考會比較能接受吧。
→ alan3100:其實這是2件事 一種是命名法的討論 另一個是你個人看不慣
→ alan3100:前者由討論可以看到並沒辦法有效說服所有人 且不阻礙專案
推 NDark:coding style是政治問題,而不是技術問題.
→ NDark:文(政治)無第一 武(技術)無第二
→ NDark:確實匈牙利已經被批的很清楚了,但這是武的部份.
→ NDark:但要大家同心協力,那就是文的部份,就必須用政治的方法解決.
→ NDark:一個是爬到更高的地位用政治地位壓過對方.
→ NDark:coding style的不同對我來講都是很難適應的.
→ NDark:所以要是碰到這種問題,我都會問,那麼標準文件在哪裡?
→ NDark:只要有先規定好,那麼就照著文件作.
→ NDark:如果沒有規定,那麼就河水不犯井水,自己玩自己的.
→ NDark:然後想辦法把專案拆成模組化,就可以在自己的領域胡搞了XD
→ nobody1:怎麼看都不像是說服不了別人  而像原po不能被別人說服
→ nobody1:有點像是去糾正別人的英文發音或是口音一樣
→ uranusjr:http://goo.gl/X2Xqx  約有 825,000 項結果
→ lulala453:寫 Window 程式的人很多都已經習慣這種命名法了, 不跟
→ lulala453:著用還會被待久一些的拿資料型態來批，或是說你不合群
→ lulala453:其實可以自已負責的模組單一化，改別人的 code 就照他
→ lulala453:的 style ，避免被說三道四; 要不就換工作吧
→ FukadaKyoko:的確很多是很久以前老人寫出來的code
推 yoco315:很遺憾，這真的是「很無聊也很沒意義」的「自我感覺」問題
→ yoco315:我知道你覺得這看起來很醜，但問題不再醜，在「你覺得」
→ yoco315:我相信我在這邊絕對無法說服你這件事，你應該也同意
→ yoco315:同理，你也絕對無法說服你同事 xDDD 希望你能認知到這點
推 clanguage:大家跟著加上就是你們的 coding style..
推 cashlalala:coding style follow就好 想太多沒意義
→ cashlalala:除非你自己寫給自己maintain一輩子
推 noonOut:coding style，找他來談，雖然你不一定贏，但統一很重要
→ eva19452002:這種命名法叫匈牙利命名法，是用匈牙利程設師提出來的
→ eva19452002:ms好像很喜歡這種命名法，但現在還有沒有用不清楚
推 bobju:總之,你不夠力.這種事情要夠力的人主導,還要跟大家協調出一
→ bobju:個共同規範,落實審查制度(code review)才行.沒那麼容易的
推 plover:Windows API style.  It's fine
推 snaketsai:匈牙利命名法臭了嗎?
推 askacis:Linus: Hungarian notation is brain damaged.
推 snaketsai:Linus放的砲可多了，他討厭ACPI、討厭UEFI、討厭C++....
→ snaketsai:結果這年頭連GCC都倒戈stage 3改用C++寫 (lol)
→ snaketsai:我倒是很好奇，是誰brain damaged了(grin)
推 reichs:跟我同事一樣，變數加i,s,b,甚至類別加上cls,
→ reichs:看起來就超礙眼的。
→ reichs:新進同事也照著此規則在命名，雖然公司沒強制規定命名的規
→ reichs:則，不過要求新進同事不要加上prefix,現在維護他的程式
→ reichs:就很順眼。
推 deuter:不同語言的習慣不一樣, 如果你是寫 .NET 的程式
→ deuter:那就照這個 http://ppt.cc/p~js
→ deuter:微軟直接就建議 DO NOT use Hungarian notation
推 amozartea:花一小時把名稱改掉  然後定一份naming rule給主管看
→ amozartea:反正之前沒人訂  所以你最大
推 Mewra:naming convention是專案開始前就要溝通的