Coding

  • Use standard library routines where they exist. Have a reference by your side, and look up what you don't know (don't guess the return value, check the book). This holds for string routines especially - people seem to write a lot of routines for things like finding the right character. In the case of C++, the standard template library has been accepted, and is starting to appear in implementations. The same principle applies.
  • I have a standard include file I put first in my .cc files. It defines macros for PRE(), POST(), and ASSERT(). I just define them all to "assert" for now, but I like the flexibility, and the name documents the purpose. Anyway, I use these in my routines, where possible on each argument coming in and each result going out. The Eiffel language has this integrated in, and their environment lets you turn PRE-POST checking on/off on a class-by-class basis. It's worth looking at Meyer's book "Object-Oriented Software Construction".
  • In defining C++ classes, I have a couple standard methods: OK() and dump(). OK() represents the class invariant, and I check it on entry and exit from each routine. dump() is available for debugging, and writes info to a file.
  • Be careful with C++'s automatically defined routines: constructor, assignment, copy, and destructor. There is a way to shut off compiler generation of these; if the default is called it is likely to have bad semantics for real objects.

Class structure

How are C++ programs split into files (what is the mapping from the logical to physical organization?)

What is the basic layout of the header and body sections?

  • Header file protects against double inclusion (#ifndef, #define, ..., #endif)
  • Project include file
  • What operators are always defined by a class?
    • Constructor. At least one exists. May use constructors with parameters. Make private a parameter-less constructor for classes that must have parameters to build their object.
    • copy constructor
    • operator=
    • destructor
    • Most classes need an operator==
    • dump ()
    • Explicitly comment when taking compiler default.

    Follow this style exactly: every class eventually needs these, so just define them & be done with it.

  • STANDARD/ACCESSORS/MODIFIERS
    • Use of "type function (params) const;" for accessors
    • Some people argue against the use of a "set/get" function like "pop" for stacks, arguing that you should use "top" to get value, then "pop" to modify it, but pop should result in a new stack, not return a value.
    • Iterators are friends of class they iterate over.

Safety

  • Class invariants Should this just be a standard function?? (In protected section.)
  • Preconditions & postconditions & assertions
  • Documentation of class & variables.
  • Exception handling Never return an explicit status. Use exceptions to return wild status instead.
  • Provide an accessor function so client can determine if it'll do something dangerous. Ex: an is_eof() function, not just a return value on read(). (Client should be able to test for eof without triggering the exception from read.)
  • Many following things affect safety.

Memory Management

  • There are many possible styles. Must choose one & follow it religiously.
  • There are problems when mixing styles too. Tricky topic. The pit of C++.
  • Default style: counted pointers.
  • Alternatives: Garbage collection, no management.

Naming

  • Files
  • Namespaces.
  • Classes
    • Adjective*Noun
    • Template classes end with preposition
    • Mixins may be adjectives, often of the "able" or "ible" form.
    • Iterators: Adjective*NounIterator ??
  • Member functions
    • Bool functions: Name function is_on(), not state(). (Adjective or isXyz - make sure the sense corresponds to true.)
    • Accessors: noun (phrase) of return value
    • Modifier: verb (phrase) of action to be done.
  • Public class variables Don't use them - provide an accessor/modifier pair if you must
  • Protected/private class variables Name them _lowerUpperUpper
  • Enumerations
  • Constants Use "const int xxx = value;" by default.

Formatting

A religious issue. So, I'll jump right in: 4-space indent, liberal whitespace, etc. Create a file ".indent.pro" wit this contents: "-bad -bap -c40 -ncdb -di12 -i4 -pcs". This will set defaults for the indent program.

Consistency is really the important thing

Two rules I believe in, probably important enough to mention

  1. Case statements are much less impt. in C++ than in C, BUT: put a break after each case, including default:, and comment any FALLTHROUGH deviation dramatically.
  2. Always use braces on if. The only exception is a single-line statement statement of the form "if (foo) statement;"

Copyright 1994-2010, William C. Wake - William.Wake@acm.org