C++ and Perl Guidelines -- Notes on using C++ and Perl from Road Intranet

This document records guidelines for using C++ and Perl. Many guidelines apply to C# and Java programming. Some guidelines are specific to C#. The primary references are Framework Design Guidelines Effective C++ , and Perl Best Practices . The primary model is Nokia's Qt framework. Please send comments and suggestions to bradb@shore.net

Help

C++ In a Nutshell [liscR_2003] -- Concise and complete description of C++.
cplusplus.com -- The C++ Resources Network with documentation, tutorials, forums, and source code.
CodeIdol -- free, on-line books on coding and IT
Stackoverflow -- free, expert advice on programming
Apache C++ Standard Library (guide, classes) -- Fully documented, standards-compliant STL.

Developer Resources

Microsoft MSDN
Java2s -- Extensive collection of simple, example code using Java, C++, XML, etc. Separate sections for tutorial code.
Accessibility Designer

Tables

ASCII, Unicode, Character code -- character tables.

C++ usage

Geotechnical's C++ Programming Style Guidelines
Henricson and Nyquist's Industrial Strength C++ -- with rules and recommendations (1997)
Mozilla's C++ Portability Guide
Open Directory (DMOZ) for C++ Style
Todd Hoff's C++ Coding Standard -- with wikis on Agile Programming, Code Reviews, Software Development and Test Driven Development.
Uwyn's C++ Coding Standard (2002)
Wikibook's C++ programming conventions, idioms, and more idioms
Wikipedia's Design Patterns, Programming Style

Established programming languages such as C++ and Perl offer a wealth of choices for expressing your code. Reading the manual is not enough. These guidelines and books will help you develop a good programming style.

A good programming style improves the robustness, efficiency, and maintainability of your code. It reduces the cost of your software by reducing the number of bugs in your programs, increasing its efficiency, and making the code comprehensible. A good programming style conveys your intentions clearly; it is neither clever nor obtuse. .
"Program in the future tense " -- "Good software adapts well to change. ... To program in the future tense is to accept that things will change and to be prepared for it." .
Use a revision control system -- Software changes frequently and is defined by many files. Changes in one file often need corresponding changes to other files. Use a revision control system to keep track of these changes . Be rigorous about the configuration of test and deployed software. Integrate your bug tracking and revision control systems. Know what source changes fixed a bug. For each source directory, know what bugs were fixed by changes within that source directory.
Use 3-part version numbers -- Have a standard for version numbers. You need at least three fields: major, minor, and release. Have a convention for developer releases . Perforce uses year.version.changelistnumber (e.g., 2007.2/122958).
"Well-designed frameworks are consistent" -- A consistent framework allows you to understand all of the framework after you understand a piece of the framework. Consistent interfaces are easy to use correctly ; inconsistent interfaces are aggravating .
"Make interfaces easy to use correctly and hard to use incorrectly" -- Design your API for ease of use. "When in doubt do as the ints do." Be leery of complex usage rules. For example, return smart pointers for automatic delete. Use a Month class instead of int .
"Most importantly, try thinking of a program as a set of interacting concepts represented as classes and objects, instead of the program as a bunch of data structures with functions twiddling their bits." .
Encapsulation allows change -- "If something is encapsulated, it is hidden from view. ... The fewer things can see it, the greater flexibility we have to change it. ... count the number of functions that can access [a piece] of data." .
Dependency Inversion Principle -- "High-level modules should not depend upon low-level modules. Rather, both should depend upon abstractions. Abstractions should not depend upon details. Rather, details should depend upon abstractions." With fewer, more stable dependencies, applications are easier to change and enhance .
Declarations should depend on declarations, not definitions -- Reduce dependencies between modules by depending on class declarations instead of class definitions
- Forward declaration -- When practical, use forward declarations of a class. Forward declarations work for references, pointers, pass by value, and return by value. A forward declaration of a nested class needs public accessibility.
- Opaque type -- Replace data members with a private, opaque types.
- Declaration-only -- Consider using a declaration-only header file (e.g., STL's <iosfwd>) .
Avoid cut-and-paste, do not repeat yourself -- If you want to cut-and-paste code within a file, define a subroutine instead. If you want to cut-and-paste subroutines between files, define a class or module instead . Use cut-and-paste to copy templates and other structures that should be used consistently across files. Be particularly careful of changes to cut-and-pasted code. It is easy to make an inconsistent change that appears to work OK.
Flexibility via indirection -- "Almost all flexibility in software comes with an extra layer of indirection (arrays, dynamic data structures, recursion, and so on). Not surprisingly, dynamic binding also depends on an extra layer of indirection."

C++ is a federation of languages -- C++ combines multiple languages with different rules and conventions
.
- C -- The language C is the programming language underlying C++
- Object-oriented C++ -- C++ extends C with classes, constructors, destructors, inheritance, function overloading, and dynamic binding.
- Template C++ -- Templates allow compile time instantiation of classes and methods by type name. Template metaprogramming supports compile-time execution. Generic algorithms may be written with templates.
- Framework C++ -- A framework provides a library of useful classes, templates, and generic algorithms. The best known library is the STL (Standard Template Library). The Qt libraries implement implicitly shared objects and Java-style iterators. Many of the recipes in Stephens, et. al..'s C++ Cookbook (O'Reilly, 2006) are more clearly expressed in Qt.
Declaration -- "A declaration is the all-encompassing term for anything that tells the compiler about an identifier. ... a declaration tells you an entity's name and the external view of an entity, such as an object's type or a function's parameter"
.
- Specifiers -- List storage class first (e.g., extern, mutable, static), then type specifiers (e.g., int), followed by cv-qualifiers (const, volatile). Each level of pointer may have cv-qualifiers. .
- Function pointer -- Use a typedef when declaring a function pointer For example, typedef void (*MyFunction)(int); defines a one argument function returning an int. Then declare the function pointer with MyFunction fp; .
Definition -- "A definition defines the storage, value, body, or contents of a declaration. ... a definition provides the internal workings of the entity: the storage and initial value of an object, a function body, and so on." . Do not define objects in header files at namespace-level. Use 'extern' and declarations instead .
Scope -- "A scope is a region of source code that contains declarations. ... you can think of a scope as a dictionary of names mapped to declarations." .
Name Lookup -- For the rules used to associate declarations with names see .
Policy -- For templates, a policy customizes the behavior of the template. It is itself a template , . For an example, see Stephens, et. al., C++ Cookbook (5-10.hpp)
POD Type -- "POD is short for Plain Old Data. The fundamental types and enumerated types are POD types, as are pointers and arrays of POD types." A POD class, struct, or union uses only POD types for nonstatic data. POD types are invariant under memcpy. By default, non-static POD types are uninitialized .
Sequence point -- "Between sequence points, the compiler is free to reorder expressions in any way that preserves the original semantics." Only access global and volatile objects immediately after a sequence point. Between sequence points, do not modify or access an object after modifying the object (e.g., f(i++, i++)). A sequence point occurs "at the end of every expression that is not a subexpression," after evaluating all of a function's arguments, and after copying a function's return value .
Traits -- For templates, a traits template or class defines tag structs and typedefs to describe iterators, character classes, and built-in types , .

The STL and other libraries use templates to define generic algorithms. For introduction to algorithms and their unifying principles see .

Algorithms are defined on iterators and ranges -- Generic algorithms are defined in terms of iterators and iterator operations. They do not themselves execute container operations. "In general, the generic algorithms operate on iterator pairs that denote a range of elements in a container (or other sequence)." .
"Use a checked STL implementation" -- Generic algorithms do not check their arguments. Iterators may be out-of-bounds. Iterator ranges may be inverted or refer to unrelated containers. A checked STL library will catch these and other errors .
Use pure functions for predicates -- Predicates used by algorithm must be pure functions. They always return the same value for the same arguments. An algorithm may invoke predicates in any order multiple times. The algorithm may break mysteriously if predicates return different results for the same argument .

Design a framework from a set of usage scenarios and code samples. The basic scenarios are most important. What can be done without documentation?

See also

Global data -- Avoid globally defined objects and variables. Limit the use of static variables that are global to a class. A global variable is an implicit argument to every method that uses it. Globals reduce reuse since all users must be packaged together .
"Declare data members private" -- Everything in the public interface should be a function. It keeps the interface consistent and flexible. "It makes it easy to notify other objects when data members are read or written, to verify class invariants and function pre- and post-conditions, to perform synchronization in threaded environments, etc." If you eliminate a public or protected data member an unknowable amount of code may be broken , .
Union type -- "An object of union type has enough memory to store the largest member, and all data members share that memory. ... It is your responsibility to keep track of which data member is "active." Use an anonymous union for simplified access to union members .
Const vs. mutable -- Do not assign arrays, collections, and other mutable types to const or readonly fields. Otherwise the elements of the field can be modified
Unsigned bit field -- A bit field is "a sequence of bits packed into an object. Use 'signed' or 'unsigned' on 'int' bit fields, otherwise the value is undefined .
Public static readonly -- In C#, Use static readonly fields for predefined objects .

assert -- Use assert() liberally to document internal assumptions and invariants. For boolean asserts, add && "informative message" to describe the failure .
Custom assert -- Define your own assert for greater control over invariant testing. include a level parameter to reduce the amount of assert testing in production code .
autoexp.dat -- In DevStudio, use autoexp.dat to define rules for displaying variables in native code. This file is in
```
 Program Files\Microsoft Visual Studio 8\Common7\Packages\Debugger
```
For more control over displaying data see "EEAddIn" in the DevStudio documentation.
endl -- When writing diagnostic output, end lines with '<< endl' instead of '\n', The former writes a new line and flushes the buffer. Alternatively use '<< flush'. Without 'endl' or 'flush' the last lines of output may not appear after a program crash. . If using Qt, distinguish between STL's endl and Qt's endl.
if(DEBUG) -- Use conditional expressions instead of #if for debugging code. The compiler checks both versions of the code, and eliminates the unexecuted branch .
ToString -- C# displays the ToString() value of an object if it is available. It should be unique, readable, developer-appropriate. Ideally, parsing the ToString() should recreate the object .
LogEntry() -- Define a log entry class whose constructor starts the log and whose destructor stops the log entry .

User vs. technical documentation -- Do not include implementation details in user documentation. Tell the user what the code does, not how it does it .
Place user documentation in the source files -- If user documentation is in the source files, it is easier to maintain and keep up-to-date. .
Define templates for user documentation -- Define and use templates for documenting each type of module. It helps the reader understand a module. The writer does not worry about organization. .

Flexibility is expensive -- "In the last ten years we have encountered quite a few C++ projects that fell far short of their required performance. At the heart of those performance failures was a design and an implementation geared for extreme flexibility and reusability. The obsession with reusable code has produced software that, due to the lack of efficiency, was not even usable, not to mention reusable. ... The problem is that performance and flexibility are often enemies." .
Limit use of inline functions -- An inline function is either declared 'inline' or defined within a class. It may define static objects. An inline function requires recompilation on any change. "Limit most inlining to small, frequently called functions" . Do not inline constructors and destructors. It breaks binary compatibility [].
Inlining is faster -- "Inlining is probably the most significant mechanical performance enhancement technique available in C++." For example, inlining the obvious candidates of a 10,000 line subsystem improved performance by 40%. If inline candidates are assigned to a ".inl" file, the preprocessor can selectively include the file in the corresponding .h or .cpp file .
Constructors are expensive -- Creating and destroying objects is expensive. For example removing three unnecessary std::string creates from a logging class reduced response time from 2,500 ms to 185 ms. When practical, embed an object instead of an object pointer. This saves a heap allocation and deallocation. Use a free list to recycle objects. .
Temporaries are expensive -- Temporary objects must be created and destroyed. For example, a Complex expression i*b + 1.0 is faster if 1.0 is replaced with a predefined Complex one(1.0). Defining std::string s3=s1+s2 avoids the temporary created for s3=s1+s2. Mutators avoid temporaries (e.g., s3=s1; s3+=s2) .
Object vectors are expensive -- A vector of BigInt objects is 18 times more expensive than a vector of integers. If vectors are frequently manipulated consider using a vector of pointers instead. .
Vector traversal is fast -- Traversing a vector from beginning to end is fast. For example, summing the elements of a vector with std::accumulate is 23 times faster than summing a list. List traversal ignores the memory cache. .
Inheritance is expensive -- Inheritance adds a level of indirection to function calls. For example, a standalone object for SimpleMutex cost the same as a hand-code implementation. All calls were inlined. A simple inheritance-based lock object with a virtual destructor degraded performance about 60% .
Know the memory hierarchy -- Registers have much more bandwidth than the level-1 cache. The level-1 cache is faster than the level-2 cache. The level-2 cache is much faster than main memory. Accessing data in the same cache line is faster than accessing data in many cache lines. Disk access is incredibly slow, except for bulk data from contiguous sectors. Non-resident virtual memory is disk. .
Straight-line code is fast -- "The fastest code is straight line code: no conditional tests, no loops, no calls, no returns. In general, the more the critical path of a program looks like a straight line, the faster it will execute."
Argument checking is slow -- Sanity-checking of arguments involves lots of branches. Keep argument checking out of the critical path. Avoid redundant checks.
Avoid context switches -- A context switch is expensive. The processor must save its state and execute the scheduler. The cache and TLB are likely to be stale when the process returns. A context switch can cost thousands of cycles. Multithreaded processor architectures can make context switches for free, but they do not avoid the problem of stale cache lines and TLB misses.
return-value optimization (RVO) -- If a returned value is constructed, a compiler may construct the result into the destination object . The class must define a copy constructor . If a function can create more than one object (e.g., a default initializer for the NULL case), return-value optimization is usually disabled.
RTTI is expensive -- Run-time type information and dynamic casts are expensive . In Qt, use QMetaObject instead.
Precompute data -- Precomputed lookup tables moves computation from the performance-critical path to initialization. For example, replace calls to tolower, islower, isspace, and isdigit with tables. .
Split up shared resources -- Reduce synchronization costs by defining multiple resource pools with independent locks .
Avoid false sharing of the data cache -- In multi-processor systems, the data cache is an important resource. When data is modified by the same process, keep it together. When data is modified by multiple processes, separate the data. For example, if two locks are only eight bytes part, each access may invalidate the whole cache line .
Wakeup a single thread -- When a lock is released, prefer waking up a single thread. Otherwise all threads will wake up, even though only one thread will succeed .

Events are callbacks into user code. When an event is raised, the user-supplied event handler is called. Instead of calling the event handler immediately, the event may be posted to an event queue. In Qt, an event handler is called a "slot" and an event is called a "signal".

Pre- and post-events -- A pre-event occurs before a state change. A post-event occurs after the state change. Use present tense for pre-events (e.g., "Form.Closing") and past tense for post-events (e.g., "Form.Closed") ,
Canceling pre-events -- A pre-event should allow the end user to cancel the event.
Sender and EventArgs -- Event handlers should receive the sending object and a subclass of EventArgs. The former provides scope to the sender, while the later allows new properties to be added later
On... -- Raise an event with a protected virtual method (e.g., "OnAlarmRaised") .

Use exceptions instead of return codes. Exceptions provide a consistent API for reporting problems. They integrate well with object-oriented languages. They support localization. They can not be silently ignored. Exceptions can be instrumented , .

Throw exceptions for all failures -- Do not use failure returns. Throw exceptions for recoverable and unrecoverable errors. Use an error handler to recover from an error if practical. .
Throw standard exceptions -- Throw a standard exception or an exception derived from a standard exception. Then the exception type defines the exception handler
. In C++, throw an exception derived from <stdexcept>. It must have a copy constructor. Do not throw an expression
. Do not throw a string
.
- InvalidOperationException -- an object is in the inappropriate state for the operation . Throw exceptions for incorrect usage of an API
- ArgumentException -- Throw an ArgumentException if an argument does not validate
- In Perl, throw an exception object constructed by Exception::Class. .
Write from the user's perspective -- Write the error message from the user's perspective. Write descriptive error messages. Report the caller's location instead of the exception's location. Tell what's wrong, why it's wrong, where in the data, and whence in the code. Include the values that were not equal, the filename that was not found, the expected string, and the actual string. Give line numbers and character offsets. If practical, briefly indicate how to fix or workaround the problem. For formatting, use STL's ostreamstring (<sstream>) or Qt's QString::arg(). Consider using an exception builder as described below. In Perl, use 'croak' instead of 'die'. .
Prefixed error code -- For published software, include an error code in all error messages. Assign a unique numeric identifier and a prefix that indicates the source. Error codes provide tags for documentation and discussion. Error messages are easily reworded.
Document errors -- Document all errors. Rewrite the error message using full sentences. List the likely causes. Give a workaround and how to fix the problem. .
Unhandled exception -- Write clear error messages. An unhandled exception reflects a bug in the application that can only be fixed by a developer . If an unhandled exception occurs, users must deal with it. Often, an understanding of the exception will lead to a workaround or resolution.
Exception builder -- An exception builder is a method that constructs and throws an exception from a list of arguments. It reduces the cost of exceptions and allows inlining .
Exception constructors -- Provide constructors for default construction, a message string, an inner exception, and serialization .
Exception objects are copied -- Throwing an exception calls the exception object's copy constructor of the object's static type .
Avoid exception specifications -- They do not catch serious errors. They do not work well with templates. They are easy to use incorrectly .

"Even a program with no internal bugs must still interact with the environment in which it executes: at the very least, the operating system, filesystem, terminal I/O, hardware devices, and network connections. That environment must be treated as hostile, because any or all of its components may fail in some unpredictable manner. Robust software must allow for that possibility, detect when it occurs, and either overcome the problem, if possible, or report it and fail gracefully. All of which comes under the mantle of error handling. ... The first [fundamental principle] is that all detectable run-time errors must be detected, classified, and reported. The second is that it should not be possible to ignore any detected error without a conscious and visible effort. .

Error handling is seldom tested thoroughly. Use exceptions to reduce the amount of error handling code. With exceptions, errors due to error handling are isolated to the error handlers.

Only catch exceptions that you can handle -- Rethrowing an exception just confuses the issue. Use a 'finally' block if you need to release resources .
Catch exceptions by reference -- Catch-by-value leads to double-copying of the exception object. Catch-by-pointer leads to ownership problems .
Prevent resource leaks with destructors -- Throwing an exception calls the destructor for fully constructed objects . Do not throw exceptions within a destructor .
Try-parse -- Try-parse returns false if an operation (e.g., parse) fails. Use it for specific, expected failures. Name the method "Try..." .
No exceptions between modules -- Separately deployed modules may use different implementations of exception handling. Catch exceptions at module boundaries: around main, callbacks, threads, module interfaces, and destructors. Translate exceptions into return codes . For example, Qt does not throw exceptions. Unfortunately, this policy makes it easy to ignore errors. An alternative approach is testing for module compatibility at runtime.
assert.c -- The internal code for exceptions must be particularly careful. See Microsoft's assert.c for an example (<DevStudio root>\VC\crt\src\assert.c).

A C++ program must be designed to recover from exceptions. Even modules that use return codes may throw exceptions for memory errors, divide by zero, and other runtime exceptions.

Exception safe code -- "Exception-safe functions ... Leak no resources. ... Don't allow data structures to become corrupted." All functions must be exception-safe, otherwise the system is not exception-safe
.
- Basic guarantee -- After an exception, objects continue to satisfy their invariants, but the exact state may be unpredictable. All functions should satisfy the basic guarantee.
- Strong guarantee -- "if an exception is thrown, the state of the program is unchanged. Calls to such functions are atomic"
- No-throw guarantee -- The strongest guarantee is to never throw an exception, greatly simplifying exception-safe code. All operations on built-in types are no-throw. By convention, destructors and swap are no throw.
- Exceptions are synchronous -- Exceptions only occur at the boundary of a function call. Function calls may occur at operators and implicit conversions .
- Delay changing status -- "[Do not] change the status of an object to indicate that something has happened until something actually has."
- Two-phase modification -- When modifying an object, "perform all of the work that might emit an exception safely off to the side and only then, when you know that the real work has succeeded, you commit and modify the program state using only operations that provide the no-fail guarantee."
- Copy and swap -- Use copy and swap to satisfy the strong guarantee. Make a local copy using the copy constructor, then swap the local copy for the member. The old contents of the member is deleted on exit. It automatically handles self-assignment .
- Copy before delete -- Make a local copy of a member before deleting it. If an exception occurs, the local copy is automatically deleted .
Constructors do not destruct -- Destructors are only called on fully constructed objects (). Catch and handle exceptions inside constructors. Consider auto_ptrs for dynamically allocated data. If an exception occurs, destructors are called for objects created via the initialization list..
Destructors do not throw exceptions -- If a destructor throws an exception, the program may terminate or exhibit undefined behavior.
lists the alternatives for handling exceptions in constructors:
- Call ahead of time -- Have the caller execute code that may throw an exception beforehand. As a backup, the same code is invoked by the destructor, but without throwing exceptions.
- Fail fast -- Terminate the application after logging information about why the program failed.
- Swallow the error -- Doing nothing may lead to undefined behavior later.
- Function try block -- For constructors, use a function try block to catch exceptions during member initialization .
ScopeGuard -- Alexandrescu and Petru Marginean created ScopeGuard to simplify exception safe code. See Generic: Change the Way You Write Exception-Safe Code — Forever

See also

Constructors vs. factories -- Prefer constructors. They are more usable, consistent, and convenient .
Named method -- Use a factory method to document a specialized constructor (e.g., Repeat(char, count) .
Conversion -- Use a factory method for conversions, e.g., from string to object .
Naming -- Prefix factory methods with "Create" (e.g. CreateMyType). For factory types, use a "Factory" suffix (e.g., MyTypeFactory) .

"A function is the basic unit of work, no matter whether you are programming C++ in a structured style, an OO style, or a generic style. A function makes assumptions about its ... preconditions ... and performs one or more actions (documented as its results or postconditions ...)."

Non-member function
- "Prefer non-member, non-friend functions to member functions" -- A non-member, non-friend function can not modify private data, thus keeping the data encapsulated. It extends a class without increasing its size. It improves packaging flexibility .
- Use non-member functions for implicit conversions to all parameters -- A member function can not convert the 'this' argument. Avoid making friends unnecessarily .
- For static friends, declare the function static before declaring it a friend. Otherwise the function will have external linkage .
Overloading vs. defaults -- Use method overloading instead of default arguments. Compilers usually implement defaults by compiling the default value into the call. This breaks most calls if the default value is changed
Implement a non-throwing swap -- "To swap the values of two objects is to give each the other's value." A non-throwing swap simplifies exception-safe code and assignment-to-self. Swap is particularly useful for classes with a private data class
.
- Implement swap via a public swap function (c.f., STL containers).
- Use a total template specialization (prefixed with "template<>") to specialize STL's swap template.
- In the class, define a public swap function that invokes std::swap on the private data pointers.
- The template specialization is a.swap(b)
- If the class and private data are themselves templates, use a non-member swap function instead of a template specialization.
- For greater flexibility, define both a non-member swap and a template specialization.
- Never throw exceptions. A non-throwing swap simplifies exception-safe code. Custom swaps usually operate on built-in types, which themselves never throw exceptions.
const return value -- Return a const reference, pointer, or iterator to provide read-only access.

A derived class inherits from a base class. The derived class may add new methods and data members, or it may redefine virtual methods.

See also

Default initialization -- By default, non-POD objects are initialized with their default class constructor. POD data members and stack variables are uninitialized. An empty initializer list initializes POD types to zero (e.g., 'int a[10]={}') .
Delay initialization -- Initialize a variable when its arguments are available and its use is imminent. Initialization at use makes code easier to read, and may avoid initialization altogether. Prefer initialization to reassignment of a loop variable .
Assignment or call -- Initialization may look like assignment (e.g., 'int x=42' or 'int a[]={57,3,2,1}') or a function call (e.g., int x(42)) .
Resource acquisition is initialization (RAII) -- Manage resources by allocating them in a constructor and releasing them in the destructor. Since exceptions automatically destruct local objects, the corresponding resources are automatically released
.
- "Never allocate more than one resource in a single statement."
- Copying resource managed objects -- For complex resources such as a mutex lock, be careful about copying RAII objects. Disallow copying by defining a private copy constructor and assignment operator. Implement reference counting for implicitly shared objects. Consider using deep copies or ownership transfer .
- Access to the raw resource -- For access to the resource managed by a RAII object, provide either a get() method or implicit pointer conversion. Use get() to avoid unintended conversions. Use implicit pointer conversions for natural pointer references and dereferences .
Move static objects to a function -- In C++, the initialization order for non-local static objects is undefined. Move these objects from the class declaration to a function definition where they are initialized on the first call. See also singleton objects and factory methods . Do not call such functions from the destructor of a static object . Do not initialize static data members at runtime .
Singleton pattern -- Define a factory method that returns its static object . Use a static counter to limit the number of objects . If multi-threaded, call each singleton class on the initialization thread . If static code must run first, define a static object as in <ios>, ios_base::Init .

Always prompt for interactive input -- Prompt the user before requesting input. Use IO::Interactive to test for interactivity. For Perl, consider using IO::Prompt. .
Use progress indicators for interactive programs -- If an operation will take a while, use a progress meter or prompt the user with the reason. a sequence of dots, and 'done' .

General

Code in paragraphs -- Group related statements and definitions into paragraphs. Start the paragraph with a comment .
Declare in paragraphs -- In header files, group related entities together. Organize each group alphabetically. If you use #//Comment to indicate groups, a code outliner may include the groups. A workable order is Fields, Constructors, GetSet, and Modify.
Align corresponding items vertically -- Use vertical alignment to group related information. It makes it easier to scan names and documentation. . For header files, place return types at column 4 and names of functions and fields at column 25.
4-space indents -- Four spaces balances readability with horizontal space limits. Avoid tab characters since they may vary in appearance . Indent preprocessor directives the same as code.
Minimize spaces -- Avoid spaces before opening braces and before opening parentheses. . Do not use a space before assignment. Although non-standard, it distinguishes left - from right-hand side, and it helps avoid substituting assignment for equality.

Headers

Declare fields first -- List the private fields of a class first. It is easier to read the concrete representation of a class than to deduce the representation from its public interface.

Code

#include from specific to general -- List your module's header file first, followed by application header files, then system header files. It helps avoid circular includes and hidden dependencies. []. See for suggestions on managing include files.
Define and declare in the same order -- Header files and code files should follow the same order. The one can act as an index to the other.
Two line method signatures -- Use two lines for method declarations. Place the return type, class, and '::' on a line by itself. The second line starts with the method name. While non-standard, it places names on the left edge for quick scanning.
switch...case -- Align the case statements with the switch. Use either 'break' or a comment at the end of each case []
}else{ -- Do not use a space between a closing brace and a keyword. While non-standard, this increases the visibility of alternative expressions. Alternatively, place the keyword on the next line .
Operator spacing -- Add spaces around low precedence operators. It groups an expression into clauses. You may want spacing around all operators or no spacing at all . Consider spacing for 'operator!'. Spacing enhances its visibility.
Long lines -- Break long lines before an operator. If you break a line after the operator, it is lost at the end of the line. Select the lowest precedence operator, or the assignment operator. If multiple lines, place the terminating semicolon on a line by itself. If in the middle of a comma list, define the expression as a variable .
One-line statements -- A statement block may be on one line with spaces around the brace delimiters. Use one-line statements for inline function, getters, and setters .
K&R brace style -- Place the opening brace at the end of the line, without a preceding space. Place the last, closing brace on a line by itself. Always use braces around one-line blocks .
End comments -- Use end comments for methods, classes, and namespaces. Echo the block's name (e.g., }//main).
Cascading conditionals -- Instead of cascading if statements, consider cascaded ternary operators aligned into columns (i.e., 'test ? if true : if false). The first column is conditionals starting with a colon .

Store heap objects in smart pointers -- If an object is allocated on the heap, initialize a smart pointer with its reference. Otherwise exceptions may leak the object .
Reference counted objects -- See Qt's implicitly shared data and Meyer's on reference counting .
Heap-only objects -- Restrict objects to the heap by making the destructor private. Then define a Destroy() method to explicitly delete the object. See Meyer's errata for a discussion of how to tell if a object is on the heap.
Stack- and static-only objects -- Prevent heap objects by declaring operator new as private .
Match new with delete -- Do not mix array allocation with object deallocation. Do not deallocate objects from a different module. . "The rule is simple: if you use [] in a new expression, you must use [] in the corresponding delete expression." To avoid confusion, do not use typedefs for array types .
Replace new and delete together -- A class may define a custom new and delete function for efficiency, reduced overhead, improved alignment, improved cache consciousness, etc. .
set_new_handle -- Classes and templates may define their own new handler. When memory allocation fails, C++ repeatedly calls set_new_handler until memory becomes available, an exception is thrown, or the program exits .
Dispose pattern -- Managed C# code uses the IDisposable interface to release unmanaged resources. Avoid the use of finalizers .
Be careful of alignment -- Different architectures require different memory alignment for native data types. For example, pointers may need alignment to full-word boundaries. In any case, access to aligned data is usually faster than unaligned data. Be particularly careful when casting pointers to different types. For example casting char* to int* may crash.
Using union to force alignment -- A union data type will align data to the most stringent type. For example, union alignInt { char c; int i; } aligns a character to the same boundary as integers.

A namespace defines a unique collection of names. Java and C# use hierarchical namespaces separated by dots ('.'). Hierarchical namespaces in C++ and Perl use a double-colon ('::') separator. Typically a Java or C# namespace corresponds to a directory of the source tree.

Place everything in a namespace. Otherwise naming collisions may occur between unrelated modules.
Do not use a name that may also be used as a class name.
C++ namespaces -- Nested namespaces are cumbersome in C++. Consider following Java convention (orgQhull::). Namespaces are cThe C++/Qt framework uses a flat namespace with a 'Q' prefix to identify classes.
Unnamed namespace -- Use an unnamed namespace for names restricted to a single file. All names are guaranteed to be distinct. .
Namespace hierarchy -- A namespace should be easily browsed for relevant APIs . Place rare, complex types in a subnamespace .
Using directive -- The using directive prepends a namespace to the search path for name resolution. Restrict using directives to function definitions . Do not use them in header files or before an #include .
Separate types from templated methods and operators -- Define different namespaces for types and templated methods. Otherwise, argument-dependent lookup (ADL) may accidentally select the wrong method. Similar, assign different namespaces for unrelated types. "... avoid putting non-member functions that are not part of the interface of a type X into the same namespace as X .
Avoid namespaces in function declaration -- For global functions such as ostream.operator<<, use namespaces on arguments in the definition of a function, but avoid them in the declaration of the function. In the declaration, let 'using <namespace>::<class>' indicate the namespace. The following problem was seen with declarations with namespaces. MSVC2005 treats declarations with and without namespaces as distinct functions [This may be a bug in MSVC].

For C++, consider adopting Microsoft's naming conventions for .NET identifiers . Strive for syntactic and semantic consistency. A name should "clearly and accurately reflect the purpose, usage, and significance of whatever you're naming." . Use descriptive method names and argument names in headers .

Distinguish components by case -- Use upper and lower case to distinguish different entity types.
- PascalCase -- Use PascalCase for class names, and namespaces. Consider using PascalCase for public properties, interfaces, events, enumerations, and methods.
- camelCase -- Use camelCase for parameter names and local variables
- ALLCAPS -- Use ALLCAPS for macros and #define. ALLCAPS is frequently used for constants, but it is distracting, especially for longer names. Consider using a shared, ALLCAP prefix for constants.
- PascalCase vs. camelCase for methods -- Public methods are proper names with a global identity. .NET uses PascalCase, while most C++/Java code use camelCase. Dewhurst recommends capitalized type names to distinguish them from other names . Sutter, Alexandrescu, and Todd Hoff recommend PascalCase for C++ , [Hoff].
- Underscore -- Use underscores for ALLCAPS and private fields of a class. .NET does not use underscores . Perl programmers often use underscore . Underscore is similar to a dash or a space, but it stands out. A page of underscores can be distracting.
- Prefix -- Prefix static and global variables with 's_'. It helps them stand out. Some users prefix private fields with 'm_' or a '_' suffix. A more readable convention is to use internal underscores for private fields (e.g., begin_node)
Grammar rules -- Adopt a set of grammar rules for naming each entity type (e.g., Noun :: Adjective :: Adjective for namespaces).
.
- Noun phrase -- Use noun phrases (adjective* noun) for type names, properties, interfaces, and variables. For namespaces, use a noun for the toplevel name, followed by adjectives (e..g, package Disk::DVD::Rewritable). For hashes and arrays,. consider adding a preposition (e.g., %title_of, or %sales_from) .
- Verb phrase -- Use verb phrases (verb, optional adjective, noun) for method names and event names. Use past tense for events that have happened. Consider adding a preposition or participle (e.g., getRecordFor or buildExecutionProfileUsing .
- Plural vs. singular -- Use plural for arrays and singular for hashes. An array is a collection often processed iteratively. A hash is a mapping function that is commonly used as a lookup table. Consider naming a hash with a singular noun followed by a preposition (e.g., $count_for). .
- Type indicators -- In general, avoid type indicators (e.g., a 'i' prefix for integer variables). With C++, the use of a variable is usually near its declaration.. Consider a standard prefix for statics and a standard suffix for pointer to pointers (e.g., facet vs. facetp).
- Spell-out names -- Avoid using abbreviations, acronyms, and language-specific names such as 'int' . Identifiers should be spelled correctly. There's multiple misspellings, but usually only one correct spelling .
- Avoid generic names -- Avoid generic type names such as Element, Node, Log, and Message
- Avoid inherently ambiguous words -- Some words are inherently ambiguous, particularly "last" and "set". For example: last (previous or final), set (collection or assignment), left (direction or remainder), right (direction or entitlement), no (negative or number), abstract (theoretical, or summary), contract (smaller or agreement), record (the best, to log, or data), second (ordinal or time), close (near or to shut), bases (base or basis) .
- Id -- Id is an abbreviation for 'identifier'. It is not an acronym. .
Use syntax and naming to distinguish entity types.
- Namespaces and classes -- Use PascalCase.
- Parameters and local variables -- Use camelCase. Use short names for class types. Use descriptive names for builtin types (e.g., int dimension). A parameter and its type should determine its meaning .
- Private fields of an object -- Use lower_case with at least one underscore in each name. Class members define the static representation of an object. They should stand out from other components.
- Boolean property and methods -- Name a boolean property with an affirmative phrase . The resulting conditional expression should read naturally (e.g., isValid or hasEndTag) .
- Globals and class members -- Prefix global variables 'g_' (file or module scope) and class members with "s_" ("static class member"). Globals are implicit parameters to every procedure that uses them. They should be clearly identified.
- Constants and enumerations -- Use PascalCase, perhaps with an ALLCAP prefix (e.g., ERRmemory). The prefix identifies the domain. Do not use "Enum" and "Flag" suffixes
- Derived class names -- End a derived class with the name of the base class
- Public methods and functions -- Use camelCase (C++, Java) or PascalCase (.NET). PascalCase is somewhat more readable, but camelCase is well established for C++ and Java programs.
- Event -- Use an "EventHandler" suffix for event handles (e.g., ClickedEventHandler). Every event handler takes an object (sender) and arguments (ClickedEventArgs)
Do not shadow names -- Avoid giving a variable or function the same name as in an outer scope. Use -Wshadow with gcc. These names are already defined: remainder, index [BSD strings.h].
Good names do not change -- Whenever a name changes, it breaks all uses of that name. See Berner-Lee's Cool URIs don't change.

Use empty() instead of testing size() -- Prefer the empty() predicate over a comparison. The former may be defined for more types .
Prefer prefix increment -- Prefix increment is more efficient than postfix since it returns the newly constructed value , . C++ passes an extra zero argument to the postfix operator ,
Overload operators
- Avoid operator overloads -- Use operator overloads only for types with a natural definition of the operator. For example, redefine subtraction for the difference between two dates , .
- Overloading ostream::operator<< with namespace parameters -- If the parameter for operator<< is in a namespace, the textbook examples do not work. In the header file, declare operator<< outside of the namespace with fully qualified types (e.g., std::ostream <operator<<(std::ostream <os, const orgQhull::QhullVertex::PrintVertex <pr);). In the code file, define the operator<< outside of the namespace with the same signature. 'Using' directives can simplify the code.
```
     namespace orgQhull {
         // namespace definitions
     }
     
     using std::ostream;
     using orgQhull::QhullVertex;
     
     ostream &
     operator<<(ostream &os, const QhullVertex::PrintVertex &pr)
     { 
         // Definition
     }
 
```
- Postfix operator -- Define the postfix operator in terms of the prefix operator
  .
```
  T T::operator++(int){ T old(*this); ++*this; return old; }
```
- Return const objects for prefix and postfix operators -- Otherwise a chain of postfix operators will not report an error .
- Never overload &&, ||, or ',' -- Overloaded implementations of these operators do not have the expected C++ semantics . The comma operator discards the results and type of the left operand. It is mainly used for evaluating functions with side effects .
- Implement op= instead of op -- Guarantee correct semantics for op= by implementing the binary op in terms of op=. If the first argument is passed by value, it may save a temporary
  .
```
 T operator@(const T lhs, const T& rhs){ return lhs @= rhs; }
```
- Commutative operators -- When overloading a commutative, binary operator, you may need to define two operators for differing parameter orders .
Copy assignment -- Copy assignment is closely related to copy constructors. See notes on copy assignment in
Be careful of the question mark operator (... ? ... : ...)
- Enclose complicated selectors in parentheses -- If the selector is complicated, enclose it in parentheses. Otherwise the '?' may associate with the wrong expression.
- Ensure that both expressions have the same type -- If one expression is an object and the other a builtin type, the program may crash unexpectedly. []
- Avoid using ? with << -- The ternary operator, ?, has a lower precedence than the iostream operator <<. This can lead to unexpected results (e.g., cout << a ? f() : g()) .
Be careful of the modulus operator (%) -- In C, the result is undefined if either operator is negative and the result is non-zero.

"Prefer pass-by-reference-to-const to pass-by-value" -- For example, pass-by-value of a Student class costs six constructors and six destructors; none are called by pass-by-reference-to-const. Pass-by-reference avoids the slice problem for base class parameters. Use pass-by-value for built-in types, STL iterators, and STL function objects .
Avoid out and ref parameters -- Pointers, aliasing, and multiple return values add complexity to an API. Return a struct if you need to return multiple values .
Return objects by value -- "Never return a pointer or reference to a local stack object, a reference to a heap-allocated object, or a pointer or reference to a local static object if there is a chance that more than one such object will be needed .
Use the least derived parameter type -- When practical, define parameters as an interface type or base type. For example, in .NET use IEnumerable<T> instead of a collection .
Prefer enums over boolean parameters -- Use enums if a method takes more than one boolean parameter. Use an enum if more than two choices may be required later. Enums communicate and evolve better than booleans ,
Validate enum parameters -- Explicitly check that an enum parameter falls into the expected range .
Naming -- For binary operators, use "lhs" (left-hand side) and "rhs" (right-hand side) ("left" and "right" have too many other meanings). For unary operators and copy constructors, use "other" . For the index of a vector, use "index" instead of "pos" or "i".
Do not reserve parameters -- Define new methods instead of using reserved parameters
Replace long parameter lists with named arguments -- Use named arguments if a function has more than three parameters. Named arguments are easier to remember and verify than positional arguments. Named arguments may have default values. In Perl, pass an anonymous hash. of name-value pairs .
Prefer const -- Parameters, methods, and return types should be const if possible
.
- Bitwise vs. logical const -- Implement logical const. C++ assumes bitwise const for efficiency reasons. Add 'mutable' to fields that do not affect logical const (e.g., a cached value) .
- Apply const everywhere it is appropriate -- Once a method is non-const, it may only be used from non-const methods.
- Const vs. non-const methods -- If appropriate, define methods with both a const and non-const return type. C++ will select the appropriate method. Reduce code duplication by calling the const method from the non-const method. Invoke the const method using static_cast (e.g., return const_cast<char&>(static_cast<const TextBlock&>(*this) [position]);) .
- const T* const -- If 'const' is after the *, the pointer can not be modified. If 'const' is before the *, the data can not be changed.
- Const return value -- A const return value prevents assignments to the returned value (e.g., (a+b)= c) . Unfortunately, it also reduces opportunities for composition (e.g., (stringA + stringB).toUppercase())
- const_iterator -- By convention, a const_iterator may not be used to modify the data. Because the STL defines iterator as a template, a const modifier would apply to the pointer instead of the data.
  It Qt and KDE code, prefer const_iterator over iterator to avoid detaching from implicitly shared objects. Use constBegin() to initialize the iterator and cache the result of constEnd() to terminate the loop. Do not mix const and non-const iterators. [

Reference vs. pointer -- A reference is a permanent alias for another object (e.g., v[0]). Use references for assignment targets and parameters. Use pointers when the value may change or become null. . "A reference is an alias for its initializer. ... The only thing one can do with a reference is initialize it." .
Null pointer -- Use 0 as the null pointer .
Smart pointer -- A smart pointer or auto pointer redefines operator* and operator-> on a private pointer member
.
- Pass smart pointers by const reference.
- Typically the pointer will own the object and automatically delete the data on destruction. If so, define assignment and copy construction to transfer ownership. For example, copy assignment of std::auto_ptr<T> automatically sets the source to 0. Alternatively, use a reference count.
- std::tr1::shared_ptr<T> -- A shared_ptr is a reference-counting smart pointer. Copying a shared pointer bumps its reference count. Similarly, destruction decrements the reference count, deleting the object if zero. . To call additional methods on destruction, pass a "deleter" method to the constructor .
- Implicit sharing, QSharedDataPointer -- Qt uses implicit sharing for many of its classes. Each copy increments a reference count. Each destruction decrements the reference count, deleting the object on reaching zero. Each potential modification clones the object unless there is only one reference.
  - Inexpensive return-by-value -- With implicit sharing, it is inexpensive to return a data structure by value, copy a data structure, or pass a data structure by value.
  - Accidental deep copies -- With implicit sharing, any non-const operation will create a new instance of the data structure. For example, operator[] comes in const and non-const variations. If the non-const operator occurs, the data structure will be deep copied. To help avoid these problems, use const functions such as at() or make value parameters const.
- Do not implicitly convert smart pointers to dumb ones.
- Use member templates to implicitly convert a smart pointer base class to a derived class. See .
- Redefine operator! to test for null.
- Define SmartPointerToConst to allow assignments from non-const to const pointers .
"Avoid returning 'handles' to object internals" -- For example, do not return a reference, pointer, or iterator to a data member. A const reference is OK. Once a handle is returned, "you run the risk that the handle will outlive the object it refers to." "[Never] return a handle to a less accessible member function" .
Return a pointer to allocated storage -- Use a pointer to return newly allocated storage. It signals the caller that the storage needs to be deleted. Do not return a reference .

See also

property vs. method -- A class may use many parameters with few properties (a functional contract) or few parameters with many properties. The later is easier to use, self-documenting, and more easily versioned. Multiple threads can use the same functional class invoking a single call .
Inexpensive properties -- "Use properties for simple access to simple data with a simple computation"
Define setters and getters -- The getter may be the name of the property. Use 'set...' or 'Set...' for the setter. Do not use the same name for both (especially in Perl). .
Invalid state -- Allow invalid states for properties. Throw an exception when the properties are used together .
Throw exceptions for setters -- Do not throw exceptions for getters .

Validate a copy of mutable parameters -- If a parameter is mutable, validate and use a copy of the parameter. Otherwise, the caller may modify the parameter after validation, creating a security hole
Be careful of ToString -- Debugging and exception messages can leak detailed security information to the user. Be careful .

Untested software does not work correctly. By default, software fails to meet its expectations. Just as newly written software almost always has compiler errors, untested code contains logic and design errors.

Write test cases first -- Write test cases as you design the interface. A test suite is an executable specification of your code's expected behavior. Run it often to catch regressions. .
Compile with warnings as errors -- Always compile with warnings reported as errors. Disable legitimate warnings selectively. Warnings often indicate problems with your code. Do not delay your investigation .
Write test cases quickly -- Make test cases easy to write. Use a test framework and enhance it for your application. Writing a custom driver and manually reviewing the output is too much work. In C++, consider QTest and Nunit. In Perl, consider Test::Simple, Test::More, and Test::Harness. . Alternatively, make your code self-checking and develop a command line interface to drive the code. Then a test suite is a long sequence of commands. For initial releases, you should exercise the code far more than your new users.
Write test cases that fail -- Try to trip up your code. Do not write existence tests (i.e., does this function exist?). Find the bugs that others will not find. .
Make code fail easily -- Do not allow errors to hide in your code. Think of a program's execution as a narrow maze through an immense space. The program is correct if it stays within the maze. An error is a step outside of the maze. Once outside of the maze, anything can happen. Whenever practical, check your invariants. Verify that you are in the maze. Then, if something goes wrong, you know it quickly and know when it was last right.
Write test cases for bugs -- If someone reports a bug, your tests failed. Add test cases for the bug. Search for related problems and add tests as needed .
Learn to use the debugger -- Learn the debugger for your programming language. Watching a program step through a routine is likely to surprise you. New code should be watched at least once. It may be the fastest way to detect bugs .
Benchmark your code -- Test the efficiency of your code. You will be surprised by the results. Identify the bottlenecks. Know what routines are frequently called and what routines are expensive. Test both space and time efficiency .

With templates, polymorphism occurs at compile-time. A template defines an implicit interface based on a type's valid expressions. In contrast, inheritance occurs at run-time, defining an explicit interface based on function signatures .

Use templates wisely, not just because you can []. Templates increase the complexity of software by generating source code at compile time. Compile-time errors may be difficult to diagnosis.

Explicitly define the points of customization -- How does a caller customize the code generated by a template?
- What are its method calls?
- What are its nonmember function calls? -- Most non-member calls are resolved by argument lookup (ADL).
- What are the expected semantics of these functions? -- What happens when an error occurs?
- What are its specialized templates? -- The user may specialize a template to define traits or adapters.
Prevent unintended ADL lookup
- Use explicit calls in templates -- Use an explicit call via this-> or a using directive. Otherwise C++ may select a name from the caller's environment. To call the base class, qualify a base class name .
- Place helper functions in their own namespace -- Use an explicitly qualified, nested namespace for helper functions.
Member template
- Member function templates -- A member function template generates member functions for a class. For example, a templated constructor or assignment operator will accept any type (aka. generalized copy constructor or generalized copy assignment). Be sure to declare the normal copy constructor and assignment operator .
- Implicit conversion -- A member template can define an implicit conversion for derived types. For example to convert to a base, smart pointer
  [wiki].
```
  template<class newType>
```
```
  operator SmartPtr<newType>() { return SmartPtr<newType>(pointee); }
```
- Use a templated friend for non-member functions -- Implement a templated non-member function (e.g., operator>>) by defining it as a friend .
- Do not specialize function templates -- When extending a function template, write an overloaded function instead of a specialization. Avoid overloading and specializing altogether by implementing the function template in terms of a class template. Then partially specialize the class template .
Prefer 'typename T' to 'class T' -- A template parameter may be any type, not just a class. Also use 'typename' to indicate nested dependent names .
Remove parameter-independent code from templates -- A template may be instantiated many times. Move code that does not depend on the template's parameters elsewhere. Non-type parameters (e.g., matrix size) may be replaced with function parameters or class data members .
Template metaprogramming -- With work, templates are Turing complete. They can execute programs at compile time .
Do not use virtual methods in templates -- Avoid virtual methods in templates. They may lead to code bloat .
Pass by reference -- Since a template may be used for any type, use pass by reference instead of pass by value. The cost of copying may be high. By convention, function objects are passed by value .
Use != instead of < -- In templates, prefer inequality over less than. The former is defined for many types and iterators .

Be careful of threading -- Guarantee that different threads can use different objects without locking. Specify how multiple threads can share an object. .
Async pattern -- Use the async pattern for asynchronous operations. The main elements are a Begin method, End method, Async Result object, a call-back, and a State object given to the call-back. .
Timeout -- Define timeouts as a TimeSpan parameter. Consider using an int if the timeout is always a small number of milliseconds. Throw TimeoutException when the timeout expires .

See also

"Minimize casting" -- "The rules of C++ are designed to guarantee that type errors are impossible. In theory, if your program compiles cleanly, it's not trying to perform any unsafe or nonsensical operations on any objects."
- Use old-style casts to call an explicit constructor for a function argument.
- Avoid using dynamic_cast by defining a homogeneous container or a virtual function.
- Use Qt's QMetaObject to avoid the high cost of dynamic_cast and typeid().
- Use static_cast to convert an integer to an enum . Cast simple types with a constructor (e.g., int(myFloat) instead of (int)myFloat. The compiler will warn if needed. []
Limit use of get-set -- A type that defines getters and setters for its data members, is not abstract. Users become dependent on a particular implementation . Use get-set to configure a type.
Avoid const and reference data members -- A const or reference data member limits the usefulness of a class. Assignment is difficult .
Avoid implicit type conversions -- Implicit type conversions may happen unexpectedly
,
.
- Use 'explicit' for single parameter constructors . Consider implicit conversions between pointers and iterators.
- Convert to void* -- For convenient null conditionals, convert to void*. For example, STL's basic_ios converts to null if the failbit is set. .
- For commonly used arguments, define overloaded methods and operators. For example, define operator= on String&, char* and char*, String& . Be parsimonious. Do not support many types. They lead to many, many methods,
- Consider conversions to bool, int, and string -- If an object has a natural definition as a bool, int, or string, consider providing the appropriate conversion. It increases the usability of the class. .
Avoid type codes and runtime type queries -- Do not encode the type of an object. An object-oriented type is defined by its behavior, not by its state. Otherwise code needs to test the type of its objects, leading to brittle code. It a type code is necessary, define it with a virtual function . Avoid the use of runtime type queries. They are expensive and have the same failings as type codes . Avoid capability queries as well .
Prefer int to size_t -- The type, size_t, is returned by the sizeof operator in C and C++. It is an unsigned integral type. It leads to many type errors since it does not convert to signed values such as int. Qt rarely uses size_t

Opaque type -- An opaque type hides the implementation details for a public class or handle class. The public class has a private, smart pointer to the opaque type (Qt's d or d_ptr, Sutter's pimpl). The opaque type may have public fields. Qt appends "Private" for opaque type names (e.g., QHostInfoPrivate). Qt defines the type in a separate header file (e.g., qhostinfo_p.h). A less readable choice is an "Impl" suffix , .
Interface type -- An interface class has no data members, no constructors, a virtual destructor, and pure, virtual functions. They often include a factory method to create new objects. The interface may be an abstract base class or a mixin class for multiple inheritance (e.g., IComparable) , . Be careful of defining interface classes. Interface classes can not evolve after they ship Interfaces do not define a contract; prefer abstract classes instead . Avoid marker interfaces without members .
Nested type -- A nested type is defined within the scope of another type. Use nested types for enumerators that need access to the outer type. Do not use nested types for enums
Proxy class -- A proxy class automatically substitutes one class for another. For example operation[] can return a proxy class for distinguish left-hand-side from right-hand-side uses .
Function object -- A function object or functor is a class that overloads the function call operator, operator(). It makes it easy to pass functions into methods or store them for later execution . Connect buttons to actions by defining a hierarchy of function objects . Due to inlining, a function object can be twice as fast as a function pointer .
Static class -- A static class only contains static members. They provide shortcuts to other operations and the system (e.g., System.Environment)

A value type acts like a built-in type. For example, POD types are value types, as are Qt's implicitly shared objects.

A value type has a copy constructor and an assignment operator. Value types do not use virtual functions.
Value types are passed by value or by const reference.
Polymorph vs. value types. Polymorph types have virtual functions, but no copy constructor or assignment operator. They are passed by pointer or occasionally by reference.. In Qt, polymorph types inherit from QObject [vhilsheimer].
struct -- Reserve structs for small, simple value types, similar to a language's primitive types
.
- Limit their size to 16 bytes or less .
- Value type arrays are more efficient than reference type arrays
- Do not provide a default constructor -- Make zero, false, or null a valid value. This simplifies array initialization .
- Implement IEquatable for value types
char -- Do not assume that a 'char' type is signed. Architectures such as PPC use unsigned type for 'char'.

Software changes over time.

Platform-specific files -- Place platform-specific code in one file per platform. Switch platforms by including different files. Do not use the preprocessor and #if statements .
Use a revision control system -- Software changes frequently and is defined by many files. Changes in one file often need corresponding changes to other files. Use a revision control system to keep track of these changes . Be rigorous about the configuration of test and deployed software. Integrate your bug tracking and revision control systems. Know what source changes fixed a bug. For each source directory, know what bugs were fixed by changes within that source directory.
Use 3-part version numbers -- Have a standard for version numbers. You need at least three fields: major, minor, and release. Have a convention for developer releases . Perforce uses year.version.changelistnumber (e.g., 2007.2/122958).

Help

C++ usage

Qt is a cross-platform C++ framework for applications and UIs. It simplifies C++ programming without using the STL. Many of the style guidelines were derived from Qt's source code. Qt Creator is a development envioronment for writing and debugging Qt programs.

Deploying_Qt_Applications

Qt and KDE publish several guidelines for writing programs. KDE is written with Qt.

[Qt] Qt Coding Conventions
QtCodingStyle -- Notes on spacing, layout, etc.
API_Documentation -- KDE's documentation guidelines
[KDE] Common Programming Mistakes in KDE -- KDE coding guidelines
Designing Qt-Style C++ APIs -- "An API is to the programmer what a GUI is to the end-user."
Binary_Compatibility_Issues_With_C++
[library] KDE Library Documentation Policy
[library] KDE Library Code Policy

Qt makes extensive use of implicitly shared objects. These are similar to STL's auto_ptrs.
To maintain binary compatibility, Qt usually defines a private class to implement a public class. Read for a discussion of Q-pointers and D-pointers.

The Windows distribution of Qt Creator includes the MinGW environment. To use MinGW and its g++ compiler, you need to compile Qt. Once compiled, you can select MinGW for the tool chain of a project.

How to compile Qt [Compiling-qt-with-mingw-in-msys]

Download and install one of the Qt Downloads. Install to a directory without internal spaces (e.g., C:/qt/4.5.3).
The STK for Windows includes Qt Creator with prebuilt libraries and binaries. If you want to compile the source anyway. Try these instructions.
If need be, download and install Qt Creator from Qt Downloads.
Install Road Bash -- Road Bash provides a cross-platform shell for Linux, Unix, MacOS, and Windows. For Windows, it redistributes MSYS. Alternatives include MSYS> itself and Cygwin.
- Select a user name -- If your user name contains a space, consider selecting a name without spaces ().
- Define environment variables for Qt and add Qt to your PATH. Use Control Panels->System->Advanced->Environment Variables.
```
    export QTDIR=/c/qt/4.5.3/
    export QMAKESPEC=$QTDIR/mkspecs/win32-g++
    export PATH=$PATH:$QTDIR/bin:$MINGW_DIR/bin
```
- Mount the mingw directory by adding the following line to /etc/fstab (e.g., c:/bash/etc/fstab)
```
    #Win32_Path                     Mount_Point
    C:/qt/qtcreator-1.2.92/mingw    /mingw
```
- Test your bash shell -- ls /mingw $QTDIR
- Configure Qt for compiling (i.e., generate Makefiles for each source directory).
```
    cd $QTDIR
    # Make sure that all build products are removed
    if [[ -f Makefile ]]; then make distclean; fi
    # Consider moving the examples and demos directory elsewhere.  They take a long time to build

    # Create Makefiles for QMAKESPEC.  These options change every version
    #  Note configure.exe -- the configure script may fail to work
    ./configure.exe -prefix C:/Qt/4.6.0 -fast -no-dbus -no-declartive -no-scripttools -no-script -no-javascript-jit -no-webkit -no-svg -no-phonon-backend -no-multimedia -no-qt3support -no-largefile -opensource
```
- Run either /bin/make or /mingw/bin/mingw32-make (they are the same program). This builds object files, libraries, and executables. It will take several hours. Periodically, you will need to rerun the make command because it runs out of memory due to a resource leak.
- Check the Makefiles for Unix-style forward slashes. If they used Windows back slashes, rerun 'configure' or 'qmake' to convert to Unix forward slashes.

error: a class-key must be used when declaring a friend -- Use the keyword 'class', e.g., friend class const_iterator;
warning: expected ';' before "i" -- If you use a templated class within a template function, the expression may be ambiguous ('a<b>c' is a valid expression of comparison operators). Avoid the ambiguity by preceeding the class name with 'typename' (e.g., typename orgQhull::QhullLinkedList<T>::const_iterator i;)
QObject is inaccessible -- Use public inheritance to derive from QObject. Otherwise the derived class and it moc files does not have access rights to QObject methods.

Could not find qmake configuration directory -- Did you define an environment variable QMAKESPEC? For example, C:/qt/4.5.3/mkspecs/win32-g++ [src/shared/proparser/profileevaluator.cpp]
Could not find qmake configuration file -- The file $QMAKESPEC/qmake.conf was not found. [src/shared/proparser/profileevaluator.cpp]
make not found in the environment -- Add the MinGW bin directory to the PATH variable in Control Panels->System->Advanced->Environment Variables.

Perl differs from C++ through its frequent use of notation, builtins, and context. For example, '{ ... }' may indicate a hash literal or a program block depending on context.. The expression @myarray may refer to the array's elements or the array's size depending on context.

Use strict and warnings -- Strict prevents misspellings for turning into subtle bugs. Most warnings indicate legitimate problems in your code. Do not delay fixing them. Do not use $a and $b outside of sort blocks (they are not checked by strict). .
Spacing -- Do not remove spaces that clarify a program's structure. Keep a space after control structure keywords such as 'if' and 'while'. Keep spaces around complex hash keys or array indices .
Terminating semicolons and commas -- Use a semicolon for the last statement (element) of a program block. Use a comma for the last element or a literal list. Neither are required, but they avoid problems when reorganizing or enhancing code .
_ref suffix -- Mark reference variables with a suffix (e.g., $opts_ref). Otherwise a scalar may accidentally store a reference without the corresponding dereferencing arrow .
Dereference with arrows -- Use the -> notation to access a reference (e.g., $list_ref->[0]). Use prefix syntax and braces for a slice (e.g., @{$list_ref}[0, 1]). .
slices -- A hash or array slice is a subset selected by indices (e.g., @active{'top', 'prev', 'backup'}). To select and assign many elements, create a literal hash whose keys select the elements and whose values specify the assignments. .
Double quote vs. single quote -- Use double quotes for strings with interpolated variables. Otherwise use single quotes . Use a pair of double quotes for the empty string ("").
Multi-line strings -- Use heredocs with an END_... terminator. Double-quote the terminator if you are interpolating variables, otherwise single-quote the terminator. For two line strings, concatenate two strings. .

Builtins -- Do not use parenthesis with builtins such as 'split' and 'print'. Always use parenthesis with subroutines. Always use braces for print filehandles .
Always use a block with map and grep -- The map and grep builtins can take a block between braces or an expression. The block format clearly separates processing from data .
Use grep for lists -- For example, remove matching elements from a list with @a = grep { $_ ne 'b' } @a;
Unpack arguments first -- A subroutine call in Perl sets @_ to aliases for each argument. Since @_ has multiple uses, it is wise to immediately unpack it into local variables. Use either 'shift'' or my ($arg1, ...) = @_;. Use 'shift' if you sanity check the arguments. .
Assign defaults immediately -- If a parameter has a default value, assign it immediately. Do not wait until the parameter is used .
Always return -- End every subroutine call with a return statement. Otherwise Perl will return the last value. If a subroutine only returns a scalar value, say so explicitly (return scalar $result. Use 'return' instead of 'return undef' to return a failure. If a subroutine returns a list, return a sensible value in scalar context . If the list is homogeneous, return its size. If the list is heterogeneous, return the most important element or return a string representation of the list. If the subroutine returns an iterative list, return the first element .
Use $warn and Data::Dumper -- Use $warn and Data::Dumper for debugging statements. $warn identifies the statement and writes the output to stderr. Data::Dumper gives the details about data .
Weaken -- Use 'weaken' to avoid circular data structures that leak memory. A weakened reference is not reference counted. It becomes 'undef' if its referent is garbage collected. For example, weaken a back link to prevent a cycle of nodes that each refer to the next node. Such cycles can not be garbage collected.

Perl provides several implementations of object-oriented programming.

Do not make object-oriented a requirement -- Perl's support of object-oriented programming is inconsistent. Method calls are slower than subroutine calls. Use objects for large applications, applications with lots of structured data, domains that are naturally hierarchical, and software written by teams of programmers, .
Inside-out objects -- Inside-out objects implement fully encapsulated objects. They define a hash for each attribute. An object is a blessed, uninitialized scalar that indexes the attribute hashes. Inside-out objects safely handle single and multiple inheritance. They require a destructor to delete the attributes. See Class::Std and .
new -- Use 'new' as the name for an object's constructor. Pass arguments as an anonymous hash. Use a hash of hashes if a class hierarchy reuses attribute names. Do not use new() as a copy constructor (e.g., $object_ref->new()). Define a clone() function instead. . If using multiple inheritance and class hierarchies, define new in the base class. New invokes BUILD and DEMOLISH methods in derived classes .
Private methods and utility functions -- Perl does not use header files that define the public interface to a class. Consider using a leading underscore to distinguish methods and functions for internal use only. .
Overload boolean, numeric, and string coercions -- Object references do not naturally convert to booleans, numbers, or strings. Define these conversions with 'use overload' or make them throw an error. .

Perl provides many alternatives. Avoid the following constructs.

Control structures

Avoid postfix if -- It hides the decision and its consequence. Reserve postfix if for flow-of-control statements (e.g., return if $floor == $measurement). .
Avoid postfix control statements -- Do not use postfix until, for, or while statements. .
Avoid negative control statements -- Do not use 'unless' or 'until'. Programmers are unfamiliar with these constructs. Restate in the positive. If you use 'unless' never use a negative sub-clause such as unless ($count != $MAX_COUNT) .
Avoid do..while loops -- Next, last, and redo do not work within do..while loops. Rewrite as while loop with the condition initially true .
Do not use for (<>) -- A for statement reads in the entire file before starting the iteration. Use while (<>) instead. If you need to slurp the file, consider using Perl6::Slurp .

Data

Do not use lvalue accessors -- Do not return an lvalue from a subroutine. it undoes encapsulation of the object's data. In C++, do not return a pointer to a data member. .
Do not use symbolic references -- A symbolic reference is a lookup in a symbol table. Use a lexical hash instead. .
Do not use pseudohashes -- A pseudohash is a hash with an included schema. They are expensive in memory and execution time. They are prone to obtuse errors when inherited .
Do not use restricted hashes -- A restricted hash disallows access to unknown elements. Unfortunately, its restrictions are easily circumvented .

Objects and modules

Do not set @ISA -- Define inherited classes at compile time with 'use base' .
Do not bless without a package -- Do not use the one-argument form of 'bless' .
Do not use indirect object syntax -- An indirect object call mimics Perl's builtins (e.g. method $obj instead of $obj->method()). It leads to difficult errors. .
Avoid AUTOLOAD -- Perl invokes AUTOLOAD for unknown methods in a class hierarchy, potentially adding any number of methods to a class. For example, if a class does not define DESTROY(), AUTOLOAD will see the call on every object destruction. Do not define more than one AUTOLOAD. .
Avoid export by default -- If you export a routine named 'fail', it will override similarly name subroutines from other modules. Require explicit export for most subroutines .
Do not export variables from a module -- Variables (like fields of an object) should be private to the module .

Builtins

Do not modify $_ in map, grep, or first -- For these functions, $_ is an alias, not a value. Make a copy first. Modifications to $_ modify the source element. .
Avoid eval of a string -- String eval does not produce warnings at compile time. Use anonymous subroutines and Sub::Installer instead .
Avoid lvalue substr -- Use a 4-argument substr instead of assigning to a substr .
Do not use bareword filehandles -- Use indirect, local filehandles instead of bareword filehandles. Either use 3-argument open or IO::File.. Check for errors. Close filehandles explicitly, as soon as practical .
Do not use autoflush -- Do not use autoflush, especially with select. IO::Handle autoflush() is better .
Do not use 'format '-- If you need ascii formated tables, consider using Perl6::Form . Spreadsheet output gives you flexibility.
Do not tie variables or filehandles -- The tie builtin works behind the scenes to call a function whenever you access or modify a variable. Use explicit calls to methods or subroutines instead .

Subroutines

Do not test for undefined arguments by value -- Use if (defined $arg) or if (exists $arg) instead of if ($arg). The false values 0 and "" may become legitimate values for $arg .
Do not use subroutine prototypes -- Subroutine prototypes lead to surprising behavior. Do not use them .

Regular expressions are a compact representation of a string transformation. Treat them with care., like any programming code. Mistakes are easy to make. See for additional notes on minimal matches, capturing parentheses, captured substrings, tokenized matching with /gc, tabular regular expressions, complex regexes, alternations, and backtracking,

String eq is faster than regexp -- Use string eq for matching specific strings. A regular expression with literal, alternative strings is slower.
Always use xms flags -- The 'x' flag allows comments and spaces. The 'm' flag matches ^ and $ to the beginning and end of a line (as in Unix). The 's' flag matches '.' to any character including newlines. Use '[ ]' to represent a single space. Use '\A' and \'\z' to match the beginning and end of a string .
Always use brace delimiters -- Use braces for delimiters { e.g., m{...}xms and s{...} {...}xms. Braces nest and reduce the likelihood that regexp comments become code (as in ([^/n]*) # value of file/option/mode). Use slashes for short, embedded patterns within a 'map' or 'grep' expression. .
Escaped metacharacters -- Use singular character classes for escaped metacharacters such as '[.]', '[*]', etc. An alternative is named characters (e.g., \N{SPACE}. .
Prefer \s to [ ] -- The character class \s matches any space character. Alternatively, reduce all runs of space characters to a literal space, then match single spaces. .
Prefer properties -- A Unicode property matches a character class across all languages {e.g., \p{Uppercase} .
Use list assignment for captured substrings -- Assign a list of lexical variables to each captured substring (e.g., my ($opt_name, $operator) = $config- =~ m{ \A (\S+) \s* (*|[+]=)}xms .
Thompson NFA for regular expressions -- Thompson NFA are faster than Perl's implementation. They are used in grep and awk.

Perl has a wealth of modules in CPAN and the standard module library. For additional recommendations, see perlmodlib and .

Benchmark -- Time your routines .
Class::Std -- Encapsulated object-oriented classes using inside-out objects .
Config::Std -- Flexible and straight-forward configuration of your programs. Provides named sections, key/value pairs, multiline values, and comments .
Data::Alias -- Create an alias for most expressions. For example, iterate over the keys of a hash and create an alias to each value. Unlike the each keyword, you can modify the value through the alias .
Devel::Size -- Measure the size of your data structures .
Exception::Class -- An exception object conveys failure data to the handler. It allows a hierarchy of error classes with type specific error handlers. For example, if (my $exception = X::EOF->caught()) { ... } makes a local copy of $EVAL_ERROR to prevent overwrites. .
Fatal -- Makes builtins throw exceptions. .
Inline -- Include source code from other programming languages in your Perl modules. .
List::MoreUtil -- Includes all, first_index, apply, pairwise, zip, uniq .
List::Util -- Includes first, max, min, shuffle, sum, and reduce. Util::first() returns the first element that matches an expression .
Module::Starter::PBP -- Module templates with test code and documentation .
only -- Enforce dependency requirements by version. .
Perl::Critic -- Static analysis for Perl Best Practices.
POE -- Portable multitasking and networking.
Regexp::Common -- Regular expressions for zipcodes, etc. .
Scalar::Util -- Includes blessed, reftype, readonly, tainted, openhandle, weaken, looks_like .
Spreadsheet::ParseExcel -- Work with Excel spreadsheets
Text::CSV_XS -- Split complex lines of variable-width data .
version -- Support three-part version numbers. Use with 'only' .
YAML -- Compact, readable string representation of Perl data.

Bulka, Mayhew, Addison-Wesley, 2000, ISBN 0-201-37950-3

Efficient C++ programming with timing comparisons.

Cline, Lomow, Girou, Addison-Wesley, 1999, ISBN 0-201-30983-1

Introduction to C++, its usage, and COM via FAQs.

Carroll, Ellis, Addison-Wesley, 1995, ISBN 0-201-51284-X

Reusable C++. A classic.

Conway, O'Reilly Media, 2005, ISBN 0-596-00173-8

Perl best practices are surprising relevant to C++

Cwalina and Abrams, Microsoft Press, 2006

Microsoft's style guide for the .NET framework. Thorough with lots of commentary and advice

Dewhurst, Addison-Wesley, 2003, ISBN 0-321-12518-5

An advanced course in C++ programming. "A significant portion of this book is spent describing the nuances of certain areas of the C++ language that are commonly misunderstood and frequently lead to gotchas."

Dewhurst, Addison-Wesley, 2005, ISBN 0-321-32192-8

"Essential, common knowledge that every programmer needs to know, in a form that is pared to its essentials and that can be efficiently and accurately absorbed." Includes advice on templates.

Lippman, Lajoie, Moo, Addison-Wesley, 2005, ISBN 0-201-72148-1

A thorough introduction to the C++ language, libraries, and usage.

Lischner, O'Reilly, 2003, ISBN 0-596-00298-X

Complete, concise reference to the C++ language and standard libraries

Meyers, Addison-Wesley, 1996, ISBN 020163371X

Technical details not covered by Meyers' classic, Effective C++.

Meyers, Addison-Wesley, 2001, ISBN 0201749629

How to use STL well.

Meyers, Addison-Wesley, 2005, ISBN 0321334876

How to use C++ well. The best advice on using C++.

Stroustrup, Addison-Wesley, 1993, ISBN 0-201-53992-6

C++ described by its creator. Includes chapters on designing classes and libraries.

Sutter and Alexandrescu, Addison-Wesley, 2005, ISBN 0321113586

Coding standards gathered from multiple sources.