[译]Google C++编程风格指南(八)[完]
2015-01-23 11:32
218 查看
规则之例外
前面说明的编码习惯基本是强制性的,但所有优秀的规则都允许例外。
1. 现有不统一代码(Existing Non-conformant Code)
对于现有不符合既定编程风格的代码可以网开一面。
当你修改使用其他风格的代码时,为了与代码原有风格保持一致可以不使用本指南约定。如果不放心可以与代码原作者或现在的负责人员商讨,记住,一致性包括原有的一致性。
1. Windows代码(Windows Code)
Windows程序员有自己的编码习惯,主要源于Windows的一些头文件和其他Microsoft代码。我们希望任何人都可以顺利读懂你的代码,所以针对所有平台的C++编码给出一个单独的指导方案。
如果你一直使用Windows编码风格的,这儿有必要重申一下某些你可能会忘记的指南(译者注,我怎么感觉像在被洗脑:D):
1) 不要使用匈牙利命名法(Hungarian notation,如定义整型变量为
2) Windows定义了很多原有内建类型的同义词(译者注,这一点,我也很反感),如
3) 使用Microsoft Visual C++进行编译时,将警告级别设置为3或更高,并将所有warnings当作errors处理;
4) 不要使用
5) 除非万不得已,否则不使用任何不标准的扩展,如
在Windows上,只有很少一些偶尔可以不遵守的规则:
1) 通常我们禁止使用多重继承,但在使用COM和ATL/WTL类时可以使用多重继承,为了执行COM或ATL/WTL类及其接口时可以使用多重实现继承;
2) 虽然代码中不应使用异常,但在ATL和部分STL(包括Visual
C++的STL)中异常被广泛使用,使用ATL时,应定义
3) 通常每个项目的每个源文件中都包含一个名为
4) 通常名为
团队合作
参考常识,保持一致。
编辑代码时,花点时间看看项目中的其他代码并确定其风格,如果其他代码
编程风格指南的使用要点在于提供一个公共的编码规范,所有人可以把精力集中在实现内容而不是表现形式上。我们给出了全局的风格规范,但局部的风格也很重要,如果你在一个文件中新加的代码和原有代码风格相去甚远的话,这就破坏了文件本身的整体美观也影响阅读,所以要尽量避免。
好了,关于编码风格写的差不多了,代码本身才是更有趣的,尽情享受吧!
翻议作者链接:http://www.cppblog.com/Fox/archive/2008/07/23/56933.html
前面说明的编码习惯基本是强制性的,但所有优秀的规则都允许例外。
1. 现有不统一代码(Existing Non-conformant Code)
对于现有不符合既定编程风格的代码可以网开一面。
当你修改使用其他风格的代码时,为了与代码原有风格保持一致可以不使用本指南约定。如果不放心可以与代码原作者或现在的负责人员商讨,记住,一致性包括原有的一致性。
1. Windows代码(Windows Code)
Windows程序员有自己的编码习惯,主要源于Windows的一些头文件和其他Microsoft代码。我们希望任何人都可以顺利读懂你的代码,所以针对所有平台的C++编码给出一个单独的指导方案。
如果你一直使用Windows编码风格的,这儿有必要重申一下某些你可能会忘记的指南(译者注,我怎么感觉像在被洗脑:D):
1) 不要使用匈牙利命名法(Hungarian notation,如定义整型变量为
iNum),使用Google命名约定,包括对源文件使用
.cc扩展名;
2) Windows定义了很多原有内建类型的同义词(译者注,这一点,我也很反感),如
DWORD、
HANDLE等等,在调用Windows API时这是完全可以接受甚至鼓励的,但还是尽量使用原来的C++类型,例如,使用
const TCHAR *而不是
LPCTSTR;
3) 使用Microsoft Visual C++进行编译时,将警告级别设置为3或更高,并将所有warnings当作errors处理;
4) 不要使用
#pragma once;作为包含保护,使用C++标准包含保护,包含保护的文件路径包含到项目树顶层(译者注,
#include<prj_name/public/tools.h>);
5) 除非万不得已,否则不使用任何不标准的扩展,如
#pragma和
__declspec,允许使用
__declspec(dllimport)和
__declspec(dllexport),但必须通过
DLLIMPORT和
DLLEXPORT等宏,以便其他人在共享使用这些代码时容易放弃这些扩展。
在Windows上,只有很少一些偶尔可以不遵守的规则:
1) 通常我们禁止使用多重继承,但在使用COM和ATL/WTL类时可以使用多重继承,为了执行COM或ATL/WTL类及其接口时可以使用多重实现继承;
2) 虽然代码中不应使用异常,但在ATL和部分STL(包括Visual
C++的STL)中异常被广泛使用,使用ATL时,应定义
_ATL_NO_EXCEPTIONS以屏蔽异常,你要研究一下是否也屏蔽掉STL的异常,如果不屏蔽,开启编译器异常也可以,注意这只是为了编译STL,自己仍然不要写含异常处理的代码;
3) 通常每个项目的每个源文件中都包含一个名为
StdAfx.h或
precompile.h的头文件方便头文件预编译,为了使代码方便与其他项目共享,避免显式包含此文件(
precompile.cc除外),使用编译器选项
/FI以自动包含;
4) 通常名为
resource.h、且只包含宏的资源头文件,不必拘泥于此风格指南。
团队合作
参考常识,保持一致。
编辑代码时,花点时间看看项目中的其他代码并确定其风格,如果其他代码
if语句中使用空格,那么你也要使用。如果其中的注释用星号(
*)围成一个盒子状,你也这样做:
/********************************** * Some comments are here. * There may be many lines. **********************************/
编程风格指南的使用要点在于提供一个公共的编码规范,所有人可以把精力集中在实现内容而不是表现形式上。我们给出了全局的风格规范,但局部的风格也很重要,如果你在一个文件中新加的代码和原有代码风格相去甚远的话,这就破坏了文件本身的整体美观也影响阅读,所以要尽量避免。
好了,关于编码风格写的差不多了,代码本身才是更有趣的,尽情享受吧!
翻议作者链接:http://www.cppblog.com/Fox/archive/2008/07/23/56933.html
相关文章推荐
- Google C++编程风格指南之代码注释
- Google C++Style Guide【C++编程风格指南解读】——命名约定
- Google C++编程风格指南(八):规则之例外
- Google C++编程风格指南(六):代码注释
- Google C++编程风格指南(四):智能指针和其他C++特性(转载)
- 我要精通C++——Google C++编程风格指南之命名约定
- Google C++Style Guide【C++编程风格指南解读】——C++特性
- Google C++编程风格指南(七):格式
- Google C++编程风格指南(五):命名约定(转载)
- [译]Google C++编程风格指南(五)
- google C++编程风格指南之头文件的包括顺序
- Google C++Style Guide【C++编程风格指南解读】——注释
- Google C++Style Guide【C++编程风格指南解读】——C++代码格式
- Google C++编程风格指南(八):规则之例外
- Google C++编程风格指南(七):格式(转载)
- [译]Google C++编程风格指南(六)
- Google C++编程风格指南
- Google C++编程风格指南
- Google C++编程风格指南(四):智能指针和其他C++特性
- Google C++编程风格指南(六):代码注释(转载)