微软Office的源代码样式规范(上) ―― 绝对机密文档！！！

Office Source Code Style Guide
Dave Parker, 6/30/95

Abstract
This document outlines a general style guide for C and C++ source code in Office Development.  The main purpose here is to list features of C++ which we will use and which we will avoid, along with the basic rationale for doing so.  There are also standards for basic coding issues for the sake of consistency within the code and robust constructs.  This is not a complete list of C/C++ language features with commentary.  Rather, it mentions only the issues we consider important.  Knowledge of C++ is assumed.
Contents
1. GENERAL GOALS 3
2. CLASSES 3
2.1 CLASS VS. STRUCT 4
2.2 PUBLIC, PRIVATE, AND PROTECTED MEMBERS 4
2.3 DATA MEMBERS 4
2.4 VIRTUAL FUNCTIONS 5
2.5 CONSTRUCTORS 5
2.6 DESTRUCTORS 6
2.7 NEW AND DELETE 7
2.8 OPERATORS 7
2.9 INHERITANCE 8
2.9.1 Inheritance of Interface vs. Implementation 8
2.9.2 Inheritance vs. Containment 10
2.9.3 Multiple Inheritance 11
3. OTHER C++ FEATURES 11
3.1 CONSTANTS AND ENUMERATIONS 12
3.2 REFERENCES 12
3.3 CONST PARAMETERS AND FUNCTIONS 13
3.4 DEFAULT ARGUMENTS 13
3.5 FUNCTION OVERLOADING 14
3.6 OPERATOR OVERLOADING 14
4. COMMON C/C++ ISSUES 14
4.1 #IFDEFS 14
4.2 GLOBAL VARIABLES 15
4.3 MACROS AND INLINE FUNCTIONS 16
4.4 OPTIMIZATION 16
4.5 WARNINGS 17
4.6 PRIVATE DATA AND FUNCTIONS 17
4.7 TYPEDEFS 17
4.8 BASIC DATA TYPES 17
4.9 POINTERS 18
4.10 SWITCH STATEMENTS 19
4.11 ASSERTS 19
4.12 ERRORS AND EXCEPTIONS 19
5. FORMATTING CONVENTIONS 20
5.1 NAMING CONVENTIONS 20
5.2 FUNCTION PROTOTYPES 21
5.3 VARIABLE DECLARATIONS 22
5.4 CLASS DECLARATIONS 22
5.5 COMMENTS 23
5.5.1 File Headers and Section Separators 23
5.5.2 Function Headers 24
5.5.3 In-Code Comments 25
5.5.4 Attention Markers 25
5.6 MISC. FORMATTING CONVENTIONS 26
5.7 SOURCE FILE ORGANIZATION 27
5.7.1 Public Interface Files 27
5.7.2 Private Interface Files 28
5.7.3 Implementation Files 28
5.7.4 Base Filenames 29
6. INTERFACES TO DLLS 29
6.1 C FUNCTIONS AND GLOBAL VARIABLES 29
6.2 COMMON C/C++ PUBLIC HEADER FILES 29
6.3 LIGHTWEIGHT COM OBJECTS AND ISIMPLEUNKNOWN 30
7. APPENDIX A: BASIC HUNGARIAN REFERENCE 33
7.1 MAKING HUNGARIAN NAMES 33
7.2 STANDARD BASE TAGS 33
7.3 STANDARD PREFIXES 34
7.4 STANDARD QUALIFIERS 35

 1. General Goals
C++ is a complex language that provides many ways to do things, and going ?whole hog” on all of its features can lead to confusion, inefficiency, or maintenance problems.  All Office developers need to become experts on the features we will use, and avoid the others in order to form solid conventions within the group that we are all comfortable with.  Our use of C++ features will be fairly conservative.  We?d much rather err on the side of just dealing with C, which we?re all used to, then screwing up our app with a new concept that not all of us are used to.
Underlying the choice of all of the style decisions are a few basic goals, as listed below.  When in doubt about a particular issue, always think about the spirit of these goals.  Sometimes these goals will conflict, of course, and in these cases we try to either prioritize the tradeoffs or use experience (either our own or from other groups that have used C++ extensively).
1. Simplicity.  When in doubt, keep it simple.  Bugs are related mostly to complexity, not code.
2. Clarity.  The code should do what it looks like it?s doing.  Other people need to be able to understand your code.
3. Efficiency.  Speed and size are important.  Using C++ does not imply big and slow.  There are plenty of perfectly reasonable ways to make things as fast or faster than the normal C way.  Speed and size often trade off, and most people probably err on the side of choosing speed too often.  Remember that 20% of the code is responsible for 80% of the time.  In most cases, we?re more concerned about fitting comfortably in less RAM.
4. Appropriateness.  Use the language construct that is appropriate for the abstraction or operation you are trying to do.  Do not abuse the language.  Don?t use a construct just because it happens to work.  Definitely don?t use a strange construct to amaze and confuse your friends to try to show how smart you are.
5. Natural transition from C to C++.  We all used to be C programmers.  Others that look at our code are still C programmers (e.g. Word and Excel).  When possible, avoid C++ constructs where a C programmer?s instinct causes a wrong assumption.
6. Catch Errors Early.  Having the compiler catch an error is ideal.  Having debug code (e.g. Asserts) catch it is the next best thing, etc.  Declare things in such as way as to give the compiler the best chance at catching errors.
7. Fast builds.  Total generality and modularity can cause lots of inter-dependencies between files, which can have a dramatic impact on build times.  This is a constant time sink for everyone.  It is often worth rearranging things a little to make incremental builds faster.
8. Consistency.  The whole point of having a style guide is that programmers are never totally autonomous, even when the group has strong code ownership.  Other people need to read and understand your code.  Everyone has t