编程风格指南的使用要点在于提供一个公共的编码规范,所有人可以把精力集中在实现内容而不是表现形式上。我们给出了全局的风格规范,但局部的风格也很重要,如果你在一个文件中新加的代码和原有代码风格相去甚远的话,这就破坏了文件本身的整体美观也影响阅读
- 规则之例外
前面说明的编码习惯基本是强制性的,但所有优秀的规则都允许例外。
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.
**********************************/
编程风格指南的使用要点在于提供一个公共的编码规范,所有人可以把精力集中在实现内容而不是表现形式上。我们给出了全局的风格规范,但局部的风格也 很重要,如果你在一个文件中新加的代码和原有代码风格相去甚远的话,这就破坏了文件本身的整体美观也影响阅读,所以要尽量避免。
好了,关于编码风格写的差不多了,代码本身才是更有趣的,尽情享受吧!
Benjy Weinberger
Craig Silverstein
Gregory Eitzmann
Mark Mentovai
Tashana Landray