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

看板Soft_Job作者 (RESTful Web Services)時間12年前 (2013/05/24 15:00), 編輯推噓6(6推 0噓 42→)
留言48則, 12人參與, 最新討論串13/19 (看更多)
沒想到版上這麼多有經驗的前輩覺得對 coding style 的討論是一件 無聊的小事，討論串大概看了一下，不是很確定提出反對意見的版友 是覺得： 1. 爭論變數名稱前面要不要加上前綴很無聊？ 2. 在 coding style 上面堅持己見很無聊？ 還是 3. 覺得 coding style 也要拿出來討論很無聊？ 如果是前兩個我部分同意，但是如果是第三點我的想法是： 「 Coding style 當然是可以拿出來討論的，而且是必須在團隊中 拿出來討論的。」 先回到第一點的爭議，很多人說加上前綴對於在一般的文字編輯器中 開發很有幫助，但是不知道提出這個意見的版友有沒有遇過類似下面 這樣的程式碼？ enum LightState{ ON, OFF }; LightState bIsLightOn; ...... if (bIsLightOn == true) 或者是： set<int> m_vProductIDs; ...... m_vProductIDs.insert(productId) 如果剛好有 bug 出在這個地方，那個當下應該會很想把當初這樣寫 的人給ｏｏｘｘ 。這個時候前綴算是輔助還是干擾？ 或許有人會說那都是 they 的錯，但是當你開始意識到會有這種事情 發生的時候，這些前綴是輔助還是干擾？ 當然，這也不是不能解決的問題，只要有一個自動化的工具幫你 parse 所有的 source code 就可以了，這個工具可能還不用自己寫。 所以我們回到了第三點，或許 coding style / coding convension 比不上 unit test, daily build, version control 等其他許多工 具，但是 coding style 依舊很重要。不論你想怎樣大寫小寫，加或 不加前綴，如果團隊沒有一致的規範，你就沒有辦法用自動化的工具 揪出會讓人困惑的地方，大家讀程式、寫程式、除錯的時間就會增加。 所以我對原始提問者的建議是： 1. 不要固執自己的標準。 2. 請團隊共同討論，建立一套標準，很粗糙也沒有關係。 3. 用工具或 script language 每天把程式碼中不符合標準、會 造成誤解的部份找出來，在徵求 manager 的同意後每天把這 份結果公布。 [註] 先自首，coding style 的規範目前也在團隊導入中，上面的意 見並非經驗而是原本打算在團隊中實行的計畫。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 42.79.69.124
→
05/24 15:04, , 1F
無聊是指爭codingStyle這件事情吧，跟討論CS怎樣沒關係。
05/24 15:04, 1F
→
05/24 15:06, , 2F
你的例子也不好，一看到LightState bIsLightOn;就知道壞了
05/24 15:06, 2F
→
05/24 15:09, , 3F
這樣的前綴有幫助debug的效果，去掉前綴更難除。
05/24 15:09, 3F
依賴前綴的開發人員，很可能在一開始的時候忽略掉 bIsLightOn 的 宣告： LightState bIsLightOn; 至於比較容易除錯的問題我要再想想，但是如果可以在一開始的時候 就避免誤解，減少寫出錯誤程式的機會不是比較好嗎？
推
05/24 15:34, , 4F
若團隊當中沒人能夠凝聚共識付諸實行,確實會變成是一個
05/24 15:34, 4F
→
05/24 15:35, , 5F
無聊的話題,誰也不想聽誰的
05/24 15:35, 5F
→
05/24 15:39, , 6F
我看不懂你第二個例子是在說哪裡不好 ?
05/24 15:39, 6F
m_vProductIDs 的前綴暗示這個變數是一個 vector<int>，但是它的 實際型別是 set<int>
→
05/24 15:41, , 7F
第一個例子的話, 一開始會命名 LightState eLigthState
05/24 15:41, 7F
→
05/24 16:05, , 8F
呃，下錯前綴還用錯的程式，不用前綴這個人只會錯更大吧
05/24 16:05, 8F
→
05/24 16:05, , 9F
這種人其實更需要前綴提醒他自己不要寫、用錯屬性
05/24 16:05, 9F
→
05/24 16:07, , 10F
所以不依賴前綴為什麼可以解決這個問題？因為他們會花更多
05/24 16:07, 10F
→
05/24 16:07, , 11F
時間去看每個變數的型別？ LOL
05/24 16:07, 11F
→
05/24 16:08, , 12F
這就像是掩耳盜鈴一樣啊，看不到的問題不代表他就不存在。
05/24 16:08, 12F
或許我表達的不夠清楚，我想講的是如果你想要享受前綴帶來的好處 ，你最好有一個自動化的工具把錯誤的前綴找出來，所以需要建立 coding convesion / coding rule，這樣才方便建立一個 parser 做 這件事情。 我的舉例是因為我「主觀的相信」很多推崇前綴的人身邊並沒有這樣 的工具。 [註] 我不確定動態語言能不能也用 parser 或其他工具找出不符規 範的程式碼，這是我原本文章沒考慮到的地方。
→
05/24 16:09, , 13F
原po應該只是想要舉個前綴的壞處，除了麻煩不漂亮暫時想無
05/24 16:09, 13F
→
05/24 16:14, , 14F
我打個比方吧，這就好像訂立上班時間一定會有人遲到，所以為
05/24 16:14, 14F
→
05/24 16:14, , 15F
了避免有人遲到造成爭議，我們乾脆把上班時間廢了...
05/24 16:14, 15F
推
05/24 16:14, , 16F
這個例子完全沒說明前綴哪裡不好啊，只是說明宣告時寫錯
05/24 16:14, 16F
→
05/24 16:15, , 17F
這就好像是一段code明明是O(N)的但是註解寫O(lgN)，後來
05/24 16:15, 17F
→
05/24 16:15, , 18F
的人呼叫太多次就拖垮整個程式，那可以說明在註解寫上
05/24 16:15, 18F
→
05/24 16:15, , 19F
演算法的複雜度是個不好的習慣嗎？
05/24 16:15, 19F
加註解很好呀，但是你的註解如何跟你的程式碼同步呢？如果無法同 步，我一般會直接略掉註解。
→
05/24 16:33, , 20F
我覺得說 "犯了某某錯誤之後會如何如何" 會有點失焦
05/24 16:33, 20F
→
05/24 16:34, , 21F
很多正面良好的做法都會有能讓它們變得可笑的錯誤案例
05/24 16:34, 21F
推
05/24 16:39, , 22F
我覺得寫程式越笨越好
05/24 16:39, 22F
→
05/24 16:40, , 23F
命名也一樣 命名仔細一點 沒什麼壞處
05/24 16:40, 23F
→
05/24 16:41, , 24F
很多”沒必要”的事情 其實很有幫助
05/24 16:41, 24F
→
05/24 16:42, , 25F
個人覺得「註解無法同步所以直接略掉註解」不是好做法..
05/24 16:42, 25F
推
05/24 16:50, , 26F
不是所有人都有你的編輯器 如果是在記事本或網頁上看程式碼呢
05/24 16:50, 26F
→
05/24 16:55, , 27F
所以如果你想要享受紅綠燈帶來的好處，你得要有一個保證能
05/24 16:55, 27F
→
05/24 16:55, , 28F
禁止人、車闖紅燈的機器，不然紅綠燈就對你沒有任何好處。:Q
05/24 16:55, 28F
借用 TonyQ 的比喻，我想講的是如果沒有這種機器存在，每個人在 過馬路前最好記得先左右看一下，不然下一次社會新聞版面可能會有 你的名字出現。 不過我還是就此打住吧，或許就像 yoco315 說的：「只有新手才會 爭這種問題」。我要學習的還很多。 我並不是前綴字元的強烈反對者，希望我上面的文章不會給人這種感 覺，我也會用 m 表示成員變數，用 p 表示指標，只是更多時候我享 受 IDE 的便利，和少掉型別資訊的變數名稱讓我可以專注在問題本 身。如果我的專案夥伴覺得加上型別資訊比較好，那加上型別資訊也 很好，只要我們有一個規則可以區分字首 s 是 Set 還是 String 。
→
05/24 16:56, , 29F
現實是，人員遵守 guide line 才是重點，有部份不願意遵守的
05/24 16:56, 29F
→
05/24 16:57, , 30F
，是他們該被譴責，被是 guideline 該被譴責。根據團隊，嚴
05/24 16:57, 30F
→
05/24 16:57, , 31F
重一點的甚至會被踢出去。並不是不能 100% 保證不能出錯的
05/24 16:57, 31F
→
05/24 16:57, , 32F
機制才有價值，同樣的，多作多錯、不作不錯這種思維也不一定
05/24 16:57, 32F
→
05/24 16:57, , 33F
就真的比較有產出。:Q
05/24 16:57, 33F
→
05/24 16:58, , 34F
然後你每天都在享受不完美的紅綠燈對你帶來的好處，
05/24 16:58, 34F
→
05/24 16:58, , 35F
welcome to real world. :Q
05/24 16:58, 35F
→
05/24 17:00, , 36F
不過我是一直認為 team build 不能只靠制度跟機器就是了，
05/24 17:00, 36F
→
05/24 17:00, , 37F
重點是共識，如果都有共識要這麼做，不靠紅綠燈或許也能維持
05/24 17:00, 37F
→
05/24 17:01, , 38F
交通順暢(ex. stop sign)，總是會有方法的。
05/24 17:01, 38F
推
05/24 18:18, , 39F
TonyQ大說的太對了～～
05/24 18:18, 39F
推
05/24 18:36, , 40F
我個人看下來覺得大家講的是 2.
05/24 18:36, 40F
嗯嗯
→
05/24 19:28, , 41F
如果你本來在的環境有,除非有什麼重大益處,不然不要去挑
05/24 19:28, 41F
→
05/24 19:30, , 42F
動什麼新方法,有些Code或許不太好,但反思或許我們的產出
05/24 19:30, 42F
→
05/24 19:31, , 43F
在其他前輩或工作夥伴眼中亦同.我後來的做法是謹守自己的
05/24 19:31, 43F
→
05/24 19:32, , 44F
Coding Style並做文件跟註解,後來主管也願意接受某些確實
05/24 19:32, 44F
→
05/24 19:34, , 45F
需要規範的東西,最後在專案空閒時做了版本調整跟重構.
05/24 19:34, 45F
→
05/24 20:01, , 46F
現實是這是 project leader 的事, 如果leader不重視
05/24 20:01, 46F
→
05/24 20:01, , 47F
下面小嘍囉說破嘴也沒用, this is real world
05/24 20:01, 47F
→
05/24 20:03, , 48F
不過我會要求就是, 因為我的位置可以要求 XD
05/24 20:03, 48F
※ 編輯: elvispoetic 來自: 114.37.94.158 (05/25 00:16)
‣ 更多 elvispoetic 的文章
文章代碼(AID): #1Hdn0bAl (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 13 之 19 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共19篇)
‣ 更多 elvispoetic 的文章
文章代碼(AID): #1Hdn0bAl (Soft_Job)