C++ style guide - Revision history

Gongminmin at 03:51, 14 December 2015

2015-12-14T03:51:09Z

Gongminmin at 03:50, 14 December 2015

2015-12-14T03:50:44Z

Gongminmin: /* Declaration Order */

2012-06-10T07:29:28Z

‎Declaration Order

Gongminmin: /* Access Control */

2012-06-10T07:12:04Z

‎Access Control

Gongminmin at 07:11, 10 June 2012

2012-06-10T07:11:06Z

Gongminmin: /* Operator Overloading */

2012-06-09T08:36:56Z

‎Operator Overloading

Gongminmin at 14:57, 14 May 2012

2012-05-14T14:57:36Z

Gongminmin: /* Static and Global Variables */

2012-05-13T15:05:13Z

‎Static and Global Variables

Gongminmin: /* Nonmember, Static Member, and Global Functions */

2012-05-09T15:00:29Z

‎Nonmember, Static Member, and Global Functions

Gongminmin: /* Scoping */

2012-05-08T14:37:38Z

‎Scoping

@@ Line 1,957: / Line 1,957: @@
 Things to note:
-*Any base class name should be on the same line as the subclass name, subject to the 80-column limit.
+*Any base class name should be on the same line as the subclass name, subject to the 140-column limit.
 *The public:, protected:, and private: keywords should not be indented.
 *Except for the first instance, these keywords should be preceded by a blank line. This rule is optional in small classes.

@@ Line 1,540: / Line 1,540: @@
 == Line Length ==
-Each line of text in your code should be at most 80 characters long.
+Each line of text in your code should be at most 140 characters long.
-We recognize that this rule is controversial, but so much existing code already adheres to it, and we feel that consistency is important.
+Exception: if a comment line contains an example command or a literal URL longer than 140 characters, that line may be longer than 140 characters for ease of cut and paste.
-'''Pros:'''
+Exception: an #include statement with a long path may exceed 140 columns. Try to avoid situations where this becomes necessary.
-Those who favor this rule argue that it is rude to force them to resize their windows and there is no need for anything longer. Some folks are used to having several code windows side-by-side, and thus don't have room to widen their windows in any case. People set up their work environment assuming a particular maximum window width, and 80 columns has been the traditional standard. Why change it?
-−
-'''Cons:'''
-Proponents of change argue that a wider line can make code more readable. The 80-column limit is an hidebound throwback to 1960s mainframes; modern equipment has wide screens that can easily show longer lines.
-−
-'''Decision:'''
-characters is the maximum.
-−
-Exception: if a comment line contains an example command or a literal URL longer than 80 characters, that line may be longer than 80 characters for ease of cut and paste.
-−
-Exception: an #include statement with a long path may exceed 80 columns. Try to avoid situations where this becomes necessary.
 Exception: you needn't be concerned about header guards that exceed the maximum length.

@@ Line 646: / Line 646: @@
 Method definitions in the corresponding .cpp file should be the same as the declaration order, as much as possible.
-Do not put large method definitions inline in the class definition. Usually, only trivial or performance-critical, and very short, methods may be defined inline. See C++ style guide#Inline Functions|Inline Functions]] for more details.
+Do not put large method definitions inline in the class definition. Usually, only trivial or performance-critical, and very short, methods may be defined inline. See [[#Inline Functions|Inline Functions]] for more details.
 = Write Short Functions =

@@ Line 621: / Line 621: @@
 == Access Control ==
-Make data members private, and provide access to them through accessor functions as needed. Typically a variable would be called foo_ and the accessor function Foo(). You may also want a mutator function Foo(). Exception: static const data members (typically called Foo) need not be private.
+Make data members private, and provide access to them through accessor functions as needed. Typically a variable would be called foo_ and the accessor function Foo(). You may also want a mutator function Foo(). Exception: static const data members (typically called FOO) need not be private.
 The definitions of accessors are usually inlined in the header file.

@@ Line 621: / Line 621: @@
 == Access Control ==
-Make data members private, and provide access to them through accessor functions as needed. Typically a variable would be called foo_ and the accessor function foo(). You may also want a mutator function set_foo(). Exception: static const data members (typically called Foo) need not be private.
+Make data members private, and provide access to them through accessor functions as needed. Typically a variable would be called foo_ and the accessor function Foo(). You may also want a mutator function Foo(). Exception: static const data members (typically called Foo) need not be private.
 The definitions of accessors are usually inlined in the header file.

@@ Line 613: / Line 613: @@
 In general, do not overload operators. The assignment operator (operator=), in particular, is insidious and should be avoided. You can define functions like Equals() and CopyFrom() if you need them. Likewise, avoid the dangerous unary operator& at all costs, if there's any possibility the class might be forward-declared.
-However, there may be rare cases where you need to overload an operator to interoperate with templates or "standard" C++ classes (such as operator<<(ostream&, const T&) for logging). These are acceptable if fully justified, but you should try to avoid these whenever possible. In particular, do not overload operator== or operator< just so that your class can be used as a key in an STL container; instead, you should create equality and comparison functor types when declaring the container.
+However, there may be rare cases where you need to overload an operator to interoperate with templates or "standard" C++ classes (such as operator<<(ostream&, T const &) for logging). These are acceptable if fully justified, but you should try to avoid these whenever possible. In particular, do not overload operator== or operator< just so that your class can be used as a key in an STL container; instead, you should create equality and comparison functor types when declaring the container.
 Some of the STL algorithms do require you to overload operator==, and you may do so in these cases, provided you document why.

@@ Line 409: / Line 409: @@
 The problems with doing work in constructors are:
-*There is no easy way for constructors to signal errors, short of using exceptions (which are forbidden).
+*There is no easy way for constructors to signal errors, short of using exceptions.
 *If the work fails, we now have an object whose initialization code failed, so it may be an indeterminate state.
 *If the work calls virtual functions, these calls will not get dispatched to the subclass implementations. Future modification to your class can quietly introduce this problem even if your class is not currently subclassed, causing much confusion.

@@ Line 385: / Line 385: @@
 Likewise, the order in which destructors are called is defined to be the reverse of the order in which the constructors were called. Since constructor order is indeterminate, so is destructor order. For example, at program-end time a static variable might have been destroyed, but code still running -- perhaps in another thread -- tries to access it and fails. Or the destructor for a static 'string' variable might be run prior to the destructor for another variable that contains a reference to that string.
-As a result we only allow static variables to contain POD data. This rule completely disallows vector (use C arrays instead), or string (use const char []).
+As a result we only allow static variables to contain POD data. This rule completely disallows vector (use C arrays instead), or string (use char const []).
 If you need a static or global variable of a class type, consider initializing a pointer (which will never be freed), from either your main() function or from pthread_once(). Note that this must be a raw pointer, not a "smart" pointer, since the smart pointer's destructor will have the order-of-destructor issue that we are trying to avoid.

@@ Line 327: / Line 327: @@
 Functions defined in the same compilation unit as production classes may introduce unnecessary coupling and link-time dependencies when directly called from other compilation units; static member functions are particularly susceptible to this. Consider extracting a new class, or placing the functions in a namespace possibly in a separate library.
-If you must define a nonmember function and it is only needed in its .cpp file, use an unnamed namespace or static linkage (eg static int Foo() {...}) to limit its scope.
+If you must define a nonmember function and it is only needed in its .cpp file, use an unnamed namespace to limit its scope.
 == Local Variables ==

@@ Line 228: / Line 228: @@
 namespace b
+{
-	...code for b...	// Code goes against the left margin.
+	...code for b...
+}
 </pre>
@@ Line 272: / Line 272: @@
 		...
+	}
-}  // namespace librarian
 </pre>