Coding Guidelines

These guidelines are from Heinz Wrobel's article "Coding Standards" supplemented with AmigaOS API and types recommendations.

Some rules programmers should adhere to

General

The zeroeth law of C programming:

0. Fully agree on the coding rules BEFORE you start the project and make them available IN WRITING. Revise them as necessary in a group effort and document reasons for changing them.

Code Formatting

First a few comments about looks and braces:

- BE CONSISTENT. No matter what coding style you choose, use it

 consistently. READABILITY COUNTS.

- BE CAREFUL ABOUT TABS IN YOUR SOURCES. Tabs can be the most

 obnoxious things in the world. They can even shut down your work
 or at least waste valuable resources. Why? Because nobody cares
 about the details. Due to historical reasons the tab character
 should represent eight spaces. To be exact it should represent a
 move to the next column with its number being a multiple of eight.
 This value of eight spaces is very important as it is THE ONLY
 value where portability including all alignment of the sources
 between different OS or editing environments can be guaranteed.

 It is common practice to use tabs to indent sources. That is most
 definitely not a bad thing. Unfortunately most brain damaged
 editing environments allow arbitrary configuration of the tab
 width for the display and then save these "display tabs" as "disk
 tabs". This messes up all alignment once the next team member
 loads the source into his favourite editing environment. This can
 decrease readability to almost zero, and it is guaranteed that
 people will get into a "formatting war" instead of doing the job
 necessary. Obviously this is a totally unacceptable situation.
 There is only one solution:

   Configure your editing environment to differentiate between
   "disk tabs" of eight spaces and "screen tabs". You work with
   screen tabs and your environment will have to automatically
   convert between your favourite screen tab setting to the disk
   tab size of 8 whenever it writes documents to disk. Of course
   on loading an appropriate conversion to screen tabs has to take
   place, too. If the environment does not support something like
   this, trash it or don't use tabs in any source at all.
   Otherwise you WILL have a problem.

 Concerning screen tab expansion, I strongly recommend a setting
 of four. This allows for easy and efficient conversion to disk
 tabs and gives a visually effective indent in pretty much any
 programming language.

 Be extremely carful about automatic tab conversions in your
 editing environment. If there is any chance that other members of
 your team have to access the sources, automatic tab conversion
 should be disabled. Otherwise the usefulness of any revision
 control system in development is severly limited as the sources
 will change "randomly" between certain tabs and space
 configurations.

- MARK THE CLOSING BRACES WITH COMMENTS! Once you have seen >10 "END" or

 "}" statements in a row and spent >10 minutes to figure out where they
 belong, you know what I mean. Never just write "}" and nothing
 more, write "} /* if */" or "} /* function_foo */". This is
 important. Modern editing environments can be configured to do
 this automatically for you.

- Having matching braces (as opposed to the K&R style) aligned in one

 column makes finding the matching brace a lot easier. The brain
 gets 87% of its outside information via the eyes. Simple
 improvements in readability like this will save time.

 Example of a coding style concentrating on readability:

   void function(int foo, int bar)
   {
       switch(foo)
       {
           case 1:
               if(bar == 2)
               {
                   /* Do something about it! */
               } /* if */
               break;
           default:
               break;
       } /* switch */

   } /* function */

 Naming a closing brace (or an #endif statement) as described
 above helps matching them even further, especially when moving
 through code of a team member.

- ALWAYS USE BRACES, even for single statements. This helps avoiding errors

 when code is revised and statements are added.

   if(bla)
       foo = test(foo);
   else
       foo = test2(foo);

 is MUCH more error prone than:

   if(bla)
   {
       foo = test(foo);
   }
   else
   {
       foo = test2(foo);
   } /* if */

 With braces, changing code is less dangerous. Without braces it
 can be very easy to get lost and to overlook a statement
 dependency when you have to work with code of some other team
 member. Safety counts and helps to avoid delays and expensive bug
 fix releases "just because someone overlooked a semicolon" or
 because of a similar stupid reason.

- DO NOT FAKE OTHER LANGUAGES, e.g. PASCAL BEHAVIOUR. Redefining e.g.

 "{"/"/" as "BEGIN"/"END" with the preprocessor is IMHO a misuse of the
 language. To the experienced it is as misleading as to beginners, and non
 standard constructs reduce readability because "nobody" knows about them.
 Using the language as it was defined allows your team to stay with
 standard references and manuals. If someone does not _want_ to use a
 language as is and _insists_ on aliasing its constructs to his favourite
 thing, he/she'd be better in some other place. This person will probably
 misuse any language. Using a screwdriver as a hammer does not lead to
 results.

- LIMIT FUNCTION SIZE. Once the text of a function is much more than e.g.

 two screen sizes, split it up into subfunctions. Huge functions make
 revisions and maintenance a pain. Typically, performance isn't an
 issue here and link time is less than compile time.

- LIMIT FILE SIZE. A C source file should never be longer than a

 few hundred lines. 1k lines is the absolute upper limit.
 Modularity helps a lot with C, too. Consider the linking process
 to be a feature.

- USE HEADER FILES. Create prototype header files and header files with the

 externally needed data declarations. Use them as help for making black
 box modules.

- Separate functions with some sort of header or even a simple line:

/*------------------------------------------------------------------------*/

 This makes fast reading of source files and understanding their contents
 a lot easier. Don't use "bold" lines, e.g. lines made up of
 asterisks '*'. Depending on the display they lose their line-like
 character and clutter the screen instead of helping to make
 things readable.

- Use a standard header and footer for each source file. If you are using

 a Revision control system, the header should contain an identification.
 This header can be quite simple:

/*------------------------------------------------------------------------*/ /* *

*  $Id: CodingStandards,v 1.2 1996/07/13 20:51:24 heinz Exp $
*                                                                        */

/*------------------------------------------------------------------------*/

/*------------------------------------------------------------------------*/ [headers here]

/*------------------------------------------------------------------------*/ [code here]

/*------------------------------------------------------------------------*/

/* End of Text */

AmigaOS-defined APIs and Types

• Prefer using AmigaOS types such as int32 and STRPTR over int32_t and *char.
• Prefer AllocVecTags() and FreeVec() over malloc() and free().

Programming Language

- USE THE ANSI C STANDARD for declarations. Avoid K&R wherever possible.

 The compiler is your friend and will do better error checking
 with ANSI prototypes.

- ALWAYS RUN the compiler system with THE STRICTEST ERROR CHECKING MODE

 possible. C compilers have limits to their diagnostic ability, so use what
 is available. ERRORS AND WARNINGS ARE NOT ACCEPTABLE!

- READ THE "IMPLEMENTATION-DEFINED BEHAVIOUR" SECTION OF THE MANUAL BEFORE

 YOU START. While there is a standard for C, there are still things that
 can bite you if you are not aware of them. ANSI C does not
 automatically mean "great, portable, and future compatible".

- HAVE THE LANGUAGE DEFINITION IN REACH FOR ALL TEAM MEMBERS. I also

 recommend having a book like "P.J.Plaugher: The Standard C Library"
 around as reference to everyone on the team. IF IN DOUBT, LOOK IT UP! IT
 IS NOT A SHAMEFUL THING TO DO!

- STAY WITH STANDARDS WHEREVER POSSIBLE. If you write a standard

 C application use the standard ANSI library. If you write
 something specific to a certain OS, use the tools the OS
 provides. Avoid arbitrary mixtures of standard C and OS specific
 C. Avoid use of functions specific to your current C compiler
 system or specific to the HW if you want to have protable code.
 You might need to change both eventually. This is mostly a
 problem for IBM clone programmers who think that "Borland C++" or
 "MS C++" and clones is the only thing there is in the world.
 Watch your team. Check what your compiler does per default with
 newlines or character sets! "\r\n" vs. "\n" problems can be
 eventually as painful as a compiler system that mangles ISO
 characters into 7 bit in strange places. Note that handling
 binary file data is different than text data with the ANSI C
 library. Do not rely on it being the same for all compiler
 systems.

- ISOLATE NON PORTABLE CODE.

- USE "const" and "volatile". Especially "const" helps the compiler and the

 poor soul who writes and debugs the code a lot. Wise use of "const"
 enhances the compiler error checking capabilities usually a lot.
 Some compilers may generate poor code with these keywords
 unfrtunately. In that case an easy solution is to define them to
 nothing when generating production code.

- Define anything that does not need to be externally visible as "static".

 LIMITING SCOPE of unneeded stuff helps a) the linker, b) modularity, c) a
 strong black box approach for modules.

- USE THE PREPROCESSOR CAREFULLY. While it may be useful to give strange

 constants nice names, use of it should be monitored. Major caveat: C is a
 language where expressions often have side effects. Side effects hidden
 in preprocessor macros are not diagnosed by all compiler systems! Do not
 overdo it here!

- If a source file has self contained functionality like e.g time

 conversion stuff, think hard about ADDING A TEST CASE FOR CONDITIONAL
 COMPILE in the first place.

   #ifdef TEST
   int main(int argc, const char **argv)
   {
       /* test the darn thing here! */
   } /* main */
   #endif /* TEST */

- REMEMBER: THE LINKER IS YOUR FRIEND!

- If your compiler system has an automatic build facility like "make", use

 it. "make" is a very helpful tool. If you have some sort of custom
 integrated compiler  environment, make sure that you can comparatively
 easy fall back on a standard make like scheme. Be careful about
 all the different incarnations of "make". KEEP THE PARACHUTE
 CLOSE.

- C IS USUALLY MOST EFFICIENT WHEN USED WITH POINTERS. Passing data

 structures is not good, most things are done with pointers. If your team
 does not have a FIRM UNDERSTANDING OF POINTERS, teach them first. Don't
 let them fiddle along. They need to know first or you might be in deep
 trouble.

- CHECK FUNCTION RESULTS FOR ANY FUNCTION THAT MAY FAIL. A common error is

 not checking for failure on e.g. memory allocations. ASSUME A NEGATIVE
 SITUATION when writing the code. It will hardly ever be a performance hit
 if you do and increase reliability.

Debugging Code

- CHECK FOR NULL POINTERS AND POINTER OVERRUNS.

- C STRINGS HAVE A TRAILING NULL BYTE AND ARE THEREFORE ONE BYTE LONGER

 THAN THE CONTENTS!

- CHECK FOR MISSING "*/" END OF COMMENTS. YOU MIGHT HAVE LOST A LINE OF

 CODE.

- If a bug is still hiding and can't be found, have the author explain the

 functionality of the code in question line by line including limit and
 exception handling to someone on the team who is not directly involved in
 this part of the project. This will usually solve the problem pretty
 fast and save additional cost.

Version Control

- USE some sort of A REVISION CONTROL SYSTEM like RCS, CVS, SCCS ...

 PUT A FILE ID COMMENT (like the RCS 'Id' keyword) INTO EACH
 SOURCE FILE. Otherwise identifying a printed revision is pretty
 much impossible once you get swamped in paper. I use RCS. Do not
 ever use expanding 'Log' like keywords in your sources. They just
 duplicate what is in the repository already and they'll make
 identifying differences even harder. After a while they also
 clutter the source.

- Mark stable revisions and flame everyone who makes too many changes to

 the code before using the revision control system to check it in again.
 There should not be any work files not being checked in lying around at
 the end of a working day!

Afterword

Last but not least: Have fun.