关于统一风格

    风格除了代码书写风格外，还包括文件、目录组织，错误处理、日志处理和调试策略等编码习惯。
    书写风格细分为命名规则、对齐规则、注释规则等。这些都是团队一起工作的保障。这都是外界公认的需要统一的东西。
    我想补充的是其它习惯，这些习惯也是同等重要。
首先是文件、目录组织。
    比较好的一种方式是这样：
    |--include
    |   |--idl
    |
    |--lib                              //静态库
    |   |--win32d
    |   |--win32
    |
    |--product                     //产品输出目录
    |   |--win32d
    |   |--win32
    |
    |--3rdpart                     //第三方库
    |   |--include                 //头文件
    |   |   |--wtl
    |   |   |--ace
    |   |--lib
    |   |   |--win32d
    |   |   |--win32
    |
    |--project1                  //工程1
    |--project2                  //工程2
    |   |--include
    |   |--function_folder
    |
    从上图可以看出，每一层目录有一个include，里面放的是本层以下需要共享的头文件，原则上是尽量往里放，只有共享范围超出了本层，才往上一层挪。
    lib是自己工程依赖的静态工程输出目录，可以看到lib和product都有win32d和win32，分别对应Debug版和Release版。
    第三方库放在3rdpart中，include目录放头文件，注意的是需要整理一下，如wtl的头文件放在wtl目录下，工程增加包含路径为“3rdpart/include”，使用时这样包含：#include "wtl/XXX.h"。lib的处理一样。
    如果工程有idl文件，idl会输出.h和.c文件，建议.c文件include在某个Cpp文件中，避免把它引入工程中，这样可以避免工程挪动时出现问题。一般可以把它包到main函数入口的cpp文件中。

错误处理
    理论上每一行程序都有可能出错，对每一行程序作容错处理是不现实的。一般来说，我们对函数的执行情况都是可以预知的，也正因为它的可以预知性，我们才能对它的返回情况作容错处理，否则容错是没有意义的。不可以预知的错误一般认为是异外，这种异外显然是无法处理的，或者说只能根据使用的局部性作一些简单的“放弃”。