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.

Fuego code consists mostly of shell script and python code.

Indentation and line length [edit section]

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.

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]

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.

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:

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.

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.

Shell features [edit section]

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.

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.

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]

Python code (such as parser code, the overlay generator, ftc and other helper scripts), should be compliant with 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.

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.