Cellular Network Infrastructure

h1. Osmocom coding standards

h1. Coding Style

In general, for the C-language projects we maintain in the Osmocom project, we follow the coding style

of the Linux kenrel. See https://www.kernel.org/doc/Documentation/CodingStyle for further information.

We will not debate about the coding style and whether some other style is better or worse.  The important factor is not so much _which_ coding style is followed, as long as there is one well-defined coding style and that all developers adhere to it.

h2. Submitting Patches

For submitting patches, the best practises established by the Linux kernel development community should  be followed, whenever applicable.  See https://www.kernel.org/doc/Documentation/SubmittingPatches for further information.

The generally important topics are:

h3. Submit patches against a current source tree

At time of submission, our patches should be based on current @master@ branch of the respective project, or another (more current) feature branch of that repository.

h3. Use unified diff format

It's best to let git generate the patches, so you don't have to worry about that.

h3. Have meaningful descriptions in your patches

Every commit/patch should have an explanation in the commit message.

h3. Separate your changes

Separate each _logical change_ into a separate patch.

h3. Respond to review comments

h3. Include PATCH in the subject

h2. Rules of thumb

Some general rules of thumb:

* Consider using tools like @Lindent@ and @checkpatch.pl@ or @universalindentgui@ before submitting code

* Run @make@, @make check@ and @make distcheck@ on each of your commits to ensure the build

* Use @git send-email@ or @git imap-send@ to send your patches (otherwise your mail client may wrap around lines and corrupt your patch)