[libre-riscv-dev] [Bug 217] create a "ring" system which allows pad locations to be specified conveniently

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=217

--- Comment #18 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #12)

>   I understand, I'm accustomed to it and have no problem with it.
>   This is because sometime the nesting could be very deep, and I
>   did not want things to go too much to the right.

i trained as a software engineer. very first time i dropped my code
in front of a lab assistant, he rattled out some changes on vi (which
got me hooked on it, instantly) and said, "if you have to go beyond
about 3 levels of indentation, write a new function".

>   I will switch to 4 spaces.

i only recommend this if you also redesign the code to use functions
in order to avoid exactly what you used 2 spaces for.

this unfortunately will be a lot of work so should be done incrementally.


> > and the use of commas at the *beginning* of the line on a parameter list,
> > rather than the usual place at the *end* of the line, is very difficult to
> > get used to.  i find that, automatically, i add the comma at the end
> > (because that is the pep8 standard) and of course it creates a syntax error
> > because there is a *second* (unexpected) comma at the start of the next line.
> 
>   Funny thing, I did put the comma at the beginning because I kept
>   forgetting to put it at the end. I find it also much more clear as it
>   makes one straight column below the opening parenthesis and is
>   more convenient for rectangular selection. And finally it helps
>   keep thing vertically aligned so you immediately notice if a
>   comma is missing (tabulating at the end is possible but tedious
>   because of the variable length or the arguments).
>     I understand it goes against a lot of habits and automatism,
>   but I think I will keep it.

just bear in mind, everyone who has done standard python software
programming (for 20 years) will find this very awkward to work with,
as well as read.

(we just got used to it, in other words, and it became second-nature).

for example: at some point, just to be able to read the code, i may have
to run autopep8 *before* searching for clues in the code, then on each
"git pull", destroy the working tree (git reset --hard), then "git pull",
then re-run autopep8.

! :)

> > it would need careful scheduling because, really, you need to hit the entire
> > codebase with a single carefully-reviewed autopep8 update and commit, and
> > not do *anything* else in between.
> 
>   Yes and perform complete regression tests.

autopep8 is specifically designed not to cause "damage".  there are a couple
of options which can change the meaning of the code (fix some things that you
should not be doing), however they are off by default and need to be explicitly
enabled.

as more of coriolis2 is converted to python, jean-paul, there should not just
be regression tests added, there should be unit tests added as well.

having worked with massive python code-bases before, i mention this here,
first and top priority thing of "Coding" section:
https://libre-riscv.org/HDL_workflow/

you *have* to have unit tests in a medium to large sized python project. 
without fail.

i know it is annoying, and feels like it is "stopping useful and productive
work".  however it is really quite simple: if you don't have unit tests, you
absolutely cannot safely change even one line of code that is already in use.

anyway.  OT for this bugreport.  we have EUR available, allocated specifically
to coriolis2, to help ok?

-- 
You are receiving this mail because:
You are on the CC list for the bug.