{{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 better term, {{project_name_short}} is [[About#Based_on_Debian|simple]]. It does not fork or re-compile software packages by upstream projects.

Examples of software where it is often assumed that it is being modified by {{project_name_short}} or being asked in 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 [[Self_Support_First_Policy|Self Support First Policy]]. This reduces the maintenance load at {{project_name_short}} project.

Issues which cannot be caused by a Linux distribution are sometimes mistakenly attributed to that Linux 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 reached by using 1 implementation. For example to remount /run etc. with more secure mount options an implementation should do this - if possible - either entirely in initramfs or entirely using systemd. It shouldn't do the exact same things twice in initramfs and systemd.

There’s a huge amount of things which users might potentially do which won’t make sense from {{project_name_short}} developers point of view. For example there is the [https://packages.debian.org/search?keywords=hello hello] package which most users won’t know and won’t install. I am using it as an example here. No need to pick on that particular contributor of that Debian package. Why allow installation of that package? What if that contributor turned evil and somehow included a backdoor in the hello package? To prevent such a backdoor from doing damage, there could be an apt wrapper that prevents installation of that and other packages which most users will probably never need. I am not supposing to invent an apt wrapper for this hypothetical scenario. It would be worse having that code than having that risk.

= Feature Removability =
In case a feature becomes unmaintainable there needs to be a possiblity to remove the feature for users who use upgrade their system using apt.

= No Trailing Whitespaces =
Get a decent editor and don’t leave whitespace at the end of lines.

= Indentation =
Do not use too deep levels of <code>if</code> and similar.

Bad example:

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

In above example there is need need to put everything under the <code>if</code>. This is specifically important when there are several levels of conditionals.

Example good:

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

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

= Shell Scripts =
== avoid sed awk whenever possible ==
There might be some older code (before introduction of str_replace) that uses sed / awk. Patches welcome to port to str_replace.

== use str_replace whenever possible ==

[https://github.com/{{project_name_short}}/helper-scripts/blob/master/usr/bin/str_replace str_replace] is installed in {{project_name_short}} by default. ([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 type -P instead of which ==
Please do not use <code>which</code>. Please use <code>type -P</code> instead.

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

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

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

[[Category:Design]]

{{Footer}}