From: lkcl <lkcl@web>
Date: Sat, 17 Sep 2022 17:49:56 +0000 (+0100)
Subject: (no commit message)
X-Git-Tag: opf_rfc_ls005_v1~387
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=3189b8b68b6a88760dd0f49691b3612ea4df987f;p=libreriscv.git

---

diff --git a/HDL_workflow.mdwn b/HDL_workflow.mdwn
index 94e9ed30e..cbce07e78 100644
--- a/HDL_workflow.mdwn
+++ b/HDL_workflow.mdwn
@@ -898,6 +898,48 @@ easy-to-find message, it cannot even be located, and once found, if the
 commit confuses several unrelated changes, not only the diff is larger
 than it should be, the reversion process becomes extremely painful.
 
+### PHP-style python format-strings
+
+As the name suggests, "PHP-style" is not given as a compliment.
+Format-strings - `f"{variable} {pythoncodefragment}" are a nightmare
+to read.  The lesson from PHP, Zope and Plone: when code is embedded,
+the purpose of the formatting - the separation of the format from
+the data to be placed in it - is merged, and consequently become
+unreadable.
+
+By contrast, let us imagine a situation where 12 variables need to
+be inserted into a string, four of which are the same variablename:
+
+     x = "%s %s %s %s %s %s %s %s %s %s %s %s" % (var1, var2, var3,
+                                                  var3, var4, var2,
+                                                  var1, var9, var1,
+                                                  var3, var4, var1)
+
+This is just as unreadable, but for different reasons.  Here it *is*
+useful to do this as:
+
+     x = f"{var1} {var2} {var3}" \
+         ...
+         f"{var3} {var4} {var1}"
+
+As a general rule, though, format-specifiers should be strongly
+avoided, given that they mix even variable-names directly inside
+a string.
+
+This additionally gives text editors (and online web syntax
+highlighters) the opportunity to colour syntax-highlight the
+ASCII string (the format) from the variables to be inserted *into*
+that format.  gitweb for example (used by this project) cannot
+highlight string-formatted code.
+
+It turns out that colour is processed by the **opposite** hemisphere
+of the brain from written language.  Thus, colour-syntax-highlighting
+is not just a "nice-to-have", it's **vital** for easier and faster
+identification of context and an aid to rapid understanding.
+
+Anything that interferes with that - such as python format-strings -
+has to take a back seat, regardless of its perceived benefits.
+
 ### PEP8 format
 
 * all code needs to conform to pep8.  use either pep8checker or better