FrontPage 

Fuego wiki

Login or create account

Coding style in split format

This page described the coding style conventions used in Fuego.
This page described the coding style conventions used in Fuego.
Please adhere to these conventions, so that the code has a more uniform style and it is easier to maintain. Not all code in Fuego adheres to these styles. As we work on code, we will convert it to the preferred style over time. New code should adhere to the preferred style.
Please adhere to these conventions, so that the code has a more uniform
style and it is easier to maintain.  Not all code in Fuego adheres to these
styles. As we work on code, we will convert it to the preferred style over time. New code should adhere to the preferred style.
Fuego code consists mostly of shell script and python code.
Fuego code consists mostly of shell script and python code.

Indentation and line length [edit section]

= Indentation and line length =
We prefer indentation to be 4 spaces, with no tabs.
It is preferred to keep lines within 80 columns. However, this is not strict. If a string constant causes a line to run over 80 columns, that is OK.
It is preferred to keep lines within 80 columns.  However, this
is not strict.  If a string constant causes a line to run over 80 columns,
that is OK.
Some command sequences passed to the 'report' function may be quite long and require that they be expressed on a single line. In that case, you can break them up onto multiple lines using shell continuation lines.
Some command sequences passed to the 'report' function may be quite
long and require that they be expressed on a single line.  In that case,
you can break them up onto multiple lines using shell continuation lines.

Trailing whitespace [edit section]

= Trailing whitespace =
Lines should not end in trailing whitespace.  That is: 'grep " $" *' should always be empty.
You can do this with: 'grep -R " $" *' in the directory you're working in, and fix the lines manually.
You can do this with: 'grep -R " $" *' in the directory you're working
in, and fix the lines manually.
Or, another method, if you're using vim, is to add an autocmd to your .vimrc to automatically remove whitespace from lines that you edit.
Or, another method, if you're using vim, is to add an autocmd to your .vimrc
to automatically remove whitespace from lines that you edit.
This line in your ~/.vimrc:
This line in your ~/.vimrc:
{{{#!YellowBox
autocmd FileType sh,c,python autocmd BufWritePre <buffer> %s/\s\+$//e
}}}
automatically removes whitespace from all line endings in shell, C, and python files that are saved from vim.
automatically removes whitespace from all line endings in shell, C,
and python files that are saved from vim.
Or, a third method of dealing with this automatically is to have git check for whitespace errors using a configuration option, or a hook. See https://stackoverflow.com/questions/591923/make-git-automatically-remove-trailing-whitespace-before-committing#592014
Or, a third method of dealing with this automatically is to have git
check for whitespace errors using a configuration option, or a hook.
See https://stackoverflow.com/questions/591923/make-git-automatically-remove-trailing-whitespace-before-committing#592014
---- Also, script files should not end in blank lines.
----
Also, script files should not end in blank lines.

Shell features [edit section]

= Shell features =
Shell scripts which run on the device-under-test (DUT or board), SHOULD restrict themselves to POSIX shell features only.  Do not assume you have any shell features on the target board outside of those supported by 'busybox ash'.
Try running 'checkbashisms' on your target-side code, to check for any non-POSIX constructs in the code.
Try running 'checkbashisms' on your target-side code, to check for any
non-POSIX constructs in the code.
The code in fuego_test.sh is guaranteed to run in bash, and may contain bashisms, if needed. If equivalent functionality is available using POSIX features, please use those instead. Please avoid esoteric or little-known bash features. (Or, if you use such features, please comment them.)
The code in fuego_test.sh is guaranteed to run in bash, and may contain
bashisms, if needed.  If equivalent functionality is available using POSIX
features, please use those instead. Please avoid esoteric or little-known
bash features. (Or, if you use such features, please comment them.)
Another useful tool for checking your shell code is 'ShellCheck'. See https://github.com/koalaman/shellcheck. Note that most distributions have a package for shellcheck.
Another useful tool for checking your shell code is 'ShellCheck'.
See [[https://github.com/koalaman/shellcheck]].  Note that most distributions
have a package for shellcheck.
There are a few conventions for avoiding using too many external commands in shell scripts that execute on the DUT. To check for a process, use 'ps' and 'grep', but to avoid having grep find itself, use a wildcard in the search pattern. Like so: 'ps | grep [f]oo' (rather than 'ps | grep foo | grep -v grep'.
There are a few conventions for avoiding using too many external commands
in shell scripts that execute on the DUT. To check for a process, use 'ps'
and 'grep', but to avoid having grep find itself, use a wildcard in the search
pattern.  Like so: 'ps | grep [f]oo' (rather than 'ps | grep foo | grep -v grep'.

Python style [edit section]

the PEP 8 Python style guide. As with shell code, there is a lot of legacy code in Fuego that is not currently compliant with PEP 8. We will convert legacy code to the correct style as changes are made over time.
= Python style =
Python code (such as parser code, the overlay generator, ftc and other
helper scripts), should be compliant with [[https://www.python.org/dev/peps/pep-0008/|the PEP 8 Python style guide]].
As with shell code, there is a lot of legacy code in Fuego that is not
currently compliant with PEP 8.  We will convert legacy code to the correct
style as changes are made over time.
Here are a few more conventions for Fuego code: - strings consisting of a single character should be declared use single-quotes - strings consisting of multiple characters should declared using double-quotes, unless the string contains a double-quote. In that case, single-quotes should be using for quoting, to avoid having to escape the double-quote.
Here are a few more conventions for Fuego code:
 - strings consisting of a single character should be declared use single-quotes
 - strings consisting of multiple characters should declared using double-quotes, unless the string contains a double-quote.  In that case, single-quotes should be using for quoting, to avoid having to escape the double-quote.
Note that there is a fuego lint test (selftest), called Functional.fuego_lint. It only checks a few files at the moment, but the plan is to expand it to check additional code in the future.
Note that there is a fuego lint test (selftest), called Functional.fuego_lint.
It only checks a few files at the moment, but the plan is to expand it to
check additional code in the future.
TBWiki engine 1.8.2 by Tim Bird