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

看板Soft_Job作者 (小毛哥)時間11年前 (2013/05/23 22:00), 編輯推噓12(12推 0噓 32→)
留言44則, 20人參與, 最新討論串6/19 (看更多)
補充一些白天沒講清楚的細節: 我現在待的是遊戲公司 專案開發只用VS2008寫C++ 還有FlashDevelop寫action script 3做UI 我是希望針對這個環境下討論 許多前輩的推文很有道理 比如使用notepad++, 或者客戶端沒有IDE, 但因為我們的專案沒有遇到這種case, 所以我是希望暫不討論 另, 遵循規範這點我想大家也都有共識 但我們專案目前就是在放牛吃草 大家各搞各的, 我覺得這樣很糟 一個專案沒有規範很麻煩, 我想這應該大家也有共識 我們使用的IDE都可以看到變數名稱, 宣告的檔案所在, 甚至前後註解 所以藉由縮寫來判斷型別我真的覺得不太需要 astt88大大有提到一個問題 現在的型別很多 很難針對每一種去設定縮寫 再加上如果一個變數同時有兩種屬性那又會變成更長的prefix (如int array) onear大大所說的其實跟我是相同的想法 我並不是認為"不能加", 而是不需要加上沒有幫助的prefix onear大大所舉例的: UI元件可能會命名為txtAge 這個就與我原文引述約耳的文章內所說的一樣 prefix要表示的是"意義"而不是"型別" (原文使用kind == 意義與type == 型別) 同理成員變數加 m_我覺得是好的, 如onear大大所說可以快速分辨成員與區域變數 不過也有人提出成員變數開頭用大寫, 區域變數用小寫 甚至VAX這個plug-in可以直接幫你把區域變數變成斜體 說不定大家說好之後連 m_或大寫都可以省了 但總之onear大大所提的範疇都在於"意義命名" 我覺得非常正確, 也就是我想表達的點 onear大大還提到維護 其實我現在就是維護的很頭痛才想提不要加prefix... 比如說我看到一個vector3叫做 vPos, 一個member叫做m_bFloating 了解function內部後我可能會改成 if (m_IsFloating) PlayerPosition.z += 100.0f; 而原本的 if (m_bFloating) vPos.z =+ 100.0f; 似乎沒有比較好維護啊? 而且在這邊我在乎的只是 "若是漂浮狀態, 則玩家的Z軸+100" 我完全不在乎型別是甚麼 甚至 void SetID(int iID) { m_iID = iID; } 我一定會改成 void SetID(int ID) { m_ID = ID; } 或者 ObjInfo* GetInfo(int iID) { InfoMap::iterator oIter = m_Data.find(iID); if (oIter != m_Data.end()) { return oIter->second; } return NULL; } 改成 ObjInfo* GetInfo(int ID) { InfoMap::iterator It = m_Data.find(ID); if (It != m_Data.end()) { return It->second; } return NULL; } 在這邊 o或者 i對我完全沒幫助 再舉 在接收端, 因為ObjInfo是一個struct 那可能就有人會寫個 ObjInfo* sInfo = GetInfo(iID); 那改成 ObjInfo* Info = ... ObjInfo* ObjInfo = ... 或者任何更符合該變數角色的名字 不是比較清楚嗎? 因為看到太多這種為加而加的case 我才更認為針對意義命名遠大於型別 chucheng大大說到好讀是重點 "方便讀懂，關鍵在清楚" 我非常同意 我就是覺得ID比iID好讀所以才想跟同事討論這件事 UserProfile好還是user_profile好我覺得確實見仁見智 但szUserProfile或是szuser_profile我就會覺得為甚麼要加? SecretWhale大大說的沒錯 我算是在興頭上 但也可說不是, 因為我已經被這個問題困擾超過一年了 現在大概是覺得快要受不了了吧 但coding style算枝微末節嗎? 我覺得不算, 因為每個專案都應該要有規範才對 否則成員做事沒有紀律 對於開發或者維護都是阻礙 且如我所說我們專案沒有規範, 我是很希望可以建立專案的coding style nobody1大大 andymai大大 我說服不了別人 也無法被說服 因為我同事只有兩個理由"習慣了", "有差嗎?" 主管的理由是"我們不限制做法" 我想這種理由應該很難說服人吧 NDark大所言極是 確實是政治問題 但如果以此做結論的話那我也只好嘆一口氣了 (無奈!) TonyQ板大所提 "大多數情況下需要知道型態，特別是大型系統架構" 確實我是沒接觸過 也無法想像為何需要知道 如果板大可以話不知是否能夠舉幾個實例供觀摩 感激不盡! 有些沒回覆到的板友抱歉 希望不要見怪 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 115.43.117.251
推
05/23 22:07, , 1F
其實規範這種問題 都是大家看得懂就好
05/23 22:07, 1F
→
05/23 22:07, , 2F
如果你提的意見沒有被採納 你就應該照大家的意見來走
05/23 22:07, 2F
→
05/23 22:07, , 3F
這有一部分是習慣問題 改習慣是ㄧ種成本
05/23 22:07, 3F
推
05/23 22:13, , 4F
其他大家說的都對，應該還是看在哪種IDE環境
05/23 22:13, 4F
→
05/23 22:15, , 5F
像我早期也是用匈牙利，但現在也照微軟不加型態的prefix
05/23 22:15, 5F
→
05/23 22:16, , 6F
因為程式依但加了一堆累贅詞或底線，看code改code很累
05/23 22:16, 6F
推
05/23 22:17, , 7F
這種事真的是習慣就好 我都是 dataArray urlStr 之類的~
05/23 22:17, 7F
→
05/23 22:19, , 8F
所以目前除了控制項會加以外(因為太多命名方便不重複)
05/23 22:19, 8F
→
05/23 22:21, , 9F
都採用意義法，可避免命名太長、看大量code可以快速理解
05/23 22:21, 9F
→
05/23 22:23, , 10F
但部分系統用弱IDE維護，還是匈牙利方便
05/23 22:23, 10F
→
05/23 22:23, , 11F
但完全同意團隊需要開發環境編譯規範，不然維護會很亂
05/23 22:23, 11F
→
05/23 22:25, , 12F
一個人開發隨便都可以。但改別人code我也盡量跟著其風格
05/23 22:25, 12F
→
05/23 22:53, , 13F
建議參考code complete/code craft相關章節 基本上我覺得
05/23 22:53, 13F
→
05/23 22:53, , 14F
你在做的是吃力不討好的事情 除非你重起爐灶一個project
05/23 22:53, 14F
→
05/23 22:54, , 15F
否則我認為這事你應該學者"放寬"自己的標準
05/23 22:54, 15F
→
05/23 23:06, , 16F
附帶一提 硬把自已的標準 框在別人身上 對雙方都是不好的
05/23 23:06, 16F
→
05/23 23:08, , 17F
共事要有共識 不是說自已的一套好 別人就差
05/23 23:08, 17F
→
05/23 23:10, , 18F
看別人的code是磨練自已的心性的最好練習 （無誤）
05/23 23:10, 18F
→
05/23 23:17, , 19F
我是建議你當到主管再去推.有的時候為了這種問題搞出意料
05/23 23:17, 19F
→
05/23 23:18, , 20F
外的BUG不是沒有可能,如果未來你底下的人也來這一套,版本
05/23 23:18, 20F
→
05/23 23:19, , 21F
的控制會很"歡樂".
05/23 23:19, 21F
→
05/23 23:20, , 22F
我還在資訊業界的前幾年,也曾幹過此事,被主管叫去念一頓.
05/23 23:20, 22F
→
05/23 23:27, , 23F
你同事都已經不想改了，你還一直講，小心被白眼
05/23 23:27, 23F
推
05/23 23:47, , 24F
最討厭這種自以為救世主「我高你們一等」的心態
05/23 23:47, 24F
→
05/23 23:47, , 25F
你注意一點，coding style 真的是小事，爭這超沒意義的
05/23 23:47, 25F
推
05/23 23:56, , 26F
我也贊同入境隨俗, 就算你真的沒改變 coding style 就睡不著
05/23 23:56, 26F
→
05/23 23:57, , 27F
我也建議你直接導入一整套, 比如說 google c++ style guide
05/23 23:57, 27F
→
05/23 23:58, , 28F
而不是東補一點西改一點, 補丁式的改法也比較難說服人
05/23 23:58, 28F
→
05/24 01:07, , 29F
有些遊戲改副本結果改到拍賣場壞掉 該不會就是這樣改XD?
05/24 01:07, 29F
推
05/24 07:58, , 30F
約耳:"讓錯的程式看得出錯" 他們的命名更囉唆 XDD
05/24 07:58, 30F
推
05/24 09:18, , 31F
XD 多看一些開源專案，你會發現命名什麼的阻礙不了你
05/24 09:18, 31F
推
05/24 10:32, , 32F
原PO真的很盧...如果你能向老闆保證大家統一coding
05/24 10:32, 32F
→
05/24 10:33, , 33F
style後專案開發時程能縮一半 or 遊戲大賣百萬套
05/24 10:33, 33F
→
05/24 10:33, , 34F
保證主管全力挺你ww
05/24 10:33, 34F
→
05/24 13:12, , 35F
"PlayerPosition" 首字大寫會分不清楚 Class 跟 variable
05/24 13:12, 35F
→
05/24 13:13, , 36F
你確定你要用這種 coding rule? Orz
05/24 13:13, 36F
推
05/24 13:44, , 37F
看語言吧 C# 的 property 就是大寫
05/24 13:44, 37F
→
05/24 14:03, , 38F
對不起 我可能口氣讓大家誤會...重點只是想設定好規範
05/24 14:03, 38F
→
05/24 14:03, , 39F
首字小寫也可 重點是不要型別縮寫
05/24 14:03, 39F
→
05/24 20:47, , 40F
這樣說好了，假設大家同意 iID，你願意改嗎 XD
05/24 20:47, 40F
推
05/25 01:04, , 41F
Linus: Hungarian notation is brain damaged.
05/25 01:04, 41F
推
05/25 09:56, , 42F
And so is (beep!).
05/25 09:56, 42F
推
05/26 14:49, , 43F
若探討的是寫法的問題 是要看通用性 而不是看該專案或該公司
05/26 14:49, 43F
→
05/26 14:49, , 44F
若按照所述 是要該專案或該公司 那怎麼玩都是小圈圈阿
05/26 14:49, 44F
‣ 更多 FukadaKyoko 的文章
文章代碼(AID): #1HdY3tdW (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 6 之 19 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共19篇)
‣ 更多 FukadaKyoko 的文章
文章代碼(AID): #1HdY3tdW (Soft_Job)