Files
CISS.debian.live.builder/.html/CODING_CONVENTION.html

251 lines
8.7 KiB
HTML

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>./docs/CODING_CONVENTION.md</title>
<style>
html {
color: #1a1a1a;
background-color: #fdfdfd;
}
body {
margin: 0 auto;
max-width: 36em;
padding-left: 50px;
padding-right: 50px;
padding-top: 50px;
padding-bottom: 50px;
hyphens: auto;
overflow-wrap: break-word;
text-rendering: optimizeLegibility;
font-kerning: normal;
}
@media (max-width: 600px) {
body {
font-size: 0.9em;
padding: 12px;
}
h1 {
font-size: 1.8em;
}
}
@media print {
html {
background-color: white;
}
body {
background-color: transparent;
color: black;
font-size: 12pt;
}
p, h2, h3 {
orphans: 3;
widows: 3;
}
h2, h3, h4 {
page-break-after: avoid;
}
}
p {
margin: 1em 0;
}
a {
color: #1a1a1a;
}
a:visited {
color: #1a1a1a;
}
img {
max-width: 100%;
}
h1, h2, h3, h4, h5, h6 {
margin-top: 1.4em;
}
h5, h6 {
font-size: 1em;
font-style: italic;
}
h6 {
font-weight: normal;
}
ol, ul {
padding-left: 1.7em;
margin-top: 1em;
}
li > ol, li > ul {
margin-top: 0;
}
blockquote {
margin: 1em 0 1em 1.7em;
padding-left: 1em;
border-left: 2px solid #e6e6e6;
color: #606060;
}
code {
font-family: Menlo, Monaco, Consolas, 'Lucida Console', monospace;
font-size: 85%;
margin: 0;
hyphens: manual;
}
pre {
margin: 1em 0;
overflow: auto;
}
pre code {
padding: 0;
overflow: visible;
overflow-wrap: normal;
}
.sourceCode {
background-color: transparent;
overflow: visible;
}
hr {
background-color: #1a1a1a;
border: none;
height: 1px;
margin: 1em 0;
}
table {
margin: 1em 0;
border-collapse: collapse;
width: 100%;
overflow-x: auto;
display: block;
font-variant-numeric: lining-nums tabular-nums;
}
table caption {
margin-bottom: 0.75em;
}
tbody {
margin-top: 0.5em;
border-top: 1px solid #1a1a1a;
border-bottom: 1px solid #1a1a1a;
}
th {
border-top: 1px solid #1a1a1a;
padding: 0.25em 0.5em 0.25em 0.5em;
}
td {
padding: 0.125em 0.5em 0.25em 0.5em;
}
header {
margin-bottom: 4em;
text-align: center;
}
#TOC li {
list-style: none;
}
#TOC ul {
padding-left: 1.3em;
}
#TOC > ul {
padding-left: 0;
}
#TOC a:not(:hover) {
text-decoration: none;
}
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
div.columns{display: flex; gap: min(4vw, 1.5em);}
div.column{flex: auto; overflow-x: auto;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
/* The extra [class] is a hack that increases specificity enough to
override a similar rule in reveal.js */
ul.task-list[class]{list-style: none;}
ul.task-list li input[type="checkbox"] {
font-size: inherit;
width: 0.8em;
margin: 0 0.8em 0.2em -1.6em;
vertical-align: middle;
}
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
</head>
<body>
<header id="title-block-header">
<h1 class="title">./docs/CODING_CONVENTION.md</h1>
</header>
<h1 id="1-cissdebianlivebuilder">1. CISS.debian.live.builder</h1>
<p><strong>Centurion Intelligence Consulting Agency Information Security Standard</strong><br> <em>Debian Live Build Generator for hardened live environment and CISS Debian Installer</em><br> <strong>Master Version</strong>: 8.02<br> <strong>Build</strong>: V8.03.127.2025.06.02<br></p>
<h1 id="2-coding-style">2. Coding Style</h1>
<h2 id="21-pr">2.1. PR</h2>
<p>You'd make the life of the maintainers easier if you submit only <em>one</em> patch with <em>one</em> functional change per PR.</p>
<h2 id="22-documentation">2.2 Documentation</h2>
<p>Some people really read that ! New features would need to be documented in the appropriate section in <code>usage()</code> and in <code>~/docs/DOCUMENTATION.md</code>.</p>
<h2 id="23-coding">2.3. Coding</h2>
<h3 id="231-shell--bash">2.3.1. Shell / bash</h3>
<p>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.</p>
<ul>
<li>Don't use backticks anymore, use <code>$(..)</code> instead</li>
<li>Use double square <code>[[]]</code> brackets (<em>conditional expressions)</em> instead of single square <code>[]</code> brackets</li>
<li>In double square brackets, avoid quoting at the right-hand side if not necessary. For regex matching (<code>=~</code>) you shouldn't quote at all.</li>
<li>The <a href="http://mywiki.wooledge.org/BashPitfalls">BashPitfalls</a> is a good read!</li>
<li>Whenever possible try to avoid <code>tr</code> <code>sed</code> <code>awk</code> and use bash internal functions instead, see e.g., <a href="http://www.cyberciti.biz/tips/bash-shell-parameter-substitution-2.html">bash shell parameter substitution</a>. It is slower as it forks, fopens and pipes back the result.</li>
<li><code>read</code> often can replace <code>awk</code>: <code>IFS=, read -ra a b c &lt;&lt;&lt; "$line_with_comma"</code></li>
<li>Bash can also deal perfectly with regular expressions, see e.g., <a href="https://www.networkworld.com/article/2693361/unix-tip-using-bash-s-regular-expressions.html">here</a> and <a href="https://unix.stackexchange.com/questions/421460/bash-regex-and-https-regex101-com">here</a>. You can as well have a look @ <code>is_ipv4addr()</code> or <code>is_ipv6addr()</code>.</li>
<li>If you still need to use any of <code>tr</code>, <code>sed</code> and <code>awk</code>: try to avoid a mix of several external binaries e.g., if you can achieve the same with e.g. <code>awk</code>.</li>
<li>Be careful with very advanced bash features. Mac OS X is still using bash version 3 (<a href="http://tldp.org/LDP/abs/html/bashver4.html">differences</a>).</li>
<li>Always use a return value for a function/method. 0 means all is fine.</li>
<li>Make use of <a href="https://github.com/koalaman/shellcheck">shellcheck</a> if possible.</li>
<li>Follow the <a href="https://google.github.io/styleguide/shellguide.html">shellformat</a> Shell-Style Guide.</li>
</ul>
<h3 id="232-shell-specific">2.3.2. Shell specific</h3>
<ul>
<li>Security:
<ul>
<li>Watch out for any input especially (but not only) supplied from the server. Input should never be trusted.</li>
<li>Unless you're really sure where the values come from, variables need to be put in quotes.</li>
</ul></li>
</ul>
<h3 id="233-variables">2.3.3. Variables</h3>
<ul>
<li>Use <strong>"speaking variables"</strong> but don't overdo it with the length.</li>
<li>No <em>camelCase</em>, please. We distinguish between lowercase and uppercase only.
<ul>
<li>Global variables:
<ul>
<li>use them only when really necessary,</li>
<li>in CAPS,</li>
<li>initialize them (<code>declare -g VAR_EXAMPLE=""</code>),</li>
<li>SHOULD start with:
<ul>
<li><code>ARY_</code> for Arrays,</li>
<li><code>C_</code> for Variables defining colored outputs,</li>
<li><code>ERR_</code> for Error Codes Variables,</li>
<li><code>HMP_</code> for HashMap Arrays,</li>
<li><code>LOG_</code> for Logfile Variables,</li>
<li><code>PID_</code> for PID Variables,</li>
<li><code>PIPE_</code> for PIPE Variables,</li>
<li><code>VAR_</code> for Variables</li>
</ul></li>
</ul></li>
<li>Local variables:
<ul>
<li>are lower case,</li>
<li>declare them before usage (<code>declare</code> eq <code>local</code>),</li>
<li>initialize them (<code>declare var_example=""</code>),</li>
<li>SHOULD start with:
<ul>
<li><code>ary_</code> for Arrays,</li>
<li><code>c_</code> for Variables defining colored outputs,</li>
<li><code>err_</code> for Error Codes Variables,</li>
<li><code>hmp_</code> for HashMap Arrays,</li>
<li><code>log_</code> for Logfile Variables,</li>
<li><code>var_</code> for Variables.</li>
</ul></li>
</ul></li>
</ul></li>
</ul>
<h1 id="3-misc">3. Misc</h1>
<ul>
<li>Test before doing a PR! Best if you check with two bad and two good examples, which should then work as expected.</li>
</ul>
<hr />
<p><strong><a href="https://coresecret.eu/">no tracking | no logging | no advertising | no profiling | no bullshit</a></strong></p>
</body>
</html>