📄 csdn_文档中心_微软office的源代码样式规范(上) —— 绝对机密文档！！！.htm
字号:
<TD align=middle bgColor=#003399 height=10><FONT
color=#ffffff>标题</FONT></TD>
<TD><B> 微软Office的源代码样式规范(上) ——
绝对机密文档！！！</B> silver（收藏） </TD></TR>
<TR>
<TD align=middle height=5></TD>
<TD align=middle width=500></TD></TR>
<TR>
<TD align=middle bgColor=#003399><FONT color=#ffffff>关键字</FONT></TD>
<TD width=500> 微软Office的源代码样式规范(上) ——
绝对机密文档！！！</TD></TR>
<TR>
<TD align=middle height=5></TD>
<TD align=middle width=500></TD></TR></TBODY></TABLE><!--文章说明信息结束//-->
<TABLE border=0 width=600>
<TBODY>
<TR>
<TD align=left><BR>
<P align=center><FONT size=5><STRONG>Office Source Code Style
Guide</STRONG></FONT><BR>Dave Parker, 6/30/95</P>
<P>Abstract<BR>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.<BR>Contents<BR>1. GENERAL GOALS 3<BR>2.
CLASSES 3<BR>2.1 CLASS VS. STRUCT 4<BR>2.2 PUBLIC,
PRIVATE, AND PROTECTED MEMBERS 4<BR>2.3 DATA
MEMBERS 4<BR>2.4 VIRTUAL FUNCTIONS 5<BR>2.5
CONSTRUCTORS 5<BR>2.6 DESTRUCTORS 6<BR>2.7 NEW AND
DELETE 7<BR>2.8 OPERATORS 7<BR>2.9
INHERITANCE 8<BR>2.9.1 Inheritance of Interface vs.
Implementation 8<BR>2.9.2 Inheritance vs.
Containment 10<BR>2.9.3 Multiple Inheritance 11<BR>3.
OTHER C++ FEATURES 11<BR>3.1 CONSTANTS AND
ENUMERATIONS 12<BR>3.2 REFERENCES 12<BR>3.3 CONST
PARAMETERS AND FUNCTIONS 13<BR>3.4 DEFAULT
ARGUMENTS 13<BR>3.5 FUNCTION OVERLOADING 14<BR>3.6
OPERATOR OVERLOADING 14<BR>4. COMMON C/C++
ISSUES 14<BR>4.1 #IFDEFS 14<BR>4.2 GLOBAL
VARIABLES 15<BR>4.3 MACROS AND INLINE FUNCTIONS 16<BR>4.4
OPTIMIZATION 16<BR>4.5 WARNINGS 17<BR>4.6 PRIVATE DATA AND
FUNCTIONS 17<BR>4.7 TYPEDEFS 17<BR>4.8 BASIC DATA
TYPES 17<BR>4.9 POINTERS 18<BR>4.10 SWITCH
STATEMENTS 19<BR>4.11 ASSERTS 19<BR>4.12 ERRORS AND
EXCEPTIONS 19<BR>5. FORMATTING CONVENTIONS 20<BR>5.1
NAMING CONVENTIONS 20<BR>5.2 FUNCTION PROTOTYPES 21<BR>5.3
VARIABLE DECLARATIONS 22<BR>5.4 CLASS
DECLARATIONS 22<BR>5.5 COMMENTS 23<BR>5.5.1 File Headers
and Section Separators 23<BR>5.5.2 Function
Headers 24<BR>5.5.3 In-Code Comments 25<BR>5.5.4 Attention
Markers 25<BR>5.6 MISC. FORMATTING CONVENTIONS 26<BR>5.7
SOURCE FILE ORGANIZATION 27<BR>5.7.1 Public Interface
Files 27<BR>5.7.2 Private Interface Files 28<BR>5.7.3
Implementation Files 28<BR>5.7.4 Base Filenames 29<BR>6.
INTERFACES TO DLLS 29<BR>6.1 C FUNCTIONS AND GLOBAL
VARIABLES 29<BR>6.2 COMMON C/C++ PUBLIC HEADER
FILES 29<BR>6.3 LIGHTWEIGHT COM OBJECTS AND
ISIMPLEUNKNOWN 30<BR>7. APPENDIX A: BASIC HUNGARIAN
REFERENCE 33<BR>7.1 MAKING HUNGARIAN NAMES 33<BR>7.2
STANDARD BASE TAGS 33<BR>7.3 STANDARD PREFIXES 34<BR>7.4
STANDARD QUALIFIERS 35</P>
<P> 1. General Goals<BR>C++ is a complex language that provides
many ways to do things, and going 搘hole 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抎 much rather err on
the side of just dealing with C, which we抮e all used to, then
screwing up our app with a new concept that not all of us are used
to.<BR>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).<BR>1. Simplicity. When in doubt, keep it
simple. Bugs are related mostly to complexity, not
code.<BR>2. Clarity. The code should do what it looks
like it抯 doing. Other people need to be able to understand
your code.<BR>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抮e more concerned about fitting
comfortably in less RAM.<BR>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抰 use a construct just because it happens to
work. Definitely don抰 use a strange construct to amaze and
confuse your friends to try to show how smart you
are.<BR>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抯 instinct causes a wrong
assumption.<BR>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.<BR>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.<BR>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 to give a little
to have a consistent style guide, but everyone gains it back when
they read or debug other people抯 code.<BR>2. Classes <BR>C++ classes
are a nice way to encapsulate code and data into a single unit,
which provides a good paradigm for object-oriented implementations
as well other features such as flexible access control, convenient
and type-safe polymorphism, and the possibility of code reuse via
inheritance.<BR>At the most general, classes are an extension to the
built-in typing of C which allows you to define your own types along
with the operations on that type. Taken to the extreme, every
piece of data in a program could be an instance of a class.
However, we will not go nearly this far in Office. We will use
classes when there is a good reason to, such as the concept being
implemented is inherently object-oriented or polymorphism is
required. It has been the experience of many people that
programs that use classes for everything evolve into systems that
are complex and inefficient. Although this may not be the
fault of any particular class, complex class hierarchies can lead to
needless complexity, and overly abstracted concepts can easily lead
to inefficiency.<BR>In general, we will avoid allocating classes on
the stack and passing classes by value, because this is where the
use of constructors and destructors gets you into the most
trouble. Most classes should be allocated via new, freed by
delete, and passed by pointer. In addition, we will never
declare a global variable which is an instance of a class that has a
constructor, because this causes a bunch of C runtime stuff to get
linked in and stuff to happen at boot time to construct the thing,
which is a big performance hit. Using only heap-allocated
classes implies we抣l probably use classes only for relatively
complex objects that you would normally have in the heap anyway, not
simple things like basic data types. Beyond this, it is a
judgment call when to use a class. Use one if there is a good
reason, but not if a more straightforward solution is just as
good.<BR>Summary:<BR> Use classes to encapsulate the implementation
of an object-oriented concept.<BR> Use classes to implement
polymorphism.<BR> Avoid allocating class instances on the stack and
passing them by value. Use new and delete, and pass them by
pointer. This implies not using classes for simple data
types.<BR> Never declare a global instance of a class that has a
constructor.<BR> Not everything is as class. Use them only
when you gain something.<BR>2.1 Class vs. Struct<BR>In C++, a struct
can also have member functions and operators and everything else
that a class can have. In fact, the only difference between a
class and a struct is that all members default to public access in a
struct but private access in a class. However, we will not use
this as the deciding point between using a class vs. a struct.
To match the normal intuition, we will use a class if and only if
there are member functions included.<BR>Summary:<BR> Use a class
instead of a struct if and only if there are member
functions.<BR>2.2 Public, Private, and Protected members<BR>As
stated above, structs default to public access and classes default
to private access. However, we will depend on the default only
in the case of structs (where we leave all the data implicitly
public). For a class, we will declare all members (both data
and code) explicitly as public, protected, or private, and group
them into sections in that order. For example:<BR>class
Foo<BR> {<BR>public:<BR> Foo();<BR> ~Foo();<BR> void
Hey(int I);<BR> void Ack();<BR>protected:<BR> int
m_iValue;<BR>private:<BR> int m_iStuff;<BR> void
LocalHelperSub();<BR> };</P>
<P>Summary:<BR> Declare all class members explicitly as public,
protected, or private, in groups in that order.<BR>2.3 Data
Members<BR>Data members should use the naming convention m_name
where name is a normal Hungarian local variable name. This
makes member function implementations easier to read (no confusion
about member vs. local data), and allows the use of the same
Hungarian name for, e.g., parameters and members. See the
example below.<BR>Data members should normally not be declared
public because this usually defeats the purpose of the class
abstraction. To efficiently export a data member, declare
inline get and set member functions. This will get optimized
into the same code as a public data member. For
example:<BR>class Counter<BR> {<BR>public:<BR> int
CItems() const { return m_cItems; }<BR> void SetCItems(int
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -