wiki:EW_coding_standards
Last modified 6 years ago Last modified on 08/09/11 15:10:24

Earthworm Coding Standards

Some suggested things to follow:

• Turn on the compiler warnings to detect uninitialized variables, which is disabled in gcc by default. (I'll probably do that ASAP.)

• Use standard C instead of K&R C. That means making sure there are function prototypes for everything, and not in the old K&R style.

• See what happens when we turn on -Wall when using gcc

• In makefiles, use CPPFLAGS for the -I and -D flags, CFLAGS for the -m32 and -O and -W flags, LDFLAGS for linker options (this is going to be tricky, though -- the option text has to change from a straight ld option to the form that gcc or gfortran will pass through to ld when the link step is handled by a compiler driver). I also have mixed feelings about where -m32 should go. I think I prefer it in the CC variable, since it is really like picking a different compiler (think cross-compiler) than a compiler option.

• Preserve user flag settings, e.g., (gmake only?) use CFLAGS += extra flags (else CFLAGS = $(CFLAGS) extra flags)

• Find out what code breaks with -m64

• (Much tougher) find out what code breaks when -O is used (like the bug I found in transport.c)

• Make sure any compile rules in makefiles have both CFLAGS (FFLAGS) and CPPFLAGS

• Make sure any link rules in makefiles have both CFLAGS (FFLAGS) and LDFLAGS

• Use $(MAKE) when recursively calling the same make file, use $(RM) (at least with gmake), since not all platforms accept (or require) the -f option.

• Try to rationalize conditionals throughout the code to directly reflect the choice being made. For example, use LITTLE_ENDIAN or BIG_ENDIAN when the code cares about endianness, not the name of a particular architecture. Don't use O/S name (e.g., SOLARIS or MACOSX) to conditionalize a compiler feature. We may find the categories on the Source Forge web page I found useful (http://sourceforge.net/apps/mediawiki/predef/index.php?title=Main_Page).