1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd"
[
<!ENTITY % local.common.attrib "xmlns:xi CDATA #FIXED 'http://www.w3.org/2003/XInclude'">
]>
<refentry id="CrystFEL-coding-standards">
<refmeta>
<refentrytitle role="top_of_page" id="CrystFEL-coding-standards.top_of_page">CrystFEL coding standards</refentrytitle>
<manvolnum>3</manvolnum>
<refmiscinfo>
Coding standards
</refmiscinfo>
</refmeta>
<refnamediv></refnamediv>
<refsect1 id="CrystFEL-coding-standards.description" role="desc">
<title role="desc.title">Summary</title>
<para>
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.
</para>
</refsect1>
<refsect1 id="CrystFEL-coding-standards.license">
<title>Licensing and copyright</title>
<para>
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.
</para>
<para>
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.
</para>
</refsect1>
<refsect1 id="CrystFEL-coding-standards.formatting">
<title>Formatting</title>
<para>
<emphasis>Indentation</emphasis> is done with <emphasis>tabs</emphasis> and
<emphasis>alignment</emphasis> is done with spaces. This way, the code looks
neat whatever width you configure your editor to display tabs as. This means,
for example:
</para>
<para>
<programlisting>
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 */
}
</programlisting>
</para>
<para>
However, code must be <emphasis>strictly</emphasis> 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.
</para>
<para>
When performing a two or three dimensional iteration, for example over image
coordinates or Miller indices, it is acceptable to indent as follows:
</para>
<para>
<programlisting>
for ( h=-10; h<+10; h++ ) {
for ( k=-10; k<+10; k++ ) {
for ( l=-10; l<+10; l++ ) {
/* Do stuff */
}
}
}
</programlisting>
</para>
</refsect1>
<refsect1 id="CrystFEL-coding-standards.brackets">
<title>Brackets and so on</title>
<para>
Brackets and so on should go like this:
</para>
<para>
<programlisting>
/* 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 */
</programlisting>
</para>
<para>'struct' blocks can have the braces like functions or 'if' statements. Usually the former looks nicer if the struct is large.</para>
<para>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:</para>
<para><programlisting>
if ( something ) {
do_something(a, b, c);
}
</programlisting></para>
<para>instead of:</para>
<para><programlisting>
if (something) {
do_something (a,b,c);
}
</programlisting></para>
</refsect1>
<refsect1 id="CrystFEL-coding-standards.cleverness">
<title>Cleverness</title>
<para>
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, <emphasis>don't do it at all</emphasis>.
</para>
</refsect1>
<refsect1 id="CrystFEL-coding-standards.commitmessages">
<title>VCS commit messages</title>
<para>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".</para>
<para>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'.</para>
</refsect1>
<refsect1 id="CrystFEL-coding-standards.evilness">
<title>Evil dictator</title>
<para>
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.
</para>
</refsect1>
</refentry>
|
