CISS.debian.live.builder/docs/CODING_CONVENTION.md

Table of Contents

• 1. CISS.debian.live.builder
• 2. Coding Style
• 2.1. PR
• 2.2 Documentation
• 2.3. Coding
• 2.3.1. Shell / bash
• 2.3.2. Shell specific
• 2.3.3. Variables
• 3. Misc

1. CISS.debian.live.builder

Centurion Intelligence Consulting Agency Information Security Standard
Debian Live Build Generator for hardened live environment and CISS Debian Installer
Master Version: 8.03
Build: V8.03.256.2025.06.02

2. Coding Style

2.1. PR

You'd make the life of the maintainers easier if you submit only one patch with one functional change per PR.

2.2 Documentation

Some people really read that ! New features would need to be documented in the appropriate section in usage() and in ~/docs/DOCUMENTATION.md.

2.3. Coding

2.3.1. Shell / bash

Bash is actually quite powerful—not only with respect to sockets. It's not as mighty as perl or python, but there are a lot of neat features. Here's how you make use of them. Besides those short hints here, there's a wealth of information there.

• Don't use backticks anymore, use $(..) instead
• Use double square [[]] brackets (conditional expressions) instead of single square [] brackets
• In double square brackets, avoid quoting at the right-hand side if not necessary. For regex matching (=~) you shouldn't quote at all.
• The BashPitfalls is a good read!
• Whenever possible try to avoid tr sed awk and use bash internal functions instead, see e.g., bash shell parameter substitution. It is slower as it forks, fopens and pipes back the result.
• read often can replace awk: IFS=, read -ra a b c <<< "$line_with_comma"
• Bash can also deal perfectly with regular expressions, see e.g., here and here.
• If you still need to use any of tr, sed and awk: try to avoid a mix of several external binaries e.g., if you can achieve the same with e.g. awk.
• Be careful with very advanced bash features. Mac OS X is still using bash version 3 (differences).
• Always use a return value for a function/method. 0 means all is fine.
• Make use of shellcheck if possible.
• Follow the shellformat Shell-Style Guide.

2.3.2. Shell specific

• Security:
  • Watch out for any input especially (but not only) supplied from the server. Input should never be trusted.
  • Unless you're really sure where the values come from, variables need to be put in quotes.

2.3.3. Variables

• Use "speaking variables" but don't overdo it with the length.
• No camelCase, please. We distinguish between lowercase and uppercase only.
  • Global variables:
    • use them only when really necessary,
    • in CAPS,
    • initialize them (declare -g VAR_EXAMPLE=""),
    • SHOULD start with:
      • ARY_ for Arrays,
      • C_ for Variables defining colored outputs,
      • ERR_ for Error Codes Variables,
      • HMP_ for HashMap Arrays,
      • LOG_ for Logfile Variables,
      • PID_ for PID Variables,
      • PIPE_ for PIPE Variables,
      • VAR_ for Variables
  • Local variables:
    • are lower case,
    • declare them before usage (declare eq local),
    • initialize them (declare var_example=""),
    • SHOULD start with:
      • ary_ for Arrays,
      • c_ for Variables defining colored outputs,
      • err_ for Error Codes Variables,
      • hmp_ for HashMap Arrays,
      • log_ for Logfile Variables,
      • var_ for Variables.

3. Misc

• Test before doing a PR! Best if you check with two bad and two good examples, which should then work as expected.

---

no tracking | no logging | no advertising | no profiling | no bullshit