From: lkcl <lkcl@web>
Date: Wed, 29 Jan 2020 23:32:29 +0000 (+0000)
Subject: (no commit message)
X-Git-Tag: convert-csv-opcode-to-binary~3659
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=00450f432dad6bf17cd19376bca07a7c6990249d;p=libreriscv.git

---

diff --git a/HDL_workflow.mdwn b/HDL_workflow.mdwn
index ea18a93f3..ef9cdbd4c 100644
--- a/HDL_workflow.mdwn
+++ b/HDL_workflow.mdwn
@@ -440,6 +440,7 @@ for actual code development:
   commits, and it actually becomes a nuisance).
 * prior to committing make sure that relevant unit tests pass, or that
   the change is a zero-impact addition (no unit tests fail at the minimum)
+* keep working code working **at all times**. find ways to ensure that this is the case. examples include writing alternative classes that replace existing functionality and adding runtime optiobs to select between old and new code.
 * commit no more than around 5 to 10 lines at a time, with a CLEAR message
   (no "added this" or "changed that").
 * if as you write you find that the commit message involves a *list* of
@@ -471,7 +472,8 @@ it (a large amount of code) is perfectly fine.
 
 as a general rule, however, do not use this an an excuse to write code
 first then write unit tests as an afterthought.  write *less* code *in
-conjunction* with its (more basic) unit tests, instead.
+conjunction* with its (more basic) unit tests, instead. then, folliw up with
+additions and improvements.
 
 the reason for separating out commits to single purpose only becomes
 obvious (and regretted if not followed) when, months later, a mistake