judgement call, the decision based more on real world
constraints people face than what the paper standard says.
+Make your code readable and sensible, and don't try to be clever.
As for more concrete guidelines, just imitate the existing code
(this is a good guideline, no matter which project you are
E.g.: my_function () {
- As to use of grep, stick to a subset of BRE (namely, no \{m,n\},
- [::], [==], nor [..]) for portability.
+ [::], [==], or [..]) for portability.
- We do not use \{m,n\};
- We do not use -E;
- - We do not use ? nor + (which are \{0,1\} and \{1,\}
+ - We do not use ? or + (which are \{0,1\} and \{1,\}
respectively in BRE) but that goes without saying as these
are ERE elements not BRE (note that \? and \+ are not even part
of BRE -- making them accessible from BRE is a GNU extension).
"char * string". This makes it easier to understand code
like "char *string, c;".
+ - Use whitespace around operators and keywords, but not inside
+ parentheses and not around functions. So:
+
+ while (condition)
+ func(bar + 1);
+
+ and not:
+
+ while( condition )
+ func (bar+1);
+
- We avoid using braces unnecessarily. I.e.
if (bla) {
they were describing changes. Often splitting a function
into two makes the intention of the code much clearer.
+ - Multi-line comments include their delimiters on separate lines from
+ the text. E.g.
+
+ /*
+ * A very long
+ * multi-line comment.
+ */
+
+ Note however that a comment that explains a translatable string to
+ translators uses a convention of starting with a magic token
+ "TRANSLATORS: " immediately after the opening delimiter, even when
+ it spans multiple lines. We do not add an asterisk at the beginning
+ of each line, either. E.g.
+
+ /* TRANSLATORS: here is a comment that explains the string
+ to be translated, that follows immediately after it */
+ _("Here is a translatable string explained by the above.");
+
- Double negation is often harder to understand than no negation
at all.
- Use Git's gettext wrappers to make the user interface
translatable. See "Marking strings for translation" in po/README.
+For Perl programs:
+
+ - Most of the C guidelines above apply.
+
+ - We try to support Perl 5.8 and later ("use Perl 5.008").
+
+ - use strict and use warnings are strongly preferred.
+
+ - Don't overuse statement modifiers unless using them makes the
+ result easier to follow.
+
+ ... do something ...
+ do_this() unless (condition);
+ ... do something else ...
+
+ is more readable than:
+
+ ... do something ...
+ unless (condition) {
+ do_this();
+ }
+ ... do something else ...
+
+ *only* when the condition is so rare that do_this() will be almost
+ always called.
+
+ - We try to avoid assignments inside "if ()" conditions.
+
+ - Learn and use Git.pm if you need that functionality.
+
+ - For Emacs, it's useful to put the following in
+ GIT_CHECKOUT/.dir-locals.el, assuming you use cperl-mode:
+
+ ;; note the first part is useful for C editing, too
+ ((nil . ((indent-tabs-mode . t)
+ (tab-width . 8)
+ (fill-column . 80)))
+ (cperl-mode . ((cperl-indent-level . 8)
+ (cperl-extra-newline-before-brace . nil)
+ (cperl-merge-trailing-else . t))))
+
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+ also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+ literals, it is OK to use the 'b' prefix. Even though the Python
+ documentation for version 2.6 does not mention this prefix, it has
+ been supported since version 2.6.0.
+
Writing Documentation:
+ Most (if not all) of the documentation pages are written in the
+ AsciiDoc format in *.txt files (e.g. Documentation/git.txt), and
+ processed into HTML and manpages (e.g. git.html and git.1 in the
+ same directory).
+
+ The documentation liberally mixes US and UK English (en_US/UK)
+ norms for spelling and grammar, which is somewhat unfortunate.
+ In an ideal world, it would have been better if it consistently
+ used only one and not the other, and we would have picked en_US
+ (if you wish to correct the English of some of the existing
+ documentation, please see the documentation-related advice in the
+ Documentation/SubmittingPatches file).
+
Every user-visible change should be reflected in the documentation.
The same general rule as for code applies -- imitate the existing
- conventions. A few commented examples follow to provide reference
- when writing or modifying command usage strings and synopsis sections
- in the manual pages:
+ conventions.
+
+ A few commented examples follow to provide reference when writing or
+ modifying command usage strings and synopsis sections in the manual
+ pages:
Placeholders are spelled in lowercase and enclosed in angle brackets:
<file>
Use 'git' (all lowercase) when talking about commands i.e. something
the user would type into a shell and use 'Git' (uppercase first letter)
when talking about the version control system and its properties.
+
+ A few commented examples follow to provide reference when writing or
+ modifying paragraphs or option/command explanations that contain options
+ or commands:
+
+ Literal examples (e.g. use of command-line options, command names, and
+ configuration variables) are typeset in monospace, and if you can use
+ `backticks around word phrases`, do so.
+ `--pretty=oneline`
+ `git rev-list`
+ `remote.pushdefault`
+
+ Word phrases enclosed in `backtick characters` are rendered literally
+ and will not be further expanded. The use of `backticks` to achieve the
+ previous rule means that literal examples should not use AsciiDoc
+ escapes.
+ Correct:
+ `--pretty=oneline`
+ Incorrect:
+ `\--pretty=oneline`
+
+ If some place in the documentation needs to typeset a command usage
+ example with inline substitutions, it is fine to use +monospaced and
+ inline substituted text+ instead of `monospaced literal text`, and with
+ the former, the part that should not get substituted must be
+ quoted/escaped.