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

看板Soft_Job作者 (小毛哥)時間12年前 (2013/05/25 00:41), 編輯推噓17(17推 0噓 30→)
留言47則, 16人參與, 最新討論串14/19 (看更多)
還是先謝謝各位板友的意見 沒想到會被砲這麼大 今天想了很久, 發現我的確把標題跟內文都下錯了 加入太多情緒性用詞掩蓋了我的問題 我想我真正要問的應該是 "制訂coding style時, 加入型別縮寫prefix的優缺點是? 有無何者較佳?" 我在自己工作的經驗之中覺得 不加縮寫的code更清楚 因第一眼就可以看到變數真正的名字 且在寫碼時也可以少打字 我自己撰寫或者閱讀專案的code也都沒有依靠型別縮寫 而在網路上搜尋過一些文章, 也都有贊同不需加上縮寫的論點 所以我感覺不加prefix是可行的 只是在與同事討論時 大多的反應是"沒差吧", "舊的code有加就跟著加啦" 但我想知道是堅持要加的人的理由 這麼做的優點在哪 因為我的工作經驗沒有感覺到優點, 只有缺點 規範由主管制訂很正常 但既然還未制訂, 那我覺得同事間自己取得共識(如板大所言"共識"為重點) 主管應該只是樂見其成而已 且大家有共識自然形成規範, 比誰來制訂都更好 所以現在規範還處在討論階段 我發此問題只是想收集一些能加強我的論點的意見 因為我相信板上一定也有覺得不加prefix比較好的人 當然我是偷懶了, 因為我還沒有把所有相關書跟文章都看完 發文的時候也太急沒有提供完整的論點 總之, 或許要加不加真的沒有優劣 但未來的專案規範總會選一個 我只是希望能制訂一個適合且大家都能接受的規範 在決定的時候能夠有充分的理由 而不是很單純的"啊就這樣啊" 我的確是新手一枚 工作才兩年多一點而已 只待過3個專案 但3個專案都沒有規範與code review 所以非常希望可以建立這個制度 因為我一直覺得要有規範與review專案成員的實力才會不斷變強 程式碼的品質才會提高, 進而提升產品品質 這點應該大家應該會同意吧? 問這個問題自曝其短也沒關係 因為我確實就很弱 就是因為弱所以希望可以把每件事學好 做任何一件事都有對的理由 專案制訂了規範我當然會遵守 但前提是這個規範的每一條都有充分的理由 我想大家應該也都會想理解規範制訂的理由 也希望遵守自己認同的規範吧? 結論是, 因為我偷懶沒看完文章 就不繼續發表論點或舉例了, 否則不完整的言論發表出來也是浪費大家時間 謝謝板友推薦的The art of readable code 希望能找到便宜的貨 Orz -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 115.43.117.251
推
05/25 01:02, , 1F
給你個建議 先從大家都同意的開始訂規則.這樣阻力最小.
05/25 01:02, 1F
→
05/25 01:03, , 2F
然後這是長期抗戰,要比的是耐心.
05/25 01:03, 2F
→
05/25 01:03, , 3F
等到那個專案你最老,那麼就是你說了算.
05/25 01:03, 3F
推
05/25 01:20, , 4F
在業界工作, 只有一個目的, 就是賺錢, 把心裡所有想做的
05/25 01:20, 4F
推
05/25 01:20, , 5F
其實你現在需要的不是啥coding能力了，你要學的是職場觀念
05/25 01:20, 5F
→
05/25 01:20, , 6F
或稱職場厚黑學
05/25 01:20, 6F
→
05/25 01:21, , 7F
事排序一下, 先處理project最急切的事, 而不是處理自己
05/25 01:21, 7F
→
05/25 01:22, , 8F
最不爽的事. 不過, 我也是很排斥匈亞利命名法, 也很討厭
05/25 01:22, 8F
推
05/25 01:23, , 9F
Linus: Hungarian notation is brain damaged
05/25 01:23, 9F
→
05/25 01:24, , 10F
名稱用縮寫, 但是團隊合作的時候, 除非對方的code完全看
05/25 01:24, 10F
→
05/25 01:24, , 11F
小弟長時間在linux kernel&driver打混，偶爾寫一下MFC差點
05/25 01:24, 11F
→
05/25 01:25, , 12F
不懂, 不然根本不會去要求對方修正, 我覺得tab vs space
05/25 01:25, 12F
→
05/25 01:25, , 13F
才是最痛苦的~~~~
05/25 01:25, 13F
推
05/25 01:26, , 14F
全型空白才是最痛苦
05/25 01:26, 14F
→
05/25 01:26, , 15F
可以用astyle幫你排程式，寫的人不用在意tab or space
05/25 01:26, 15F
→
05/25 01:27, , 16F
反正最後commit前用astyle排成team理規定的樣式就行了~
05/25 01:27, 16F
推
05/25 01:40, , 17F
我超討厭prefix，即使我用vim寫Lua也一樣
05/25 01:40, 17F
→
05/25 01:41, , 18F
型別那麼多誰知道哪個縮寫對應到哪個class
05/25 01:41, 18F
推
05/25 01:46, , 19F
function name沒人搞這套，但大家還不是用得好好的
05/25 01:46, 19F
推
05/25 04:56, , 20F
其實就你的文章看來 你的問題在不會做人 要推動任何東西
05/25 04:56, 20F
→
05/25 04:56, , 21F
搞不定人的問題 講再多道理都沒用 你對又如何? 別人還是
05/25 04:56, 21F
→
05/25 04:57, , 22F
可以不理你 硬要爭對錯 基本上就錯了
05/25 04:57, 22F
→
05/25 04:58, , 23F
重點不在證明對方錯 重點在如何說服別人 這是兩件事情
05/25 04:58, 23F
推
05/25 08:07, , 24F
因為我的工作經驗沒有感覺到優點<<
05/25 08:07, 24F
→
05/25 08:08, , 25F
這讓人想嗆你算哪根蔥 別人寫的程式搞不好比你吃的飯多
05/25 08:08, 25F
→
05/25 08:10, , 26F
先不論coding 你的思維從一開始就讓人不想跟你co-work
05/25 08:10, 26F
→
05/25 08:16, , 27F
我覺得年資不是個問題, 真的好的東西就該推行
05/25 08:16, 27F
→
05/25 08:19, , 28F
如果code style是延續而不經思考, 這很糟糕
05/25 08:19, 28F
→
05/25 08:20, , 29F
我轉行換工作換環境, 原本的code style我就覺得不適用了
05/25 08:20, 29F
推
05/25 10:52, , 30F
其實「大家習慣」就是一種規範，原PO今天想作的不是
05/25 10:52, 30F
→
05/25 10:52, , 31F
「訂立規範」而是「改變規範」，一方面否定原本規範，
05/25 10:52, 31F
→
05/25 10:53, , 32F
又誤打著「沒規範要訂規範」的大旗，推起來窒礙難行是
05/25 10:53, 32F
→
05/25 10:53, , 33F
一定的
05/25 10:53, 33F
→
05/25 11:04, , 34F
05/25 11:04, 34F
推
05/25 11:32, , 35F
Linus放砲很多次了，wikiquote看一看覺得他有時很固執
05/25 11:32, 35F
推
05/25 13:31, , 36F
我覺得與其討論這個，不如討論過度縮寫的問題
05/25 13:31, 36F
→
05/25 13:32, , 37F
很多人縮到只剩幾個字，別人根本看不懂
05/25 13:32, 37F
推
05/25 14:23, , 38F
我寫UI很常用前綴來分別控制元件啦，不用我會死得
05/25 14:23, 38F
推
05/25 18:26, , 39F
我覺得型別prefix(or suffix) 跟 "prefix 縮寫"是兩回事
05/25 18:26, 39F
→
05/25 23:18, , 40F
謝謝大家 縮寫也是我想討論的點...我們專案也有這問題
05/25 23:18, 40F
→
05/25 23:19, , 41F
我也是少用 prefix，除非在特定場合下，它有明顯的好處時
05/25 23:19, 41F
→
05/25 23:20, , 42F
我幾乎不用型別 prefix ，除了少數場合，避免混淆才用
05/25 23:20, 42F
推
05/28 00:47, , 43F
人家Linus有linux kernel，不知道躲在推文罵他是腦殘的
05/28 00:47, 43F
→
05/28 00:48, , 44F
又有什麼驚人的貢獻了XDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
05/28 00:48, 44F
推
05/28 02:26, , 45F
我也用Linux，但不代表我會贊同他說的所有的話
05/28 02:26, 45F
推
05/28 02:29, , 46F
BTW,Linux Kernel也不是他一個人獨攬的功勞
05/28 02:29, 46F
→
05/28 02:31, , 47F
而且我的暱稱都取"Linus is good"了(lol)
05/28 02:31, 47F
‣ 更多 FukadaKyoko 的文章
文章代碼(AID): #1HdvWahV (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 14 之 19 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共19篇)
‣ 更多 FukadaKyoko 的文章
文章代碼(AID): #1HdvWahV (Soft_Job)