From 00450f432dad6bf17cd19376bca07a7c6990249d Mon Sep 17 00:00:00 2001 From: lkcl Date: Wed, 29 Jan 2020 23:32:29 +0000 Subject: [PATCH] --- HDL_workflow.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) 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 -- 2.30.2