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

[chucheng (時間太少事情太多)]

※ 引述《FukadaKyoko (小毛哥)》之銘言：
: 現在的專案中很多人會使用例如:
: int iID = 0;
: bool bVisible = false;
: struct Vector2
: {
:     int iX;
:     int iY;
: }
: 這種命名法,
常見有二種可能，一種是老人（從turbo C）時代寫下來，習慣改不掉
另一種是跟錯人學，或學錯範例（看錯書？）

: 個人看了真的覺得很痛苦.
: 我的看法是:
: 我們專案使用visual studio, 此情形下若要知道型態滑鼠上去就知道了,
: 並不需要依賴變數前面型別的縮寫.
這樣的論點你一提出來就可能被打槍
是的，大家都用Visual Studio，那又如何，有的人就是喜歡用NotePad++
或是用vim寫code，型別不會跳出來囉
像我喜歡用textmate寫code，純個人習慣
所以就算那是事實，仍是很weak的論點


: 但大家的反應是"有差嗎"或者"習慣了".
其實有的時候真的是這樣
我知道很醜，但我很習慣在加上s或甚至str_去命
尤其是寫python的時候，甚至有時會寫json_str_user
是長了一點，但是接手或debug時很方便

重點是，寫code命名是一種藝術，你有你的論點，別人有別的
有些東西有共識，有些東西沒有，像到底是
UserProfile好還是user_profile好
每個語言甚至傳統都不一樣

: 不過大家也不反對我把一些舊的/共用的class裡面的code重新命名去掉縮寫,
: 所以實際上同事可以接受也沒有閱讀困難,
: 而且也並不真的需要那個縮寫幫助寫作,
: 只是好像不加縮寫不行.
: 而且因為專案並無coding規範,
: 所以光是提出這種命名沒有意義的說詞是沒人鳥的...
我強列推薦這本書

http://www.amazon.com/Art-Readable-Code-Dustin-Boswell/dp/0596802293

我讀完之後才大徹大誤


講白一點，最簡單的原則

命名就是讓後人方便讀懂，關鍵在清楚
在不同的情境，不一定要死守特別的規定
書中舉了很多不同的情境，可能拿來說服別人

大原則是，code是用來給人讀的，怎樣別人好讀，就怎麼寫

命名是一種藝術，關鍵在於，怎樣最Readable

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 172.249.69.127
推 ringo543:大推這本!!!!!!!Code真的是讓人看懂最優先啊
→ ringo543:畢竟還有後續維護的問題
推 FukadaKyoko:謝謝分享! 看起來很棒的書!
→ FukadaKyoko:看懂優先沒錯 我就是覺得不加縮寫更好看懂才想推
推 CRPKT:問題是「你」覺得「你」更好懂, 別人未必啊 XD
→ hSATAC:有一句老祖宗的智慧 叫「入境隨俗」
→ kuope:可是我覺得一眼就看出變數的型態比一個一個點還要直覺方便啊
→ kuope:例如一頁有十個變數，我就不用特別去記每個變數的型態
推 FukadaKyoko:所以我才來請教大家為什麼有加縮寫比較好懂呀!!
→ FukadaKyoko:因為在專案內得不到解答 才來板上問
→ FukadaKyoko:to kuo, 你說的沒錯 但大多數情況下其實不需知道型態
→ FukadaKyoko:大多數情形下要了解的是變數的意義
→ TonyQ:我的經驗是大多數情況下需要知道型態，特別是大型系統架構。
→ TonyQ:我想這大概是專案上的差別，型態決定他的內容跟能調用什麼。
→ shvanta:我無法理解為什麼原po會覺得大多數情況不需要知道型態 ><
→ shvanta:我擔心我是不是觀念過時很久了 orz...
→ realmeat:再強大的ide環境, 我會偏向使用情境來命名
→ realmeat:弱編輯器環境就用匈牙利命名法, 不然你會很想死
推 BlazarArc:我覺得知道 primitive 變數的型態比較沒用，物件反之
推 BlazarArc:所以我是應用匈牙利(語意)+對於物件使用系統匈牙利
推 jack0204:兩個專案要兜在一起的時候，就知道變數+型態的重要
→ realmeat:ide真的太強了, 七八個專案放在一起感覺不到有問題
→ realmeat:不過用notepad++打開始又是另一種光景
推 BlazarArc:推一下原Po推薦的書，有系統整裡出要點，可以推給新人看
→ uranusjr:Python 是 duck typing 語言, 把型別寫在變數名裡會誤導
→ uranusjr:在 Python 中防錯應該是藉由 introspection, 不是 typing
推 CGary:你來版上問到「大家」的看法也是「這邊大家」的看法，專案內
→ CGary:的人還是覺得那樣比較好懂。程式碼就是以使用這些碼的人，覺
→ CGary:得易讀，我們又不用這些 code，覺得易用也沒啥意義...
→ RadiationXen:個人認為要看語言、專案類型，要看情境而定
→ RadiationXen:但把不同語言的撰寫風格攪混在一起，實在是災難
推 FukadaKyoko:可是專案內的人沒有覺得"比較好懂" 只是習慣而已啊