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 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 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 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) 
Add picture from clipboard (Maximum size: 48.8 MB)