]> CrystFEL coding standards 3 Coding standards This page documents the coding conventions used within the CrystFEL source code. Read these to help when reading the code or before making modifications destined to be sent upstream. CrystFEL is distributed under the terms of the GNU General Public License version 3 or higher. Contributions are very welcome provided they also use this license. Whenever you edit a source file, don't forget to update the copyright dates at the top. Add your name and email address if they're not there already. Be sure to add your name to the 'AUTHORS' file in the top level folder, as well. Indentation is done with tabs and alignment is done with spaces. This way, the code looks neat whatever width you configure your editor to display tabs as. This means, for example: struct something { int thing; /* <--- spaces used to align comments */ int thing_with_longer_name; /* <--- spaces used to align comments */ } void somefunction(int something) { /* <--- Tab character used at the start of this line */ } However, code must be strictly wrapped at 80 columns, or what would be 80 columns if the tabs were displayed as 8 spaces. If you think you need more width, you're at too many levels of indentation and need to break things down a bit. There are no exceptions whatsoever. When performing a two or three dimensional iteration, for example over image coordinates or Miller indices, it is acceptable to indent as follows: for ( h=-10; h<+10; h++ ) { for ( k=-10; k<+10; k++ ) { for ( l=-10; l<+10; l++ ) { /* Do stuff */ } } } Brackets and so on should go like this: /* Multiple line comments have stars * down one side */ void somefunction(int someparam) { /* Single line comments use this style (not //) */ if ( a < b ) { /* 'if' statements usually have the opening brace on the same * line as the condition. */ } else { /* 'else's are 'cuddled' */ } if ( some && very && long && condition && that && spans && two && lines ) { /* Opening brace is on a line by itself in the case of a very * long condition */ } } /* Comments use proper capitalisation to make things look neat */ 'struct' blocks can have the braces like functions or 'if' statements. Usually the former looks nicer if the struct is large. Parentheses should have spaces after them in 'if' statements, but not in function calls. Function arguments should have spaces after the comma. There should be no space between the function name and the opening bracket. That means: if ( something ) { do_something(a, b, c); } instead of: if (something) { do_something (a,b,c); } Yes, we all know you can insert a new node into an RB-tree while simultaneously calculating Pi to 150 decimal places in one line of code. You don't need to prove it here. As a general rule, if you think you're about to do something clever, don't do it at all. The first line of your commit message should include a one line summary of the changes, in the form "Do XYZ". That is, not "Did XYZ". Make the minimum possible changes in each commit. Try to really distill your changes down to the bare bones, and keep 'cleaning up' in separate commits. Remember that Git thinks about 'changes' rather than 'versions'. Despite your following all of the above, I will probably still touch up your code in some places while (or shortly after) integrating it into mainline CrystFEL. Please try not to take it personally.