第四章 兩人合作

原文：大家都知道用單個字母給有復雜語義的實體命名是不好的，在C語言家族中，比較通用的，也是經過了很多實踐檢驗的方法叫“匈牙利命名法”。

問題1：雖然看了書中接下來的一些解釋，但書中的解釋我認為有些冗余雜亂，致使我還是不太理解，到底什麽是“匈牙利命名法”？

後來我上網查找了一些資料，終於使我明白。總結來說，“匈牙利命名法”基本原則是：變量名=屬性+類型+對象描述。例如，表單的名稱為form，那麽在“匈牙利命名法”中可以簡寫為frm，當表單變量名稱為Switchboard時，變量全稱應該為 frmSwitchboard。這樣可以很容易從變量名看出Switchboard是一個表單，同樣，如果此變量類型為標簽，那麽就應命名成lblSwitchboard。

問題2：後文又說到，還有一些地方不適合用“匈牙利命名法”，比如在C#中，if（）語句只能接受bool值的表達式，匈牙利命名法並不適用，並且隨著IDE的不斷強大，馬上就可以顯示變量的具體定義信息，那麽是否就意味著“匈牙利命名法”可以被淘汰了呢？

在我閱讀了一些資料後，我的回答是，在Windows上用C/C++寫程序，使用匈牙利命名法為變量命名幾乎成為了一種本能。

（1）控件的命名依舊采用Hungarian Notation，例如：

Button -> btn
Label -> lbl
TextBox -> txt
…

控件上的Hungarian Notation要靠譜的多

（2）變量命名上，僅保留以下前綴

global -> g_
member -> m_
static -> s_
pointer -> p
char*/wchar_t* -> psz
char[]/wchar_t[] ->sz

m_能夠與非成員變量區分，而且基本可以避免變量重名而需要使用this指針的情況

g_和s_的意圖無需多說，global和static從來都需要特別對待

有人可能會對剩下的三個前綴頗有微詞，我的理由是，這三個類型（其實只有兩個）實在太特殊而且需要引起足夠的註意，加前綴的意圖則是告訴你：be careful! 其他的類型都盡量不加前綴。

第十七章 人、績效和職業道德

原文：人無完人，人非聖賢，總會犯錯誤，原因很多，有的是個人一念之差，有些是時間安排的問題，有的是仿生學的原理，有的可以追溯到社會的潛規則或種種因素。但是為什麽要這麽多花招？為什麽不能都當一回簡單的P1呢？

問題1:這段話讓我想起了我們以前做一體化軟件工程實踐課程中的前端頁面這件事，那可以說是我們大學以來第一次系統地進行兩人合作，可就是這一次合作讓我感受頗深。僅僅的兩人，就有一人在團隊裏不做事，當我提醒我的隊友做好我們分配好的任務時，隊友說：“我不會。”結果整個工作幾乎由我一人完成，但最後的得分我倆是一樣的。起初，我有些憤憤不平，為什麽我付出了這麽多卻要跟混日子的得到相同的回報？不過，慢慢地我釋然了。最後吸取到的經驗是：如果整個團隊是人人出力，那是最好不過的；若不是，只管對自己的工作負好責任，做好自己份內事情，不要去計較是否公平，至於結果就由他們自己承擔吧。總而言之，自己的心態和情緒不要被別人影響了。

《構建之法》第4章、第17章閱讀與思考