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

看板Soft_Job作者 (Inkling)時間12年前 (2013/05/25 19:26), 編輯推噓9(9推 0噓 31→)
留言40則, 15人參與, 最新討論串16/19 (看更多)
※ 引述《FukadaKyoko (小毛哥)》之銘言： 部份恕刪。 : 我想我真正要問的應該是 : "制訂coding style時, 加入型別縮寫prefix的優缺點是? 有無何者較佳?" 如果你想要直接的答案，簡單一句話：沒有。 說真的，你勤快一點的話，google "hungarian notation" 它會給你 1,010,000 項結果，這是我剛查的。 第一頁裡就有 (一行, 不縮了)： http://msdn.microsoft.com/en-us/library/aa260976%28v=vs.60%29.aspx 微軟記錄的 Hungarian notation 的發明人，Charles Simonyi，的原始論文。 有關 hungarian notation 的優點，我們讓原始創作人說話。 有關 hungarian notation 的缺點，呃，緊接著的討論自己看吧。 重點就在這兒，hungarian notation 的優缺已經在程式設計師間爭論 少說也二十年而沒有定論了，你為何認為有可能在 ptt 或其它地方找 到夠說服力的論點來支持任何一方？ 這是之前很多人一直在和你說的一點，不要為這個爭執。要嘛接受，要嘛 　當主管訂規矩。這是政治問題，不是技術問題。 之前 yoco 也問過你 { 放的位置的問題，你大概不知道他為何問你這個而 簡單的回你覺得沒差。 { 放在句尾或獨立一行，你可能覺得沒差；但，這一樣是一個吵翻天的項 　目。google "curly brace position" 有 3,030,000 項目。有興趣自己去 讀。 這才是 yoco 問你那個問題的意思，你在乎 prefix，有人還在乎 { 放那兒 呢。你真的要一路糾結在這些你目前無力改變或控制的事情上嗎？ 以下部份恕刪。 : 我發此問題只是想收集一些能加強我的論點的意見 : 因為我相信板上一定也有覺得不加prefix比較好的人 : 當然我是偷懶了, 因為我還沒有把所有相關書跟文章都看完 : 發文的時候也太急沒有提供完整的論點 我提供一個我個人覺得還不錯的論點給你好了。 匈牙利命名法 '破壞' 資訊隱藏。 物件導向很重要的一點是資訊隱藏，你只需要知道物件會作什麼，不 需要知道它怎麼作的。這樣我們在更換實作方式時，才不會有困擾。 匈牙利命名法破壞了這一點。 　最後，給你一個建議。其實也是之前有人推文提到的， 不同的語言，不同的環境，有各自的生態 (coding convention)， 接受它，適應它，融入它；不然，就離開它吧。 以下恕刪。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.166.0.26
推
05/25 19:31, , 1F
你這篇讓我想到Joel on Software的Making Wrong Code Look
05/25 19:31, 1F
→
05/25 19:35, , 2F
Wrong...
05/25 19:35, 2F
→
05/25 19:36, , 3F
我是認為雛鳥要有雛鳥的樣子, 會爭論這個本來就是雛鳥...
05/25 19:36, 3F
→
05/25 19:36, , 4F
揠苗助長並不是好事，我倒是真的覺得，讓原 Po 多去跟公司內
05/25 19:36, 4F
→
05/25 19:37, , 5F
的前輩討論就是了:)
05/25 19:37, 5F
推
05/25 19:48, , 6F
純推這篇
05/25 19:48, 6F
→
05/25 20:11, , 7F
同意. 我年輕的時候也做過這種自我感覺正義的事情...
05/25 20:11, 7F
推
05/25 20:21, , 8F
推
05/25 20:21, 8F
推
05/25 21:30, , 9F
再講下去，asm也有兩大體系- -AT&T v.s. Intel
05/25 21:30, 9F
推
05/25 21:56, , 10F
code style太多種了，各有各的理由，很難說哪種真正最好
05/25 21:56, 10F
→
05/25 23:21, , 11F
謝謝你 其實joel那篇我首發就有附上網址了
05/25 23:21, 11F
→
05/25 23:22, , 12F
curly brace的問題我知道 只是以我目前對雙方看法的
05/25 23:22, 12F
→
05/25 23:22, , 13F
理解 我認為都有道理 所以我才說我覺得沒差
05/25 23:22, 13F
→
05/25 23:23, , 14F
以我目前理解沒有覺得誰更好 所以說沒差
05/25 23:23, 14F
→
05/25 23:24, , 15F
不過我會先去討論更重要的事情 謝謝建議!
05/25 23:24, 15F
→
05/25 23:39, , 16F
所以別爭這個，除非該模組以後只歸你管，那就隨你高興
05/25 23:39, 16F
→
05/25 23:41, , 17F
匈牙利表示法提出的背景，以我的看法那是該 API 設計不良
05/25 23:41, 17F
→
05/25 23:42, , 18F
所以才用匈牙利命名法來補牢一下
05/25 23:42, 18F
→
05/25 23:43, , 19F
所以如果你有一組又臭又長，很難用的API不用匈牙利會更糟
05/25 23:43, 19F
推
05/26 00:12, , 20F
呃... 你為什麼一定要找出一個理由
05/26 00:12, 20F
→
05/26 00:12, , 21F
coding style 的選擇很大一部分就純粹是順眼
05/26 00:12, 21F
→
05/26 00:13, , 22F
有時候就和你喜歡可口可樂或百事可樂一樣
05/26 00:13, 22F
→
05/26 08:49, , 23F
第一個例子不好, 因為那是1999年的文章, 快15年前了
05/26 08:49, 23F
→
05/26 08:50, , 24F
新的建議是 DO NOT use Hungarian notation.
05/26 08:50, 24F
→
05/26 08:51, , 25F
05/26 08:51, 25F
→
05/26 10:15, , 26F
那個啊, 不只15年, 1999 年是 reprint (重印), 應該20年有
05/26 10:15, 26F
→
05/26 10:16, , 27F
msds收錄它是為了歷史意義.不過如果要談優點,沒什麼比原
05/26 10:16, 27F
→
05/26 10:16, , 28F
作者自己說更好的了
05/26 10:16, 28F
推
05/26 12:21, , 29F
其實我滿意外這年頭還會看到有人發文戰匈牙利命名法
05/26 12:21, 29F
推
05/26 13:00, , 30F
咦，對耶。都沒記得你有貼那篇的連結 XD
05/26 13:00, 30F
→
05/26 21:55, , 31F
我對你無助生產力的論點不太認同就是
05/26 21:55, 31F
→
05/26 21:57, , 32F
不統一的code style絕對會造成問題, 起碼我見過不少次了
05/26 21:57, 32F
→
05/26 21:58, , 33F
減少問題發生產出錯誤率低的程式碼不是對生產力有幫助嗎?
05/26 21:58, 33F
→
05/26 22:00, , 34F
而code style的選擇絕對不是只因為順眼
05/26 22:00, 34F
→
05/26 22:00, , 35F
大多都是為了避免掉一些無謂的錯誤
05/26 22:00, 35F
→
05/27 10:39, , 36F
這裡我的確說過頭了. Codeing style 絕對是個重要的 issue
05/27 10:39, 36F
→
05/27 10:42, , 37F
原意只是希望原 po 能融入他的團隊. 不要硬推自己想法.
05/27 10:42, 37F
→
05/27 10:43, , 38F
修個文好了.
05/27 10:43, 38F
※ 編輯: Inkling 來自: 118.166.5.17 (05/27 10:44)
→
05/27 14:17, , 39F
不統一的 coding style 會造成這串討論，所以是問題 lol
05/27 14:17, 39F
推
05/27 22:54, , 40F
補1F的文章 http://goo.gl/LnMNy
05/27 22:54, 40F
‣ 更多 Inkling 的文章
文章代碼(AID): #1He9_FJ_ (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 16 之 19 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共19篇)
‣ 更多 Inkling 的文章
文章代碼(AID): #1He9_FJ_ (Soft_Job)