15. Coding Style

This chapter documents the coding style used in live systems.

15.1 Compatibility

• Don't use syntax or semantics that are unique to the Bash shell. For example, the use of array constructs.

• Only use the POSIX subset - for example, use $(foo) over `foo`.

• You can check your scripts with 'sh -n' and 'checkbashisms'.

• Make sure all shell code runs with 'set -e'.

15.2 Indenting

• Always use tabs over spaces.

15.3 Wrapping

• Generally, lines are 80 chars at maximum.

• Use the "Linux style" of line breaks:

Bad:

if foo; then
         bar
fi

Good:

if foo
then
         bar
fi

• The same holds for functions:

Bad:

Foo () {
         bar
}

Good:

Foo ()
{
         bar
}

15.4 Variables

• Variables are always in capital letters.

• Variables used in live-build always start with LB_ prefix.

• Internal temporary variables in live-build should start with the _LB_ prefix.

• Local variables start with live-build __LB_ prefix.

• Variables in connection to a boot parameter in live-config start with LIVE_.

• All other variables in live-config start with _ prefix.

• Use braces around variables; e.g. write ${FOO} instead of $FOO.

• Always protect variables with quotes to respect potential whitespaces: write "${FOO}" not ${FOO}.

• For consistency reasons, always use quotes when assigning values to variables:

Bad:

FOO=bar

Good:

FOO="bar"

• If multiple variables are used, quote the full expression:

Bad:

if [ -f "${FOO}"/foo/"${BAR}"/bar ]
then
         foobar
fi

Good:

if [ -f "${FOO}/foo/${BAR}/bar" ]
then
         foobar
fi

15.5 Miscellaneous

• Use "|" (without the surround quotes) as a separator in calls to sed, e.g. "sed -e 's|foo|bar|'" (without "").

• Don't use the test command for comparisons or tests, use "[" "]" (without ""); e.g. "if [ -x /bin/foo ]; ..." and not "if test -x /bin/foo; ...".

• Use case wherever possible over test, as it's easier to read and faster in execution.

• Use capitalized names for functions to limit messing with the users environment.