《构建之法》第4章、第17章阅读与思考

第四章  两人合作

    原文：大家都知道用单个字母给有复杂语义的实体命名是不好的，在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:这段话让我想起了我们以前做一体化软件工程实践课程中的前端页面这件事，那可以说是我们大学以来第一次系统地进行两人合作，可就是这一次合作让我感受颇深。仅仅的两人，就有一人在团队里不做事，当我提醒我的队友做好我们分配好的任务时，队友说：“我不会。”结果整个工作几乎由我一人完成，但最后的得分我俩是一样的。起初，我有些愤愤不平，为什么我付出了这么多却要跟混日子的得到相同的回报？不过，慢慢地我释然了。最后吸取到的经验是：如果整个团队是人人出力，那是最好不过的；若不是，只管对自己的工作负好责任，做好自己份内事情，不要去计较是否公平，至于结果就由他们自己承担吧。总而言之，自己的心态和情绪不要被别人影响了。