Style Guide
In order to make LinuxGSM as coherent as possible, we adopted some code conventions to follow. Here are some of them.
Variables
Naming variables
Variables should be made of lowercase letters only and should be descriptive enough to understand its purpose (even if the variable is longer that preferred).
Defining variables
Any variable should be defined through double quotes
Calling variables
Variable should always be called between brackets and double quotes to prevent globbing and word splitting.
Directories
Directories are called using LinuxGSM directories variables, or relative to those. Common directory variables can be found in linuxgsm.sh
and _default.cfg
.
Examples:
if
Statements
if
StatementsIf statements should look like the following
if statements with multiple options like so
Conditional checks
Syntax
The
if [ statement ]; then
should be a one-liner operation.Signs comparators like
==
,lt
,lt
etc. are preferred to-eq
,-le
,-lt
.Anything within an if statement must be tabulated one step deeper.
Example:
Expression Standards
Common if expressions LinuxGSM uses. More expressions here.
Expression | Description |
---|---|
| if directory exists |
| if directory does not exist |
| if file exists |
| if file does not exist |
| true if length of string is zero |
| true if length of string is non-zero |
| true if the variable exists |
Do not use ! -z
or ! -n
There is a distinct difference between -n and -v.
-n is used to check is a variable is set and not if it exists -v is used to check if a variable exists and not it is set
Loops
Loops should be a one liner statement.
Anything within a loop must be tabulated one step deeper.
Comments
As English is not always the native language of a developer, comments should use a formal writing style and be straight to the point. If unsure this short formal writing guide will help.
Functions
Function should be named starting with
fn_
and using lowercase letters only.Any recurrent task should be put into a function.
Anything within a function must be tabulated one step deeper.
Example:
Messages
Messages should be given using core_messages.sh forms
Additional information messages are given in the form of
echo -e " * Message here"
Automated Messages
Automated messages are used with any commands that are non-interactive. Examples of this include Start, Stop and Monitor. There are various different alert messages available see Exit-Codes for details.
Each automated message starts with fn_print_dots
to show a process is happening but with no known outcome.
fn_print_dots
Once an outcome of a process is known the message uses an outcome message like fn_print_ok
or fn_print_fail
fn_print_ok
The option of a newline is also available by appending _nl
for example fn_print_ok_nl
. This will add a carriage return to the message preventing it being overwritten by the next message.
Characteristics
Interactive messages contain extra detail at the begining of the message that is pre-populated. Full stops must not
be used with this type of message.
Interactive Messages
Interactive messages are used with any commands that have interactive elements. Examples of this include Install, console and debug. There are various different alert messages available see [[Exit-Codes]] for details.
standard echo commands are normally used to supplement an alert or if an alert is not required. Bullet points can also be used
Characteristics
Treat interactive messages as a standard sentence. All messages must begin with a capital and end with a full stop
Last updated