Coding Standards » History » Version 24

Ward Vandewege, 05/24/2018 02:42 AM

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 24 Ward Vandewege
There is a helper script at https://github.com/curoverse/arvados/blob/master/build/check-copyright-notices that can be used to check - and optionally, fix - the copyright headers in the Arvados source tree.
109 24 Ward Vandewege
110 13 Tom Clegg
h2. Source code formatting
111 1 Tom Clegg
112 13 Tom Clegg
(Unless otherwise specified by style guide...)
113 13 Tom Clegg
114 10 Tom Clegg
No TAB characters in source files. "Except go programs.":https://golang.org/cmd/gofmt/
115 1 Tom Clegg
116 6 Tom Clegg
* Emacs: add to @~/.emacs@ &rarr; @(setq-default indent-tabs-mode nil)@
117 6 Tom Clegg
* Vim: add to @~/.vimrc@ &rarr; @:set expandtab@
118 8 Tom Clegg
* See [[Coding Standards#Git setup|Git setup]] below
119 4 Ward Vandewege
120 6 Tom Clegg
No inline comments: @this = !desired; # we don't want to do it.@
121 4 Ward Vandewege
122 6 Tom Clegg
No long (>80 column) lines, except in rare cases when the alternative is really clunky.
123 6 Tom Clegg
124 4 Ward Vandewege
No whitespace at the end of lines. Make git-diff show you:
125 5 Ward Vandewege
126 5 Ward Vandewege
  git config color.diff.whitespace "red reverse"
127 6 Tom Clegg
git diff --check
128 1 Tom Clegg
129 13 Tom Clegg
h2. What to include
130 13 Tom Clegg
131 1 Tom Clegg
No commented-out blocks of code that have been replaced or obsoleted.
132 1 Tom Clegg
133 1 Tom Clegg
* It is in the git history if we want it back.
134 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.
135 1 Tom Clegg
136 1 Tom Clegg
No commented-out debug statements.
137 1 Tom Clegg
138 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"@
139 1 Tom Clegg
140 13 Tom Clegg
h2. Style mismatch
141 13 Tom Clegg
142 1 Tom Clegg
Adopt indentation style of surrounding lines or (when starting a new file) the nearest existing source code in this tree/language.
143 1 Tom Clegg
144 1 Tom Clegg
If you fix up existing indentation/formatting, do that in a separate commit.
145 1 Tom Clegg
* If you bundle formatting changes with functional changes, it makes functional changes hard to find in the diff.
146 1 Tom Clegg
147 13 Tom Clegg
h2. Go
148 13 Tom Clegg
149 13 Tom Clegg
gofmt, golint, etc., and https://github.com/golang/go/wiki/CodeReviewComments
150 13 Tom Clegg
151 13 Tom Clegg
h2. Ruby
152 13 Tom Clegg
153 13 Tom Clegg
https://github.com/bbatsov/ruby-style-guide
154 13 Tom Clegg
155 1 Tom Clegg
h2. Python
156 13 Tom Clegg
157 13 Tom Clegg
PEP-8.
158 12 Tom Clegg
159 12 Tom Clegg
Tell Emacs you don't want a blank line at the end of a multiline docstring.
160 12 Tom Clegg
161 12 Tom Clegg
    (setq python-fill-docstring-style 'pep-257-nn)
162 12 Tom Clegg
163 11 Brett Smith
h2. JavaScript
164 11 Brett Smith
165 20 Tom Clegg
Follow the Airbnb Javascript coding style guide unless otherwise stated:
166 14 Tom Morris
https://github.com/airbnb/javascript
167 20 Tom Clegg
168 20 Tom Clegg
We already have 4-space indents everywhere, though, so do that.
169 20 Tom Clegg
170 14 Tom Morris
171 7 Tom Clegg
h2. Git setup
172 6 Tom Clegg
173 7 Tom Clegg
Configure git to prevent you from committing whitespace errors.
174 1 Tom Clegg
175 6 Tom Clegg
<pre>
176 7 Tom Clegg
git config --global core.whitespace tab-in-indent,trailing-space
177 1 Tom Clegg
git config --global apply.whitespace error
178 17 Tom Clegg
</pre>
179 17 Tom Clegg
180 17 Tom Clegg
Add a DCO sign-off to the default commit message.
181 17 Tom Clegg
182 17 Tom Clegg
<pre>
183 17 Tom Clegg
cd .../arvados
184 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
185 17 Tom Clegg
git config commit.template ~/.arvados-dco.txt
186 17 Tom Clegg
</pre>
187 17 Tom Clegg
188 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.
189 17 Tom Clegg
190 17 Tom Clegg
<pre>
191 17 Tom Clegg
cd .../arvados
192 17 Tom Clegg
cat >.git/hooks/prepare-commit-message <<'EOF'
193 17 Tom Clegg
#!/bin/sh
194 17 Tom Clegg
195 17 Tom Clegg
case "$2,$3" in
196 17 Tom Clegg
    merge,)
197 17 Tom Clegg
        br=$(head -n1 ${1})
198 17 Tom Clegg
        n=$(echo "${br}" | egrep -o '[0-9]+')
199 17 Tom Clegg
        exec >${1}
200 17 Tom Clegg
        echo "${br}"
201 17 Tom Clegg
        echo
202 17 Tom Clegg
        echo "refs #${n}"
203 17 Tom Clegg
        echo
204 17 Tom Clegg
        echo "Arvados-DCO-1.1-Signed-off-by: ${GIT_AUTHOR_NAME} <${GIT_AUTHOR_EMAIL}>"
205 17 Tom Clegg
        ;;
206 17 Tom Clegg
    *)
207 17 Tom Clegg
        ;;
208 17 Tom Clegg
esac
209 17 Tom Clegg
EOF
210 17 Tom Clegg
chmod +x .git/hooks/prepare-commit-message
211 6 Tom Clegg
</pre>