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.
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.
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:
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.
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'.
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.