{{Header}}
{{title|title=
{{project_name_long}} Coding Style
}}
{{#seo:
|description=Simplicity, Brevity, Sparingly Forking Upstream Projects, Feature Removability
}}
<div class="mininav">
* [[Dev/coding style]]
* [[Dev/bash]]
</div>
{{intro|
Simplicity, Brevity, Sparingly Forking Upstream Projects, Feature Removability
}}
= stub =
{{stub}}

= Simplicity =
For lack of a better term, {{project_name_short}} is [[Based_on_Debian|simple]]. It does not fork or recompile software packages from upstream projects.

Examples of software where it is often assumed that it is being modified by {{project_name_short}}, or questions arise about whether that is the case:

* No good examples yet.

This has the advantage that questions and issues caused by upstream projects can be redirected upstream, as per the [[Self_Support_First_Policy|Self Support First Policy]]. This reduces the maintenance load on the {{project_name_short}} project.

Issues that cannot be caused by a Linux distribution are sometimes mistakenly attributed to that distribution. Examples:

* https://www.mail-archive.com/qubes-users@googlegroups.com/msg29899.html
* https://www.mail-archive.com/qubes-users@googlegroups.com/msg29573.html
* https://forums.whonix.org/t/monero-and-whonix-15-0-1-5-1-bug/10532

Related: [[Dev/Relationship_With_Upstream|Relationship With Upstream]]

= Brevity =
In most cases, goals should be achieved using a single implementation. For example, if remounting <code>/run</code> with more secure mount options is required, the implementation should do this, if possible, either entirely in <code>initramfs</code> / <code>dracut</code> or entirely using <code>systemd</code>. It should not duplicate the same functionality in both.

There are numerous things that users might potentially do, which may not align with {{project_name_short}} developers' perspectives. For instance, there is the [https://packages.debian.org/search?keywords=hello hello] package, which most users are unaware of and unlikely to install. This is merely an example, and no criticism is intended toward the contributor of that Debian package.

Why allow the installation of that package? What if that contributor turned malicious and included a backdoor in the <code>hello</code> package? To prevent such a backdoor from causing harm, an apt wrapper could be implemented to prevent the installation of such unnecessary packages. However, introducing such a wrapper would likely be worse than the hypothetical risk itself.

= Feature Removability =
If a feature becomes unmaintainable, there must be a way to remove it for users who upgrade their system using <code>apt</code>.

= No Trailing Whitespaces =
Use a proper editor and ensure no trailing whitespace is left at the end of lines.

= Indentation =
Avoid excessive levels of <code>if</code> conditions and similar constructs.

**Bad example:**
<pre>
machine_id() {
   if ! test -f /etc/machine-id ; then
      existing_machine_id="$(cat /etc/machine-id)"
      ## ...
   fi
}
</pre>

In the above example, there is no need to nest everything inside the <code>if</code> block. This is especially important when dealing with multiple levels of conditionals.

**Good example:**
<pre>
machine_id() {
   if ! test -f /etc/machine-id ; then
      return 0
   fi

   existing_machine_id="$(cat /etc/machine-id)"
   ## ....
}
</pre>

= Shell Scripts =
== Avoid <code>sed</code> and <code>awk</code> whenever possible ==
There may be older code (from before the introduction of <code>str_replace</code>) that uses <code>sed</code> or <code>awk</code>. Patches are welcome to migrate such cases to <code>str_replace</code>.

== Use <code>str_replace</code> whenever possible ==

[https://github.com/{{project_name_short}}/helper-scripts/blob/master/usr/bin/str_replace str_replace] is installed by default in {{project_name_short}} ([https://github.com/{{project_name_short}}/helper-scripts/blob/master/man/str_replace.1.ronn man page]). <ref>
https://github.com/Samer-Al-iraqi/Linux-str_replace/
</ref>

== Use <code>type -P</code> instead of <code>which</code> ==
Do not use <code>which</code>. Instead, use <code>type -P</code>.

https://mywiki.wooledge.org/BashFAQ/081

== Proper Whitespace Handling ==
See [[Dev/bash]].

= See Also =
* [[Dev/Source Code Intro|Source Code Introduction]]

[[Category:Design]]

{{Footer}}