前面说明的编程习惯基本都是强制性的. 但所有优秀的规则都允许例外, 这里就是探讨这些特例.
总述
对于现有不符合既定编程风格的代码可以网开一面.
说明
当你修改使用其他风格的代码时, 为了与代码原有风格保持一致可以不使用本指南约定. 如果不放心, 可以与代码原作者或现在的负责人员商讨. 记住, 一致性 也包括原有的一致性.
总述
Windows 程序员有自己的编程习惯, 主要源于 Windows 头文件和其它 Microsoft 代码. 我们希望任何人都可以顺利读懂你的代码, 所以针对所有平台的 C++ 编程只给出一个单独的指南.
说明
如果你习惯使用 Windows 编码风格, 这儿有必要重申一下某些你可能会忘记的指南:
iNum
). 使用 Google 命名约定, 包括对源文件使用 .cc
扩展名.DWORD
, HANDLE
等等. 在调用 Windows API 时这是完全可以接受甚至鼓励的. 即使如此, 还是尽量使用原有的 C++ 类型, 例如使用 const TCHAR *
而不是 LPCTSTR
.#pragma once
; 而应该使用 Google 的头文件保护规则. 头文件保护的路径应该相对于项目根目录 (Yang.Y 注: 如 #ifndef SRC_DIR_BAR_H_
, 参考 #define 保护 一节).#pragma
和 __declspec
. 使用 __declspec(dllimport)
和 __declspec(dllexport)
是允许的, 但必须通过宏来使用, 比如 DLLIMPORT
和 DLLEXPORT
, 这样其他人在分享使用这些代码时可以很容易地禁用这些扩展.然而, 在 Windows 上仍然有一些我们偶尔需要违反的规则:
_ATL_NO_EXCEPTIONS
以禁用异常. 你需要研究一下是否能够禁用 STL 的异常, 如果无法禁用, 可以启用编译器异常. (注意这只是为了编译 STL, 自己的代码里仍然不应当包含异常处理).StdAfx.h
或 precompile.h
的文件. 为了使代码方便与其他项目共享, 请避免显式包含此文件 (除了在 precompile.cc
中), 使用 /FI
编译器选项以自动包含该文件.resource.h
且只包含宏, 这一文件不需要遵守本风格指南.Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8