关于《构建之法》第四章和第十七章的问题

关于《构建之法》第四章和第十七章的问题

第四章：

问题一：在关于“缩进”，书中不提倡用tab键。而建议使用四个空格。但是tab键可设置占符数，在实际开发中，tab键是缩进的快捷键， 我无法想像每次使用缩进都要敲四次空格。

问题二：关于开闭括号

在C语言学习中，国外教材普遍使用形式如下，形式一：

int max(int num1, int num2)
{
    return (num1 > num2) ? num1 : num2;
}

而在《Thingking in Java》中，作者使用的风格如下，这也是官方源码的风格。形式二：

public static int max(int num1, int num2){
    return (num1 > num2) ? num1 : num2;
}

书中说形式一的形式比较清晰，所以选择形式一。

但是，我觉得形式二确更容易凭右括号找到左括号，结构比形式一更清晰。观察如下代码：

//形式一：
if (num1 > num2)
{                                         // 1处
    max = num1;
}
else
{
    max = num2;
}                                        //根据此处找左括号可能被1处括号混肴

//形式二：
if (num1 > num2){
    max = num1;
}                                       //2
else{                               
    max = num2;
}                                       //3 根据此处找左括号可轻易找2,3 
                                         //之间的左括号                                   

　　

我想，对于编码风格，首先按照团队的规定，若团队无规定，则按照官方源码风格。标准的统一是生产力提高的因素之一。

第十七章：

问题：关于绩效评比中的“背靠背评比方式”，引文如下。

根据所有其他人的评价来决定某个人的绩效？这样会发生小团体抱团，以及劣币驱逐良币的现象。做游戏的工程师一定听说过维尔福公司（Valve[注释6]，开发有半条命、反恐精英等游戏），这家公司的员工手册[注释7]很有意思，大家不妨看看。根据手册的描述，维尔福的员工可以自由支100%的工作时间，做什么项目、在哪儿工作等，员工可以自己做主。但是在绩效评估上，他们用了队友评估这一机制，得出下列四个值：

1. 技术等级/技术能力
2. 劳动生产力/结果
3. 对团队的贡献（做一些工具让大家的工作更容
易，帮助招人）
4. 对产品的贡献（除本职工作外，对产品有帮助
的活动，比如找Bug、预测用户的反馈、产品推
广等）

这种评比方式让我想起了班级内的投票，得票最多的人一般是人际关系不错的人，还有就像书中所说的“萝卜”一样在团队中显眼，看起来高效，看起来给团队带来的贡献最大，但是却使得团队花更多时间在debug上。与之相反，效率中等但是开发稳定的“白菜”是不是吃亏了？这种“背靠背评比”的方式是否太主观了？如果有一个独立于项目的专业人士对团队内的成员进行评比（评比方面为引文中的四点），评比结果为“局外人”的评比和“背靠背”评比的综合，是不是更合理？