Coding Standards » History » Version 23

Ward Vandewege, 05/22/2018 08:27 PM

1 1 Tom Clegg
h1. Coding Standards
2 1 Tom Clegg
3 3 Tom Clegg
The rules are always up for debate. However, when debate is needed, it should happen outside the source tree. In other words, if the rules are wrong, first debate the rules in IRC etc., then fix the rules, then follow the new rules.
4 1 Tom Clegg
5 2 Tom Clegg
{{toc}}
6 1 Tom Clegg
7 2 Tom Clegg
h2. Git commits
8 2 Tom Clegg
9 1 Tom Clegg
Make sure your name and email address are correct.
10 1 Tom Clegg
11 1 Tom Clegg
* Use @git config --global user.email foo@example.com@ et al.
12 1 Tom Clegg
* It's a little unfortunate to have commits with author @foo@myworkstation.local@ but not bad enough to rewrite history, so fix this before you push!
13 1 Tom Clegg
14 19 Tom Clegg
Refer to a story number in the first (summary) line of each commit comment. This first line should be <80 chars long, and should be followed by a blank line.
15 9 Tom Clegg
16 9 Tom Clegg
* @1234: Remove useless button.@
17 9 Tom Clegg
18 9 Tom Clegg
*When merging/committing to master,* refer to the story number in a way Redmine will notice. Redmine will list these commits/merges on the story page itself.
19 9 Tom Clegg
20 1 Tom Clegg
* @closes #1234@, or
21 19 Tom Clegg
* @refs #1234@, or
22 19 Tom Clegg
* @no issue #@ if no Redmine issue is especially relevant.
23 9 Tom Clegg
24 1 Tom Clegg
Use descriptive commit comments.
25 1 Tom Clegg
26 1 Tom Clegg
* Describe the delta between the old and new tree. If possible, describe the delta in *behavior* rather than the source code itself.
27 9 Tom Clegg
* Good: "1234: Support use of spaces in filenames."
28 9 Tom Clegg
* Good: "1234: Fix crash when user_id is nil."
29 1 Tom Clegg
* Less good: "Add some controller methods." (What do they do?)
30 1 Tom Clegg
* Less good: "More progress on UI branch." (What is different?)
31 1 Tom Clegg
* Less good: "Incorporate Tom's suggestions." (Who cares whose suggestions -- what changed?)
32 1 Tom Clegg
33 1 Tom Clegg
If further background or explanation is needed, separate it from the summary with a blank line.
34 1 Tom Clegg
35 1 Tom Clegg
* Example: "Users found it confusing that the boxes had different colors even though they represented the same kinds of things."
36 1 Tom Clegg
37 18 Tom Clegg
*Every commit* (even merge commits) must have a DCO sign-off. See [[Developer Certificate Of Origin]].
38 1 Tom Clegg
39 1 Tom Clegg
* Example: <code>Arvados-DCO-1.1-Signed-off-by: Joe Smith <joe.smith@example.com></code>
40 19 Tom Clegg
41 19 Tom Clegg
Full examples:
42 19 Tom Clegg
43 19 Tom Clegg
<pre>
44 19 Tom Clegg
commit 9c6540b9d42adc4a397a28be1ac23f357ba14ab5
45 19 Tom Clegg
Author: Tom Clegg <tom@curoverse.com>
46 19 Tom Clegg
Date:   Mon Aug 7 09:58:04 2017 -0400
47 19 Tom Clegg
48 19 Tom Clegg
    12027: Recognize a new "node failed" error message.
49 19 Tom Clegg
    
50 19 Tom Clegg
    "srun: error: Cannot communicate with node 0.  Aborting job."
51 19 Tom Clegg
    
52 19 Tom Clegg
    Arvados-DCO-1.1-Signed-off-by: Tom Clegg <tom@curoverse.com>
53 19 Tom Clegg
</pre>
54 19 Tom Clegg
55 19 Tom Clegg
<pre>
56 19 Tom Clegg
commit 0b4800608e6394d66deec9cecea610c5fbbd75ad
57 19 Tom Clegg
Merge: 6f2ce94 3a356c4
58 19 Tom Clegg
Author: Tom Clegg <tom@curoverse.com>
59 19 Tom Clegg
Date:   Thu Aug 17 13:16:36 2017 -0400
60 19 Tom Clegg
61 19 Tom Clegg
    Merge branch '12081-crunch-job-retry'
62 19 Tom Clegg
    
63 19 Tom Clegg
    refs #12080
64 19 Tom Clegg
    refs #12081
65 19 Tom Clegg
    refs #12108
66 19 Tom Clegg
    
67 19 Tom Clegg
    Arvados-DCO-1.1-Signed-off-by: Tom Clegg <tom@curoverse.com>
68 19 Tom Clegg
</pre>
69 19 Tom Clegg
70 21 Ward Vandewege
h2. Copyright headers
71 21 Ward Vandewege
72 23 Ward Vandewege
Each Arvados component is released either under the AGPL 3.0 license or the Apache 2.0 license. Documentation is licensed under CC-BY-SA-3.0. See the [[Arvados Licenses FAQ]] for the rationale behind this system.
73 21 Ward Vandewege
74 22 Ward Vandewege
Every file must start with a copyright header that follows this format:
75 21 Ward Vandewege
76 21 Ward Vandewege
Code under the "AGPLv3 license":http://www.gnu.org/licenses/agpl-3.0.en.html (this example uses Go formatting):
77 21 Ward Vandewege
78 21 Ward Vandewege
<pre>
79 21 Ward Vandewege
// Copyright (C) The Arvados Authors. All rights reserved.
80 21 Ward Vandewege
//
81 21 Ward Vandewege
// SPDX-License-Identifier: AGPL-3.0
82 21 Ward Vandewege
</pre>
83 21 Ward Vandewege
84 21 Ward Vandewege
Code under the "Apache 2.0 license":http://www.apache.org/licenses/LICENSE-2.0 (this example uses Python formatting):
85 21 Ward Vandewege
86 21 Ward Vandewege
<pre>
87 21 Ward Vandewege
# Copyright (C) The Arvados Authors. All rights reserved.
88 21 Ward Vandewege
#
89 21 Ward Vandewege
# SPDX-License-Identifier: Apache-2.0
90 21 Ward Vandewege
</pre>
91 21 Ward Vandewege
92 21 Ward Vandewege
Documentation under the "Creative Commons Attribution-Share Alike 3.0 United States license":https://creativecommons.org/licenses/by-sa/3.0/us/ (this example uses textile formatting):
93 21 Ward Vandewege
94 21 Ward Vandewege
<pre>
95 21 Ward Vandewege
###. Copyright (C) The Arvados Authors. All rights reserved.
96 21 Ward Vandewege
....
97 21 Ward Vandewege
.... SPDX-License-Identifier: CC-BY-SA-3.0
98 21 Ward Vandewege
</pre>
99 21 Ward Vandewege
100 1 Tom Clegg
When adding a new file to a component, use the same license as the other files of the component.
101 1 Tom Clegg
102 22 Ward Vandewege
When adding a new component, choose either the AGPL or Apache license. Generally speaking, the Apache license is only used for components where integrations in proprietary code must be possible (e.g. our SDKs), though this is not a hard rule. When uncertain which license to choose for a new component, ask on the IRC channel or mailing list.
103 21 Ward Vandewege
104 22 Ward Vandewege
When adding a file in a format that does not support the addition of a copyright header (e.g. in a binary format like an image), add the path to the .licenseignore file in the root of the source tree. This should be done sparingly, and must be discussed explicitly as part of code review. The file must be available under a license that is compatible with the rest of the Arvados code base.
105 21 Ward Vandewege
106 22 Ward Vandewege
When adding a file that originates from an external source under a different license, add the appropriate SPDX line for that license. This is exceptional, and must be discussed explicitly as part of code review. Not every license is compatible with the rest of the Arvados code base.
107 16 Tom Clegg
108 13 Tom Clegg
h2. Source code formatting
109 1 Tom Clegg
110 13 Tom Clegg
(Unless otherwise specified by style guide...)
111 13 Tom Clegg
112 10 Tom Clegg
No TAB characters in source files. "Except go programs.":https://golang.org/cmd/gofmt/
113 1 Tom Clegg
114 6 Tom Clegg
* Emacs: add to @~/.emacs@ &rarr; @(setq-default indent-tabs-mode nil)@
115 6 Tom Clegg
* Vim: add to @~/.vimrc@ &rarr; @:set expandtab@
116 8 Tom Clegg
* See [[Coding Standards#Git setup|Git setup]] below
117 4 Ward Vandewege
118 6 Tom Clegg
No inline comments: @this = !desired; # we don't want to do it.@
119 4 Ward Vandewege
120 6 Tom Clegg
No long (>80 column) lines, except in rare cases when the alternative is really clunky.
121 6 Tom Clegg
122 4 Ward Vandewege
No whitespace at the end of lines. Make git-diff show you:
123 5 Ward Vandewege
124 5 Ward Vandewege
  git config color.diff.whitespace "red reverse"
125 6 Tom Clegg
git diff --check
126 1 Tom Clegg
127 13 Tom Clegg
h2. What to include
128 13 Tom Clegg
129 1 Tom Clegg
No commented-out blocks of code that have been replaced or obsoleted.
130 1 Tom Clegg
131 1 Tom Clegg
* It is in the git history if we want it back.
132 1 Tom Clegg
* If its absence would confuse someone reading the new code (despite never having read the old code), explain its absence in an English comment. If the old code is really still needed to support the English explanation, then go ahead -- now we know why it's there.
133 1 Tom Clegg
134 1 Tom Clegg
No commented-out debug statements.
135 1 Tom Clegg
136 1 Tom Clegg
* If the debug statements are likely to be needed in the future, use a logging facility that can be enabled at run time. @logger.debug "foo"@
137 1 Tom Clegg
138 13 Tom Clegg
h2. Style mismatch
139 13 Tom Clegg
140 1 Tom Clegg
Adopt indentation style of surrounding lines or (when starting a new file) the nearest existing source code in this tree/language.
141 1 Tom Clegg
142 1 Tom Clegg
If you fix up existing indentation/formatting, do that in a separate commit.
143 1 Tom Clegg
* If you bundle formatting changes with functional changes, it makes functional changes hard to find in the diff.
144 1 Tom Clegg
145 13 Tom Clegg
h2. Go
146 13 Tom Clegg
147 13 Tom Clegg
gofmt, golint, etc., and https://github.com/golang/go/wiki/CodeReviewComments
148 13 Tom Clegg
149 13 Tom Clegg
h2. Ruby
150 13 Tom Clegg
151 13 Tom Clegg
https://github.com/bbatsov/ruby-style-guide
152 13 Tom Clegg
153 1 Tom Clegg
h2. Python
154 13 Tom Clegg
155 13 Tom Clegg
PEP-8.
156 12 Tom Clegg
157 12 Tom Clegg
Tell Emacs you don't want a blank line at the end of a multiline docstring.
158 12 Tom Clegg
159 12 Tom Clegg
    (setq python-fill-docstring-style 'pep-257-nn)
160 12 Tom Clegg
161 11 Brett Smith
h2. JavaScript
162 11 Brett Smith
163 20 Tom Clegg
Follow the Airbnb Javascript coding style guide unless otherwise stated:
164 14 Tom Morris
https://github.com/airbnb/javascript
165 20 Tom Clegg
166 20 Tom Clegg
We already have 4-space indents everywhere, though, so do that.
167 20 Tom Clegg
168 14 Tom Morris
169 7 Tom Clegg
h2. Git setup
170 6 Tom Clegg
171 7 Tom Clegg
Configure git to prevent you from committing whitespace errors.
172 1 Tom Clegg
173 6 Tom Clegg
<pre>
174 7 Tom Clegg
git config --global core.whitespace tab-in-indent,trailing-space
175 1 Tom Clegg
git config --global apply.whitespace error
176 17 Tom Clegg
</pre>
177 17 Tom Clegg
178 17 Tom Clegg
Add a DCO sign-off to the default commit message.
179 17 Tom Clegg
180 17 Tom Clegg
<pre>
181 17 Tom Clegg
cd .../arvados
182 17 Tom Clegg
printf '\n\nArvados-DCO-1.1-Signed-off-by: %s <%s>\n' "$(git config user.name)" "$(git config user.email)" >~/.arvados-dco.txt
183 17 Tom Clegg
git config commit.template ~/.arvados-dco.txt
184 17 Tom Clegg
</pre>
185 17 Tom Clegg
186 17 Tom Clegg
Add a DCO sign-off and "refs #xxxx" comment (referencing the issue# in the name of the branch being merged) to the default merge commit message.
187 17 Tom Clegg
188 17 Tom Clegg
<pre>
189 17 Tom Clegg
cd .../arvados
190 17 Tom Clegg
cat >.git/hooks/prepare-commit-message <<'EOF'
191 17 Tom Clegg
#!/bin/sh
192 17 Tom Clegg
193 17 Tom Clegg
case "$2,$3" in
194 17 Tom Clegg
    merge,)
195 17 Tom Clegg
        br=$(head -n1 ${1})
196 17 Tom Clegg
        n=$(echo "${br}" | egrep -o '[0-9]+')
197 17 Tom Clegg
        exec >${1}
198 17 Tom Clegg
        echo "${br}"
199 17 Tom Clegg
        echo
200 17 Tom Clegg
        echo "refs #${n}"
201 17 Tom Clegg
        echo
202 17 Tom Clegg
        echo "Arvados-DCO-1.1-Signed-off-by: ${GIT_AUTHOR_NAME} <${GIT_AUTHOR_EMAIL}>"
203 17 Tom Clegg
        ;;
204 17 Tom Clegg
    *)
205 17 Tom Clegg
        ;;
206 17 Tom Clegg
esac
207 17 Tom Clegg
EOF
208 17 Tom Clegg
chmod +x .git/hooks/prepare-commit-message
209 6 Tom Clegg
</pre>