You may not like all rules presented here, but they work very well for me and have helped producing high quality code. Everyone is free to code however they want, write and follow their own style guides, but when you contribute to my code, please follow these rules:
This guide does not explain how to write good shell code, but merely how to format it.
-
Use ASCII (UTF-8 is ok in comments, if you have to).
-
Use Unix-style line endings. On the last line of the file, too.
-
If you use a file extension, use
.sh
. Don't use a file extension for executable scripts. -
In general, write valid POSIX /bin/sh. Target POSIX.1-2008 as a base line. Avoid bashisms like
[[
,[ x == y ]
,${::}
,${//}
and arrays. Do not nest${#}
and${%}
. -
Use 1 tab for each level of indentation, 4 spaces for half-indentation.
-
Keep lines fewer than 80 characters, with 8 space tabs.
-
Do not use tabs for aligning, only for indentation. Do not use tabs in the middle of the line.
-
Function names start in column 1. Do not use the function keyword.
myfoo() { ... }
-
No space between function name and arguments.
-
Use empty lines to break up a long functions into logical paragraphs.
-
Break lines after
&&
and||
, do not use explicit line continuations with\
then. -
Put
do
andthen
into the same line as the loop:for f in *; do ... done
if [ ... ]; then ... fi
-
Don't indent switch cases:
case ... in foo) ... ;; bar) ... ;; esac
-
Never use backticks, always use
$()
. -
Avoid trailing whitespace.
-
Use
while :; do ...; done
for infinite loops. -
Use a plain
:
on a line of itself for the empty command. -
Always quote variables that contain external data.
-
Prefer blocks over subshells for plain grouping.
-
Prefer
$(( ... ))
over expr(1). -
Prefer
for arg;
overfor arg in "$@";
. -
Don't use echo (except for the most trivial uses), prefer printf.
-
Never use
[ "x$foo" = x ]
. -
Use
getopts
to parse command line flags.
-
The length of an identifier determines its scope.
-
Use lowercase variables for local scope.
-
Use
SCREAMING_SNAKE_CASE
for exported variables.
-
Comments longer than a word are capitalized and use punctuation. Use two spaces after periods.
-
Use at least two spaces before end-of-line comments in a code line.
-
Avoid superfluous comments.
-
Avoid long functions.
-
Avoid long parameter lists.
-
Keep the code simple.
-
Don't overdesign.
-
Don't underdesign.
-
Avoid bugs.
-
Read other style guides and apply the parts that don't dissent with this list.
-
Be consistent.
-
Use common sense.