2. 在包含头文件时应该加上头文件所在工程的文件夹名，即假如你有这样一个工程base，里面有一个logging.h，那么外部包含这个头文件应该这样写：
#include "base/logging.h"，而不是#include "logging.h"
我们看到的是这里《Google C++ 编程风格指南》倡导的原则背后隐藏的目的是：
1. 为了减少隐藏依赖，同时头文件和其实现文件匹配，应该先包含其首选项（即其对应的头文件）。
2. 除了首选项外，遵循的是从一般到特殊的原则。不过我觉得《Google C++ 编程风格指南》的顺序：C标准库、C++标准库、其它库的头文件、你自己工程的头文件中漏了最前面的一项：操作系统级别的头文件，比如上面的例子sys/types.h估计不能归入C标准库，而是Linux操作系统提供的SDK吧。因此我觉得更准确的说法应该是：OS SDK .h , C标准库、C++标准库、其它库的头文件、你自己工程的头文件。
3.之所以要将头文件所在的工程目录列出，作用应该是命名空间是一样的，就是为了区分不小心造成的文件重名。
二．《C++编程思想》中的不同观点
与《Google C++ 编程风格指南》不同的是，《C++编程思想》倡导一种不同的规则。《C++编程思想》P432提到：
头文件被包含的顺序是从“最特殊到最一般”。这就是，在本地目录的任何头文件首先被包含。然后是我们自己的所有“工具”头文件，随后是第三方库头文件，接着是标准C++库头文件和C库头文件。
要了解其原因：可以看JohnLakos在《Large ScaleC++ Softwre Design》(注：其中文译名为《大规模C++程序设计》)中的一段话：
保证.h文件的组成部分不被它自身解析（parse）,这可以避免潜在的使用错误。因为被自身解析缺乏明确提供的声明或定义。在.c文件的第一行包含.h 文件能确保所有对于构件的物理界面重要的内部信息块都在.h中（如果的确是缺少了某些信息块，一旦编译这个.c文件时就可以发现这个问题）。
如果包含头文件的顺序是“从最特殊到最一般”，如果我们的头文件不被它自己解析。我们将马上找到它，防止麻烦事情发生。
三．我的试验
到底哪一种包含顺序好呢？我使用VS 2005编一个控制台测试工程TestInc，里面有几个文件。
MyMath.h的代码如下：
<span style="font-size:16px;">#pragma once
#pragma once
double acos(double Num);
</span>
MyMath.cpp的代码如下：
<span style="font-size:16px;">double acos(double Num)
{
return 1.0;
}
</span>
