* General

  For this project, we are using the Linux kernel coding style, with a
  bit of latitude, as described below. The kernel style can be quickly
  summarized like this:

  - text width is 80 columns
  - indentation by tabs
  - tab width is 8 spaces
  - identifiers are lower case with underscores
  - macros are upper case
  - braces and spacing follow K&R style

* Using checkpatch.pl

  You can use the Linux kernel's checkpatch.pl script to sanity check
  your work. Sometimes that script warns about code which is in fact
  fine, so use your good taste. I use the following code as my
  pre-commit hook.

#+BEGIN_EXAMPLE
if git rev-parse --verify HEAD >/dev/null 2>&1
then
	against=HEAD
else
	# Initial commit: diff against an empty tree object
	against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi

git diff --cached $against -- | ../linux/scripts/checkpatch.pl \
	--ignore BRACES \
	--ignore PREFER_PR_LEVEL \
	--no-signoff \
	-
#+END_EXAMPLE

* Exceptions

** Use of lowerCamelCase and UpperCamelCase

   The messages and data sets in the PTP and gPTP standards are full
   of stuff that looks a bit like C-language pseudo code, and all this
   is unfortunately in camel case. In those cases where the linuxptp
   code is closely related to these fields, we retain the camel case,
   even though it hurts our eyes to look at.

   The alternative would have been to convert the field names into
   lower case underscore, but that would have over extended the
   already ridiculously long names, such as logMinPdelayReqInterval
   and observedParentOffsetScaledLogVariance.

   The exception permitting CamelCase applies primarily to the
   declarations found in the following header files.

   - ddt.h
   - ds.h
   - msg.h
   - pdt.h
   - tlv.h

** Braces around single if-else bodies

   In the Linux kernel style, if-else bodies containing just a single
   line are not placed within curly braces. Therefore you will often
   see code like the following example.

#+BEGIN_EXAMPLE
	if (!x)
		do_zero();
	else
		do_nonzero();
#+END_EXAMPLE

   In this situation we still like to see the braces, the rationale
   being that the if-else bodies tend to accumulate new statements
   over time, especially on the error path. Using the strict kernel
   style thus results in patches (and annotated views) that show a
   bogus change in the test expression, and this requires extra mental
   effort when reviewing patches, just to realize that no logical
   change has occurred. Additionally, having the braces hardly uses up
   more vertical space than not having them, so we generally include
   them as shown in the following example.

#+BEGIN_EXAMPLE
	if (!x) {
		do_zero();
	} else {
		do_nonzero();
	}
#+END_EXAMPLE

** Line lengths

   We try to keep the line length to 80 characters wide. However,
   sometimes it happens that, no matter how hard we try, we find
   ourselves going a bit over that limit. This is especially true in
   connection with the long CamelCase identifiers mentioned above.
   Breaking a statement over two lines can look even worse than having
   one line too long, so please exercise judgement when applying the
   line length rule.