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

看板Soft_Job作者 (小毛哥)時間11年前 (2013/05/23 12:56), 編輯推噓16(16推 0噓 172→)
留言188則, 29人參與, 最新討論串1/19 (看更多)
現在的專案中很多人會使用例如: 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
→
05/23 13:01, , 1F
加縮寫也是coding規範吧?只要大家達成共識就好了~不過個人
05/23 13:01, 1F
→
05/23 13:04, , 2F
是支持加縮寫的~不需要移上去就很直覺的知道那是什麼~如果
05/23 13:04, 2F
→
05/23 13:04, , 3F
都用有提示的IDE寫~那這個規範當然可有可無~但若像我同事
05/23 13:04, 3F
→
05/23 13:05, , 4F
都用vim寫~那這個規範就很有用...
05/23 13:05, 4F
推
05/23 13:13, , 5F
你可以試看看訂一份命名原則甚至是coding style的文件
05/23 13:13, 5F
→
05/23 13:13, , 6F
給所有人參考 不過老闆沒要求的話 大概是堆不動...
05/23 13:13, 6F
→
05/23 13:13, , 7F
不是 我們"沒有"規範 所以這就是討厭的地方
05/23 13:13, 7F
→
05/23 13:13, , 8F
個人用個人的方法做 code很亂
05/23 13:13, 8F
→
05/23 13:13, , 9F
B大 沒錯 就是推不動...
05/23 13:13, 9F
→
05/23 13:14, , 10F
andy, 我們用vs所以有提示, 因此要在意的應為變數意義
05/23 13:14, 10F
→
05/23 13:14, , 11F
"實際上同事可以接受也沒有閱讀困難"
05/23 13:14, 11F
→
05/23 13:14, , 12F
我是建議你別找團隊麻煩
05/23 13:14, 12F
→
05/23 13:14, , 13F
可以用 vs 有提示跟一看到就知道型別還是有差
05/23 13:14, 13F
→
05/23 13:15, , 14F
幾乎所有 IDE 除動態語言外，都是有提示型別的。
05/23 13:15, 14F
→
05/23 13:15, , 15F
對開發團隊而言，要改變重視除非有迫切性的需求，不然只是
05/23 13:15, 15F
→
05/23 13:15, , 16F
看不爽看不順眼這種理由是最最最最最最最最最爛的理由
05/23 13:15, 16F
→
05/23 13:18, , 17F
板大 但我實際詢問下 也沒有人在依靠縮寫判斷型別
05/23 13:18, 17F
→
05/23 13:19, , 18F
這個算不算"重視"我不確定 因為大家只是看舊的code有
05/23 13:19, 18F
→
05/23 13:19, , 19F
就都跟著加上 如他們所說只是"習慣" 而非"必需"
05/23 13:19, 19F
→
05/23 13:19, , 20F
甚至有的人是來了專案之後才跟著加的
05/23 13:19, 20F
→
05/23 13:20, , 21F
至於我的理由是"這種命名沒有意義" 如文中所述
05/23 13:20, 21F
→
05/23 13:20, , 22F
"迫切性" :Q
05/23 13:20, 22F
→
05/23 13:21, , 23F
所以想問一下 板大也會加嗎?
05/23 13:21, 23F
→
05/23 13:21, , 24F
我會。
05/23 13:21, 24F
→
05/23 13:21, , 25F
不過如果團隊有規範是不加、我也不加。
05/23 13:21, 25F
→
05/23 13:21, , 26F
迫切性應該是針對時間點? 這個改變任何時候都可以做啊
05/23 13:21, 26F
→
05/23 13:21, , 27F
重點在遵守團隊既有規範，這種規範除非是 boss 去推，不然很
05/23 13:21, 27F
→
05/23 13:22, , 28F
難強硬去推。理由在於，如果團隊一個人看某件事不爽就要改
05/23 13:22, 28F
→
05/23 13:22, , 29F
那要改得可多的是...
05/23 13:22, 29F
→
05/23 13:22, , 30F
那所以加或不加的理由呢? 我想討論不只是規範的問題
05/23 13:22, 30F
→
05/23 13:22, , 31F
像這種 coding rule 一般來講是不會有迫切性的需求，也就是
05/23 13:22, 31F
板大說的沒錯, 遵循規範 但我們專案現在就是沒有規範 而我們主管又不強硬推行 所以我自己個人想嘗試一步一步進行 而在縮寫這邊有個卡關 我是看這件事不爽 但我也有提出我的看法以及引用網路文章/書本做為佐證 並非單純情緒性的要求 但同事只是因為"習慣", "反正就是這樣寫" 我覺得這樣不是要做一件事的理由 再說, 團隊中有人覺得任何事要改 我覺得很OK, 只要提出正確的理由 為什麼不能改? 就算有團隊規範, 規範也可能是不好/過時的 難道不該有人出來說要改嗎? 舉個極端的例子 如果團隊規範說每行的分號要用2個 難道我們不該出來指責這件事情的荒謬? 在以vs編輯C++的狀況下, 我自己是認為"不加"大於"要加" 板大自己會加, 我也很想聽看看為什麼"要加"大於"不加" 望請指教 ※ 編輯: FukadaKyoko 來自: 220.133.45.115 (05/23 13:29)
→
05/23 13:23, , 32F
說基本上是不會改。
05/23 13:23, 32F
→
05/23 13:23, , 33F
實際上的意義，就幾個點來看
05/23 13:23, 33F
→
05/23 13:23, , 34F
就意含命名而言，非常容易衝名。
05/23 13:23, 34F
→
05/23 13:24, , 35F
像是 labelName , txtName 之類的，一個是姓名標籤，一個是
05/23 13:24, 35F
→
05/23 13:24, , 36F
textbox 的標籤。
05/23 13:24, 36F
→
05/23 13:24, , 37F
另一個是視覺上就能分辨型別（這個的問題相對小一點，前面的
05/23 13:24, 37F
→
05/23 13:25, , 38F
比較顯著。），不過也有另一票是不用型別。
05/23 13:25, 38F
還有 110 則推文
→
05/23 20:39, , 149F
只要有先規定好,那麼就照著文件作.
05/23 20:39, 149F
→
05/23 20:40, , 150F
如果沒有規定,那麼就河水不犯井水,自己玩自己的.
05/23 20:40, 150F
→
05/23 20:40, , 151F
然後想辦法把專案拆成模組化,就可以在自己的領域胡搞了XD
05/23 20:40, 151F
→
05/23 21:04, , 152F
怎麼看都不像是說服不了別人 而像原po不能被別人說服
05/23 21:04, 152F
→
05/23 21:06, , 153F
有點像是去糾正別人的英文發音或是口音一樣
05/23 21:06, 153F
→
05/23 21:18, , 154F
http://goo.gl/X2Xqx 約有 825,000 項結果
05/23 21:18, 154F
→
05/23 21:53, , 155F
寫 Window 程式的人很多都已經習慣這種命名法了, 不跟
05/23 21:53, 155F
→
05/23 21:53, , 156F
著用還會被待久一些的拿資料型態來批，或是說你不合群
05/23 21:53, 156F
→
05/23 21:54, , 157F
其實可以自已負責的模組單一化，改別人的 code 就照他
05/23 21:54, 157F
→
05/23 21:55, , 158F
的 style ，避免被說三道四; 要不就換工作吧
05/23 21:55, 158F
→
05/23 22:01, , 159F
的確很多是很久以前老人寫出來的code
05/23 22:01, 159F
推
05/23 23:38, , 160F
很遺憾，這真的是「很無聊也很沒意義」的「自我感覺」問題
05/23 23:38, 160F
→
05/23 23:38, , 161F
我知道你覺得這看起來很醜，但問題不再醜，在「你覺得」
05/23 23:38, 161F
→
05/23 23:39, , 162F
我相信我在這邊絕對無法說服你這件事，你應該也同意
05/23 23:39, 162F
→
05/23 23:40, , 163F
同理，你也絕對無法說服你同事 xDDD 希望你能認知到這點
05/23 23:40, 163F
推
05/23 23:45, , 164F
大家跟著加上就是你們的 coding style..
05/23 23:45, 164F
推
05/24 01:37, , 165F
coding style follow就好 想太多沒意義
05/24 01:37, 165F
→
05/24 01:37, , 166F
除非你自己寫給自己maintain一輩子
05/24 01:37, 166F
推
05/24 03:36, , 167F
coding style，找他來談，雖然你不一定贏，但統一很重要
05/24 03:36, 167F
→
05/24 07:56, , 168F
這種命名法叫匈牙利命名法，是用匈牙利程設師提出來的
05/24 07:56, 168F
→
05/24 07:57, , 169F
ms好像很喜歡這種命名法，但現在還有沒有用不清楚
05/24 07:57, 169F
推
05/24 08:27, , 170F
總之,你不夠力.這種事情要夠力的人主導,還要跟大家協調出一
05/24 08:27, 170F
→
05/24 08:28, , 171F
個共同規範,落實審查制度(code review)才行.沒那麼容易的
05/24 08:28, 171F
推
05/24 20:45, , 172F
Windows API style. It's fine
05/24 20:45, 172F
推
05/25 00:19, , 173F
匈牙利命名法臭了嗎?
05/25 00:19, 173F
推
05/25 01:18, , 174F
Linus: Hungarian notation is brain damaged.
05/25 01:18, 174F
推
05/25 09:45, , 175F
Linus放的砲可多了，他討厭ACPI、討厭UEFI、討厭C++....
05/25 09:45, 175F
→
05/25 09:46, , 176F
結果這年頭連GCC都倒戈stage 3改用C++寫 (lol)
05/25 09:46, 176F
→
05/25 09:47, , 177F
我倒是很好奇，是誰brain damaged了(grin)
05/25 09:47, 177F
推
05/25 12:15, , 178F
跟我同事一樣，變數加i,s,b,甚至類別加上cls,
05/25 12:15, 178F
→
05/25 12:15, , 179F
看起來就超礙眼的。
05/25 12:15, 179F
→
05/25 12:23, , 180F
新進同事也照著此規則在命名，雖然公司沒強制規定命名的規
05/25 12:23, 180F
→
05/25 12:24, , 181F
則，不過要求新進同事不要加上prefix,現在維護他的程式
05/25 12:24, 181F
→
05/25 12:24, , 182F
就很順眼。
05/25 12:24, 182F
推
05/26 08:57, , 183F
不同語言的習慣不一樣, 如果你是寫 .NET 的程式
05/26 08:57, 183F
→
05/26 08:57, , 184F
那就照這個 http://ppt.cc/p~js
05/26 08:57, 184F
→
05/26 08:57, , 185F
微軟直接就建議 DO NOT use Hungarian notation
05/26 08:57, 185F
推
05/27 19:10, , 186F
花一小時把名稱改掉 然後定一份naming rule給主管看
05/27 19:10, 186F
→
05/27 19:10, , 187F
反正之前沒人訂 所以你最大
05/27 19:10, 187F
推
05/30 10:16, , 188F
naming convention是專案開始前就要溝通的
05/30 10:16, 188F
‣ 更多 FukadaKyoko 的文章
文章代碼(AID): #1HdQ6RbR (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 19 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共19篇)
‣ 更多 FukadaKyoko 的文章
文章代碼(AID): #1HdQ6RbR (Soft_Job)