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.02
Build: V8.02.512.2025.05.30

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. You can as well have a look @ is_ipv4addr() or is_ipv6addr().
• 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=""),
    • use declare -g and use typing (variable types) if possible.
  • Local variables:
    • are lower case,
    • declare them before usage (declare),
    • initialize them (declare VAR="").
  • Preferred declaration and initialization:
    • VAR: declare -g VAR="" and declare -a ARRAY=().

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