diff --git a/content/policies/coding_conventions.md b/content/policies/coding_conventions.md
index bb6491bb760cce8c02e990ad35c4d35f8e333b1c..45039cf518e056f2f346306b826bad54d8e4c7e6 100644
--- a/content/policies/coding_conventions.md
+++ b/content/policies/coding_conventions.md
@@ -34,7 +34,8 @@ specific to other APIs are covered on their respective pages.
 
 ## Summary
 
-* [Use the GLib coding style]( {{< ref "#code-formatting" >}} ), with vim modelines.
+* [Align the happy path to the left edge]( {{< ref "#code-formatting" >}} ) and
+  when programming in the C language use the GLib coding style, with vim modelines.
 * [Consistently namespace files]( {{< ref "#namespacing" >}} ), functions and types.
 * [Always design code to be modular]( {{< ref "#modularity" >}} ), encapsulated and loosely coupled.
   * Especially by keeping object member variables inside the object’s private structure.
@@ -55,6 +56,10 @@ Using a consistent code formatting style eases maintenance of code, by meaning
 contributors only have to learn one coding style for all modules, rather than
 one per module.
 
+Regardless of the programming language, a good guideline for the organization
+of the control flow is
+[aligning the happy path to the left edge](https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88).
+
 The coding style in use is the popular
 [GLib coding style](https://developer.gnome.org/programming-guidelines/unstable/c-coding-style.html.en),
 which is a slightly modified version of the