* if the command needed to create any given autogenerated output is not currently in the list of dependencies, first consult on the list if it is okay to make that command become a hard dependency of the project (hint: java, node.js php and .NET commands will cause delays in responses due to list participants laughing hysterically too much), and after a decision is made, document the dependency and how its source code is obtained and built.
* if you find yourself repeating commands regularly, chances are high that someone else will need to run them, too. therefore, put them into a .sh shell script (and/or a Makefile) and document them at the very minimum in README or INSTALL.txt or somewhere in a docs folder as appopriate. if unsure, ask on the mailing list for advice.
* plan in advance to write not just code but a full test suite for that code. **this is not optional**. large python projects that do not have unit tests **FAIL**.
-* edit files making minimal *single purpose* modifications.
+* edit files making minimal *single purpose* modifications (even if it involves multiple files. Good extreme example: globally changing a function name across an entire codebase is one purpose, one commit, yet hundreds of files).
* prior to committing make sure that relevant unit tests pass, or that the change is a zero-impact addition.
* commit no more than 5 to 10 lines at a time, with a CLEAR message (no "added this" or "changed that").
-* if the commit message involves a list of changes or the word "and", then STOP. do not proceed: it is a "red flag" that the commit has not been properly broken down. ask for advice on-list.
+* if as you write you find that the commit message involves a *list* of changes or the word "and", then STOP. do not proceed: it is a "red flag" that the commit has not been properly broken down into separate-purpose commits. ask for advice on-list.
* if it is essential to commit large amounts of code, ensure that it is **not** in use **anywhere** by any other code.
the reason for the above is because python is a weakly typed language. make one tiny change at the base level of the class hierarchy and the effect may be disastrous.
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.
+the reason for separating out commits to single purpose only becomes obvious (and regretted if not followed) when, months later, a mistake has to be tracked down and reverted. if the commit does not have an 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.
+
* all code needs to conform to pep8. use either pep8checker or better run autopep8. however whenever committing whitespace changes, *make a separate commit* with a commit message "whitespace" or "autopep8 cleanup".
* pep8 REQUIRES no more than 80 chars per line. this is non-negotiable. if you think you need greater than 80 chars, it *fundamentally* indicates poor code design. split the code down further into smaller classes and functions.
-* TBD there is a docstring checker. at the minimum make sure to have an SPD license heafer, module header docstring, class docstring and function docstrings on non-obvious functions
-* make liberal but not excessive use of comments.
-* unless they are very closely related, only have one module (one class) per file. a file only 25 lines long including imports and docstrings is perfectly fine.
+* TBD there is a docstring checker. at the minimum make sure to have an SPD license header, module header docstring, class docstring and function docstrings on at least non-obvious functions.
+* make liberal but not excessive use of comments. describe a group of lines of code, with terse but useful comments describing the purpose, documenting any side-effects, and anything that could trip you or other developers up. unusual coding techniques should *definitely* contain a warning.
+* unless they are very closely related, only have one module (one class) per file. a file only 25 lines long including imports and docstrings is perfectly fine however don't force yourself. again, if unsure, ask on-list.
* *keep files short and simple*. see below as to why
* create a decent directory hierarchy but do not go mad. ask for advice if unsure
* please do not use "from module import *". it is extremely bad practice, causes unnecessary resource utilisation, makes code readability extremely difficult, and results in unintended side-effects.
-* try to keep both filenames and variable names short but not ridiculously obtuse. an interesting compromise on imports is "from ridiculousfilename import longsillyname as lsn", and to assign variables as well: "comb = m.d.comb" followed by multiple "comb += nmigenstmt" lines is a good trick that can reduce code indentation by 6 characters without reducing clarity.
+* try to keep both filenames and variable names short but not ridiculously obtuse. an interesting compromise on imports is "from ridiculousfilename import longsillyname as lsn", and to assign variables as well: "comb = m.d.comb" followed by multiple "comb += nmigen_stmt" lines is a good trick that can reduce code indentation by 6 characters without reducing clarity.
regarding code structure: we decided to go with small modules that are both easy to analyse, as well as fit onto a single page and be readable when displayed as a visual graph on a full UHD monitor. this is done as follows:
* at the yosys prompt type "read_ilang modulename.il"
* type "show top" and a graphviz window should appear. note that typing show, then space, then pressing the tab key twice will give a full list of submodules (one of which will be "top")
-you can now fullsize the graphviz window and scroll around. if it looks reasonably obvious, i.e the connections can be clearly related in your mind back to the actual code (by matching the graph names against signals and modules in the original nmigen code) and the words are not tiny when zoomed out, and connections are not total incomprehensible spaghetti, then congratulations, you have well-designed code. If not, then this indicates a need to split the code further into submodules.
+you can now fullsize the graphviz window and scroll around. if it looks reasonably obvious at 100% zoom, i.e the connections can be clearly related in your mind back to the actual code (by matching the graph names against signals and modules in the original nmigen code) and the words are not tiny when zoomed out, and connections are not total incomprehensible spaghetti, then congratulations, you have well-designed code. If not, then this indicates a need to split the code further into submodules and do a bit more work.
The reasons for doing a proper modularisation job are several-fold:
* firstly, we will not be doing a full automated layout-and-hope using alliance/coriolis2, we will be doing leaf-node thru tree node half-automated half-manual layout, finally getting to the floorplan, then revising and iteratively adjusting.
-* secondly, examining modules at the gate level (or close to it) is just good practice. poor design creeps in by *not* knowing what the tools are actually doing.
-* thirdly, unit testing, particularly formal proofs, is far easier on small sections of code.
+* secondly, examining modules at the gate level (or close to it) is just good practice. poor design creeps in by *not* knowing what the tools are actually doing (word to experienced developers: yes, we know that the yosys graph != final netlist).
+* thirdly, unit testing, particularly formal proofs, is far easier on small sections of code, and complete in a reasonable time.
# TODO Tutorials
projects / libreriscv.git / commitdiff