
mTCP Coding Guidelines
Michael Brutman, May 2011


It is not my right or intent to lay down strict coding guidelines.
But I will share what I think works.


C vs. C++

  The code is nominally C++.  It is more like C with classes and
  some methods.

  I generally use malloc and free (c) instead of new and delete (C++).
  This has to do with limitations in the original compiler; it did
  not support new with placement which is something I needed
  to support my usage of memory pools for objects.

  Don't use C++ exceptions.  Use return codes, and check them
  religiously.

  Use inheritance if you must.  No polymorphism, abstract base classes,
  pure virtual functions, or other works of the devil.  (Ok, I'm
  just having a little too much fun.)


Spaces vs. Tabs

  Two spaces per indent level please.  No tabs - use spaces.


Code defensively

  - Check return codes and react accordingly
  - Avoid buffer overruns at all costs - they lead to crashes


Avoid casts

  C casting has its place, and you will see it in the code.
  But be careful with it - casting tells the compiler that you
  know more than it does, reducing the compile time errors that
  the compiler can catch for you.


Assembly language

  The vast majority of the code is C/C++.  There are a few cases where
  I dip into assembler:

  - Performance: the C compiler can't be tricked into producing good
    code, or the call path length is too excessive.  These cases should
    be rare.

  - Avoiding code bloat: using some portions of the C runtime can lead
    to unintended code being linked in, whether it is needed or not.
    Sometimes it is just more efficient to make a DOS or BIOS call
    directly to avoid the extra code bloat.

  I really like the Open Watcom style of embedded assembler.  It is
  not as straightforward as the Turbo C++ inline assembler syntax,
  but it gives the compiler more information about what you are trying
  do to and lets the compiler optimize with the inline assembler
  in mind.


Comments

  Please use comments.  Not simple ones like "add byte to checksum"
  but real comments that explain things that might not be obvious.
  Comments are a great place to discuss design decisions, corner cases
  that might break under testing, etc.


