Re: [請益] 要如何說服同事停止命名類似iID的變數
※ 引述《FukadaKyoko (小毛哥)》之銘言：
: 補充一些白天沒講清楚的細節:
部份恕刪。
前面有許多版友都提過了，
"如果你沒有辦法說服大多數人，請從眾。"
這不是放大絕，Coding Style 本來就是見仁見智的事。
這基本上不需要誰說服誰，公司/主管/大多數同意的 style
就是好的 style。
下面是基於一個曾經是匈牙利命名法的擁護者，而已經變節很
多年的人的立場，利用你舉得的例子，解釋一些個人的觀點：
: 再加上如果一個變數同時有兩種屬性那又會變成更長的prefix
: (如int array)
int[] 的 prefix 一般是 ai (array of integer)，兩個字母
不會多長。
: 比如說我看到一個vector3叫做 vPos, 一個member叫做m_bFloating
: 了解function內部後我可能會改成
: if (m_IsFloating) PlayerPosition.z += 100.0f;
: 而原本的: if (m_bFloating) vPos.z =+ 100.0f;
: 似乎沒有比較好維護啊?
這裡有個問題，在我個人的習慣，
IsFloating 會是函數/方法名，不會是變數名。
三種情況：
1. 前面有個 m_，可以區分它是 member variables，
那，m_ 不也個 prefix ? (我沒寫過 m_ 這種 prefix)
2. 後面沒有 ()，我看程式碼的第一直覺會是，誰打漏了 () 嗎?
3. 滑鼠移過去：ok, 了解了。可是我為何要移滑鼠來確認呢？
這樣你是否可以體會另一邊的人的想法？
: 而且在這邊我在乎的只是: "若是漂浮狀態, 則玩家的Z軸+100"
: 我完全不在乎型別是甚麼: 甚至
: void SetID(int iID)
: {
: m_iID = iID;
: }
: 我一定會改成
: void SetID(int ID)
: {
: m_ID = ID;
: }
這裡啊，因為我從不加 m_，所以一直都很討厭。
我會寫成：
void SetID(int iID)
{
this.iID = iID; // 如果有 this
}
或，其實我更常作的是：
void SetID(int newID)
{
iID = newID;
}
重點在改 function/method 的參數，但 *不* 碰 member field。
原因等下說。
: 或者: 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 = ... 或者任何更符合該變數角色的名字
: 不是比較清楚嗎?
不，對我而言一點也不清楚。
匈牙利命名在這裡應該寫：
ObjInfo* psInfo = ...
p 代表 pointer。
因為如果 Info 是指標，後續會變成： Info->
參考， Info.
對，IDE 會告訴我，但如果我只是快速瀏覽呢？
更具體的說，看到 sInfo，我知道它是一個 struct，
等等預期會看到 . 或 -> 去存取它的 field；只看到
Info，我會把它當成 primitive type，看到接著 .
或 -> 會愣一下。
: UserProfile好還是user_profile好我覺得確實見仁見智
這個我才覺得討厭。
之前很喜歡 Java 的這種 CamelCase，昨兒翻 Python
的 PEP8 ，建議不要用 CamelCase，要寫 camel_case，
才很怒的將正在寫的 python 碼翻修了一遍...
: 但szUserProfile或是szuser_profile我就會覺得為甚麼要加?
sz -> char * -> string end with \0
str -> String
當你會混用 C 的 char * 和 C++ 的 String 時，你就知道為
什麼要加了。
: 且如我所說我們專案沒有規範, 我是很希望可以建立專案的coding style
: nobody1大大
: andymai大大
: 我說服不了別人
: 也無法被說服
: 因為我同事只有兩個理由"習慣了", "有差嗎?"
: 主管的理由是"我們不限制做法"
: 我想這種理由應該很難說服人吧
很難，可是這就是現實。
不能說服大多數人，就從眾；或者，努力拼上主管位。
: TonyQ板大所提
: "大多數情況下需要知道型態，特別是大型系統架構"
: 確實我是沒接觸過: 也無法想像為何需要知道
: 如果板大可以話不知是否能夠舉幾個實例供觀摩
: 感激不盡!
我不知道 TonyQ 的具體意見。不過，前面留下一點沒說的，
你舉了不少例子你看懂 xxx ，你就會改成 yyy。
這個很危險。
函數的參數，你改沒問題。member fields/variables 你改了名字，
如果不幸它是 public/protected 的怎辦？
我知道 IDE 很強大可以幫你全替換掉；但如果你的另一個夥伴正寫
一個新的 class；進一步假設他對這個案子很熟，不用翻程式碼就可
以直接引用既存的 class。好死不死，他引用到了你改了名的
member fields，怎辦？最好的情況是編譯錯誤，其它...
要推 coding style ，可以：
1. 說服大多數人，或當主管。
2. 更重要的，由新專案開始推。舊專案，
if it's not broken, don't fix it.
別沒事找事，搬石頭砸腳。
--
我不知道你同事年紀多大，不過匈牙利命名法是微軟推廣開的。
去翻早期的 Win32 API，那個 prefix 才叫噁心。沒事來個
lpszXXX 啥的。
我同意在現在 C++/C#/Java 當道的年代，匈牙利命名法已經可
以功成身退 (我個人也不用了)。但是，歷史的包袱沒有辦法一
刀切。Coding Style 這種沒有絕對對錯的東西，就放寬心胸看
待它吧。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 203.145.208.242
推
05/24 00:01, , 1F
05/24 00:01, 1F
推
05/24 01:31, , 2F
05/24 01:31, 2F
推
05/24 15:18, , 3F
05/24 15:18, 3F
討論串 (同標題文章)
完整討論串 (本文為第 8 之 19 篇)：