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

[elvispoetic (RESTful Web Services)]

    沒想到版上這麼多有經驗的前輩覺得對 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
→ KanoLoa:無聊是指爭codingStyle這件事情吧，跟討論CS怎樣沒關係。
→ KanoLoa:你的例子也不好，一看到LightState bIsLightOn;就知道壞了
→ KanoLoa:這樣的前綴有幫助debug的效果，去掉前綴更難除。
    依賴前綴的開發人員，很可能在一開始的時候忽略掉 bIsLightOn 的
    宣告：
    LightState bIsLightOn;

    至於比較容易除錯的問題我要再想想，但是如果可以在一開始的時候
    就避免誤解，減少寫出錯誤程式的機會不是比較好嗎？

推 mycallsoft:若團隊當中沒人能夠凝聚共識付諸實行,確實會變成是一個
→ mycallsoft:無聊的話題,誰也不想聽誰的
→ shvanta:我看不懂你第二個例子是在說哪裡不好 ?
    m_vProductIDs 的前綴暗示這個變數是一個 vector<int>，但是它的
    實際型別是 set<int>

→ shvanta:第一個例子的話, 一開始會命名 LightState eLigthState
→ KanoLoa:呃，下錯前綴還用錯的程式，不用前綴這個人只會錯更大吧
→ KanoLoa:這種人其實更需要前綴提醒他自己不要寫、用錯屬性
→ TonyQ:所以不依賴前綴為什麼可以解決這個問題？因為他們會花更多
→ TonyQ:時間去看每個變數的型別？ LOL
→ TonyQ:這就像是掩耳盜鈴一樣啊，看不到的問題不代表他就不存在。
    或許我表達的不夠清楚，我想講的是如果你想要享受前綴帶來的好處
    ，你最好有一個自動化的工具把錯誤的前綴找出來，所以需要建立
    coding convesion / coding rule，這樣才方便建立一個 parser 做
    這件事情。

    我的舉例是因為我「主觀的相信」很多推崇前綴的人身邊並沒有這樣
    的工具。

    [註] 我不確定動態語言能不能也用 parser 或其他工具找出不符規
         範的程式碼，這是我原本文章沒考慮到的地方。

→ KanoLoa:原po應該只是想要舉個前綴的壞處，除了麻煩不漂亮暫時想無
→ TonyQ:我打個比方吧，這就好像訂立上班時間一定會有人遲到，所以為
→ TonyQ:了避免有人遲到造成爭議，我們乾脆把上班時間廢了...
推 raincole:這個例子完全沒說明前綴哪裡不好啊，只是說明宣告時寫錯
→ raincole:這就好像是一段code明明是O(N)的但是註解寫O(lgN)，後來
→ raincole:的人呼叫太多次就拖垮整個程式，那可以說明在註解寫上
→ raincole:演算法的複雜度是個不好的習慣嗎？
    加註解很好呀，但是你的註解如何跟你的程式碼同步呢？如果無法同
    步，我一般會直接略掉註解。

→ lovdkkkk:我覺得說 "犯了某某錯誤之後會如何如何" 會有點失焦
→ lovdkkkk:很多正面良好的做法都會有能讓它們變得可笑的錯誤案例
推 ianlin45:我覺得寫程式越笨越好
→ ianlin45:命名也一樣 命名仔細一點 沒什麼壞處
→ ianlin45:很多”沒必要”的事情 其實很有幫助
→ shvanta:個人覺得「註解無法同步所以直接略掉註解」不是好做法..
推 v7q4:不是所有人都有你的編輯器 如果是在記事本或網頁上看程式碼呢
→ TonyQ:所以如果你想要享受紅綠燈帶來的好處，你得要有一個保證能
→ TonyQ:禁止人、車闖紅燈的機器，不然紅綠燈就對你沒有任何好處。:Q
    借用 TonyQ 的比喻，我想講的是如果沒有這種機器存在，每個人在
    過馬路前最好記得先左右看一下，不然下一次社會新聞版面可能會有
    你的名字出現。

    不過我還是就此打住吧，或許就像 yoco315 說的：「只有新手才會
    爭這種問題」。我要學習的還很多。

    我並不是前綴字元的強烈反對者，希望我上面的文章不會給人這種感
    覺，我也會用 m 表示成員變數，用 p 表示指標，只是更多時候我享
    受 IDE 的便利，和少掉型別資訊的變數名稱讓我可以專注在問題本
    身。如果我的專案夥伴覺得加上型別資訊比較好，那加上型別資訊也
    很好，只要我們有一個規則可以區分字首 s 是 Set 還是 String 。

→ TonyQ:現實是，人員遵守 guide line 才是重點，有部份不願意遵守的
→ TonyQ:，是他們該被譴責，被是 guideline 該被譴責。根據團隊，嚴
→ TonyQ:重一點的甚至會被踢出去。並不是不能 100% 保證不能出錯的
→ TonyQ:機制才有價值，同樣的，多作多錯、不作不錯這種思維也不一定
→ TonyQ:就真的比較有產出。:Q
→ TonyQ:然後你每天都在享受不完美的紅綠燈對你帶來的好處，
→ TonyQ:welcome to real world. :Q
→ TonyQ:不過我是一直認為 team build 不能只靠制度跟機器就是了，
→ TonyQ:重點是共識，如果都有共識要這麼做，不靠紅綠燈或許也能維持
→ TonyQ:交通順暢(ex. stop sign)，總是會有方法的。
推 zeldein:TonyQ大說的太對了～～
推 CRPKT:我個人看下來覺得大家講的是 2.
    嗯嗯

→ antiasus:如果你本來在的環境有,除非有什麼重大益處,不然不要去挑
→ antiasus:動什麼新方法,有些Code或許不太好,但反思或許我們的產出
→ antiasus:在其他前輩或工作夥伴眼中亦同.我後來的做法是謹守自己的
→ antiasus:Coding Style並做文件跟註解,後來主管也願意接受某些確實
→ antiasus:需要規範的東西,最後在專案空閒時做了版本調整跟重構.
→ realmeat:現實是這是 project leader 的事, 如果leader不重視
→ realmeat:下面小嘍囉說破嘴也沒用, this is real world
→ realmeat:不過我會要求就是, 因為我的位置可以要求 XD
※ 編輯: elvispoetic     來自: 114.37.94.158        (05/25 00:16)