From RFID Guardian

This is a fairly large software project. Please follow the coding guidelines here; conformance helps understanding.

Contents 1 C code 1.1 Software tree structure 1.2 Documenting 1.3 Naming 1.4 Types 1.5 Layout 2 Java code

C code

Software tree structure

• include file

in the include/ tree

has public interface for your module. Anything that need not be exported outside the module has no place here: keep it in the source

• source file

in the src/ tree

Makefile: best practice would be to clone an appropriate Makefile in some src/ subdirectory, and some test/ subdirectory. The Makefile infrastructure is set up so most configuration is automatic, but you have to define:

• RFID := $(shell cd ../..; pwd -P)

(or more ../ , until that path points to the root of MRG).

• MRG_LIB := $(RFID)/lib/libmrg
• default: $(MRG_LIB)
• include $(RFID)/include.mk

If your module has subdirectories, follow the example in e.g. src/ui/ that has two subdirectories, src/ui/impl/ and src/ui/stdin/.

Provide one or more unit tests for all your module's features. Make an appropriate subdirectory or subtree in test/.

Documenting

• In the include file, all macros, enums, types, variables and functions must be documented in Doxygen style. The generated Doxygen documentation will be on the project's web page.

• Nontrivial stuff is documented in the source file. Functions that implement nontrivial algorithms are documented in the source file before the start of the function.

Naming

C has no name spaces, so in an attempt to avoid name collisions, all public identifiers must be prefixed with mrg_<subproject>_ where subproject is a few-letter acronym for the current subproject. Macros are in all-caps, functions and variables are in all-lowercase and use "_" for sub-name separation. Static (non-public) identifiers need not be prefixed, but still beware of name collisions: debuggers tend to not understand.

Make all non-public identifiers static.

Types

Struct and enum types are of this form:

typedef struct MRG_PRJ_BLA {
    ... struct fields ...
} mrg_prj_bla_t;

If a struct contents need not be public, make it an opaque type and define the struct in the source.

Where an integer type of a certain number of bits is necessary, specify that explicitly: uint32_t in stead of unsigned long.

Layout

Use 4 spaces for indent. Use no tabs. Have no whitespace at the end of a line, especially not in blank lines.

Separate functions with 2 blank lines. Separate variable declarations and code with 1 blank line. Mark code structure with a blank line.

Always use braces in if, while etc statements. Single exception:

if (error) return -1;

for an abnormal return

Bracing looks like this:

if (a) {
    ... work along a ...
} else if (b) {
    ... work along b ...
} else {
    ... work elsewise ...
}

static int
func(mrg_prj_bla_t *prj, const char *bla)
{
}

Java code

Packages must live under org.rfidguardian.<package>. Currently, there are two packages: GP, which has the stubs/skeletons generated by the GPc stub compiler and some common hand-written classes; and UI/ME that has the user interface implementation on top of MIDP (aka JavaME). Code must be relevantly javadoc'ed.

Java code style must adhere to Sun's Code Conventions; where that style leaves the option open to use tabs (at 8), our coding style requires spaces in stead of tabs. More more addition: have no whitespace at the end of a line, especially not in blank lines. It is no coincidence that this resembles the C coding style a lot.