Matt's Programming Guidelines Version 1.1

(or What I Have Learned the Hard Way)

General

  1. Before starting, determine what is the problem you are trying to solve (This is not as obvious as it sounds).
  2. Think before you code.
  3. Think again.
  4. Think about how you are going to test your code.
  5. When possible, build test drivers into your code.
  6. Test your code as you implement.
  7. Test your code when you finish.
  8. Test boundary conditions.
  9. Backup your work using a variety of methods and media -- both code and documentation (and test the backups!)
  10. Having a legible printed copy of your design, code and documentation is always a good failsafe backup method.
  11. Comment the purpose of the code not the implementation (unless the code is doing something special).
  12. Try not to write code that does something special.
  13. Comment special coding techniques for the next person.
  14. When possible, re-use rather than re-write. That said, sometimes the only solution is to re-write.
  15. When estimating the time for a task, don't forget to include time for design, documentation and testing.
  16. Sad but true - before giving the estimate to your management, double the number and up the unit (e.g. 1 hour ==> 2 days).
  17. The software you write is a tool to solve someone's problem and not a means to showcase your brillance.
  18. Get the software to work before trying to optimize it.
  19. Every enhancement added is more code to test and document.

C Language

  1. Multi-line macros are strongly discouraged.
  2. Do not embed C keywords (exit, return, for, etc.) in macros.
  3. Each usage of a macro parameter must be parenthesised when used.
  4. Overall replacement text must be enclosed in ()s for expressions and do { ... } while (0) for statements.
  5. Use #define to give mnemonic names to constant expressions.
  6. Do not create ad hoc syntax extensions.
  7. Pointers can only point to: NULL, another pointer, &variable, an array, a function name, and a pointer valued function call.
  8. Don't use >> on signed quantities.
  9. Never extract data from a variable in a manner other then that in which it was stored.
  10. Use typedef to create names for commonly used types.
  11. Every function and variable must be explicitly typed.
  12. Whenever reasonable, declare functions returning int, not short or char.
  13. Functions that do not return a value should be declared as type void.
  14. Expressions in while, for, if and ?: should have boolean values.
  15. Use int and double as generic types when space doesn't matter.
  16. Do not assume that a pointer and a long are interchangeable.
  17. Never depend upon the order of bytes in a variable.
  18. Use ctype rather than compares or bit checks on characters.
  19. Do not dpened on results of arithmetic expressions on char values.
  20. Only compare characters using == and !=.
  21. Always pass structures by reference using a pointer; do not pass structures by value.
  22. Do not use gotos.
  23. for (;;) is usually better (and faster) than while (1).
  24. Do not declare public variables in the #include file.
  25. If a constant is used only in one module it should be defined at the head of the module.
  26. In general, avoid nesting #include files.
  27. Keep source lines under 80 columns when possible.
  28. Use two (2) character indents.
  29. Try to order parameters as input only, input-output, and output only.
  30. Whenever possible, do not use break or continue inside loops.
  31. Null (empty) statements must be comments (e.g. /* do nothing */ ;).
  32. Space before and after each relational operator.
  33. Try to keep functions to a couple of pages in length; use sub-functions if necessary.