...
- #Classes
Encapsulate code within classes, factor the code, and make it easy to understand.Anchor Classes Classes - #Accessors
Use public accessor functions for instance variables accessed outside the class.Anchor Accessors Accessors - #Arrays
Use arrays with abstraction supporting range checks.Anchor Arrays Arrays - #Switches
Always enumerate all cases in a switch statement or specify default case. It is ok to have an empty default with comment.Anchor Switches Switches - #Asserts
UseAnchor Asserts Asserts assert(...)
,guarantee(...)
,ShouldNotReachHere()
,Unimplemented()
and comments wherever needed. (Performance is almost never a reason to omit asserts.) - #SimpleC
Use single inheritance, no operator overloading, no C++ exception handling, and no goto statements. (There are a few uses of operator overloading, but these should be rare cases.) Be sparing with templates. Use only C++ features which will work correctly on all of our platforms.Anchor SimpleC SimpleC - #NamedCons
Assign names to constant literals and use the names instead. Use enum to name integer constants inside class definitions.Anchor NamedCons NamedCons - #Booleans
UseAnchor Booleans Booleans bool
for booleans (not int), usetrue
&false
(not 1 & 0); useNULL
for pointers (not 0). - #Names
Instance variable names start with underscore "_", classes start with upper case letter, local functions are all lower case, all must have meaningful names.Anchor Names Names - #Ifdefs
Ifdefs should not be used to introduce platform-specific code into shared code (except forAnchor Ifdefs Ifdefs LP64
). They must be used to manage header files, in the pattern found at the top of every source file. They should be used mainly for major build features, includingPRODUCT
,ASSERT
,_LP64
,SERIALGC
,COMPILER1
, etc.
...
- Type names and global names are mixed-case (
FooBar
). - Local names (fields, variables) and function names are lower-case (
foo_bar
). (For these, avoid mixing in upper case letters.) - Constant names in upper-case or mixed-case are tolerated, according to historical necessity.
- Constant names should follow an existing pattern, and must have a distinct appearance from other names in related APIs.
- Inside class definitions, integer constants can be defined with "
static const
". (Historically, enums have been also been used.)
- Inside class definitions, integer constants can be defined with "
- Class and type names are noun phrases. Consider an "er" suffix for a class that represents an action.
- Getter accessor names are noun phrases, with no "
get_
" noise word. Boolean getters can also begin with "is_
" or "has_
". - Setter accessor names prepend "
set_
" to the getter name. - Other method names are verb phrases, as if commands to the receiver.
- Avoid leading underscores (as "
_oop
") except in cases required above. (Names with leading underscores can cause portability problems.)
...
Overview
Content Tools
ThemeBuilder