Coding standards » History » Revision 8
Revision 7 (Anonymous, 02/19/2016 10:48 PM) → Revision 8/37 (laforge, 02/21/2016 02:06 PM)
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 Read 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@ Lindent and @checkpatch.pl@ checkpatch.pl or @universalindentgui@ before submitting code universalindentgui. * Run @make@, @make check@ make, make check and @make distcheck@ make distcheck on each of your commits to ensure the build * Use @git send-email@ git send-email or @git imap-send@ git imap-send to send your patches (otherwise your mail client may wrap around lines and corrupt your patch)
