X-Git-Url: https://git.tokkee.org/?a=blobdiff_plain;f=Documentation%2FCodingGuidelines;h=09ffc46563cba1057b37ba4a5701858fb95c5dda;hb=5cb3c9b7dff15f762d63df0b6f2d6b4bf82565e9;hp=0d7fa9cca9e5c3ec8a11cd2c878f5a7afe353abe;hpb=cd12f536129357d5347c1953db69bde68b5f46c9;p=git.git diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 0d7fa9cca..fe1c1e5bc 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -31,25 +31,36 @@ But if you must have a list of rules, here they are. For shell scripts specifically (not exhaustive): + - We use tabs for indentation. + + - Case arms are indented at the same depth as case and esac lines. + - We prefer $( ... ) for command substitution; unlike ``, it properly nests. It should have been the way Bourne spelled it from day one, but unfortunately isn't. - - We use ${parameter-word} and its [-=?+] siblings, and their - colon'ed "unset or null" form. + - We use POSIX compliant parameter substitutions and avoid bashisms; + namely: - - We use ${parameter#word} and its [#%] siblings, and their - doubled "longest matching" form. + - We use ${parameter-word} and its [-=?+] siblings, and their + colon'ed "unset or null" form. - - We use Arithmetic Expansion $(( ... )). + - We use ${parameter#word} and its [#%] siblings, and their + doubled "longest matching" form. + + - No "Substring Expansion" ${parameter:offset:length}. + + - No shell arrays. - - No "Substring Expansion" ${parameter:offset:length}. + - No strlen ${#parameter}. - - No shell arrays. + - No pattern replacement ${parameter/pattern/string}. - - No strlen ${#parameter}. + - We use Arithmetic Expansion $(( ... )). - - No regexp ${parameter/pattern/string}. + - Inside Arithmetic Expansion, spell shell variables with $ in front + of them, as some shells do not grok $((x)) while accepting $(($x)) + just fine (e.g. dash older than 0.5.4). - We do not use Process Substitution <(list) or >(list). @@ -129,3 +140,58 @@ For C programs: used in the git core command set (unless your command is clearly separate from it, such as an importer to convert random-scm-X repositories to git). + + - When we pass pair to functions, we should try to + pass them in that order. + +Writing Documentation: + + 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: + + Placeholders are spelled in lowercase and enclosed in angle brackets: + + --sort= + --abbrev[=] + + Possibility of multiple occurrences is indicated by three dots: + ... + (One or more of .) + + Optional parts are enclosed in square brackets: + [] + (Zero or one .) + + --exec-path[=] + (Option with an optional argument. Note that the "=" is inside the + brackets.) + + [...] + (Zero or more of . Note that the dots are inside, not + outside the brackets.) + + Multiple alternatives are indicated with vertical bar: + [-q | --quiet] + [--utf8 | --no-utf8] + + Parentheses are used for grouping: + [(|)...] + (Any number of either or . Parens are needed to make + it clear that "..." pertains to both and .) + + [(-p )...] + (Any number of option -p, each with one argument.) + + git remote set-head (-a | -d | ) + (One and only one of "-a", "-d" or "" _must_ (no square + brackets) be provided.) + + And a somewhat more contrived example: + --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]] + Here "=" is outside the brackets, because "--diff-filter=" is a + valid usage. "*" has its own pair of brackets, because it can + (optionally) be specified only when one or more of the letters is + also provided.