[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 #15 from Jock Tanner <tanner.of.kha at gmail.com> ---
(In reply to Jean-Paul.Chaput from comment #8)
>   Coriolis has always been tricky to install from sources (but try to build
>   the whole Gnome3 stack instead of using packaged versions to make a fair
>   comparison). As I happen to manage Cadence/Mentor/Synopsys in my lab,
>   I assure you, that they are not simpler, by a long shot (with a license
>   fee around 100K$ a year, for commercial purpose).
>     That context being setup, I know myself to have a tendency to make things
>   too complicated, but it is difficult to improve without feedback.
>     I'm always eager to improve the quality of my software and coding style,
>   but ranting about "this is badly written" do not help. I flatter myself
>   to have the "scientific spirit", so if you pinpoint me badly written code
>   and *why* it is so (with reference), I will improve it in my futur code
>   and progressively rewrite the old one.

Jean-Paul,

I'm feeling like I'm slowly burying myself in the sand, but instead of bad code
I would like to pinpoint you something much more important − bad tools you use.

There are many errors in and around Coriolis, similar to the one I found:

- clrcore/helpers/Alliance.py:199 − gaugeDatasNo is undefined
- cumulus/plugins/chip/BlockCorona.py − a lot of undefined vars
- cumulus/plugins/chip/BlockPower.py − a lot of undefined vars
- etc/coriolis2/common/colors.py − ditto

Most of these errors are outside “happy path”. But I don't have to catch all
these errors to see them. In fact I don't have to run the code at all. All I
have to do is open the file in Pycharm, and it highlights all kind of problems.
The good code is mostly black&white, while the bad code is lit up like a
Christmas tree!

'colors.py' shows another typical problem of the project. The first indent is 4
spaces, but all the following indents are 2 spaces. It most probably means that
this file once contained a class, that later was refactored into free
functions. I do that a lot. I love free functions. And my editor
indents/dedents any amount of code with one key press. I don't have to spend my
time making my indentation consistent.

Another thing is dead code. It comes in two flavors: it may be either just
unreachable or commented out.

- etc/coriolis2/common/patterns.py:109 − unreachable (and meaningless btw)
- soclayout/experiments5/ringoscillator.py:879-914 − also unreachable
- stratus/dpgen_ROM.py:861-916 − commented-out

First flavor reveals itself instantly with code highlight. Second one, well, it
kinda have a reason to be there. But if you use version control, that reason is
invalid. Especially if you can access any commit in two clicks: “Version
control” → “Log”. If you find it hard to just delete the unneeded code, well,
you must be using the bad tools.

I won't even get started on Pycharm making hard or even impossible to break
PEP8, let alone reformatting any code in an instant. The style is not a most
important problem of the project. Bad tools are.

Important disclaimer! I mostly speaking of my lovely Pycharm, because I'm lazy,
and it comes configured right out of the box. I know that the same result can
be achieved with properly configured vim, Emacs, SublimeText or Notepad++. I
just can't recommend all the necessary plugins.

Jean-Paul, if you don't want to kill me already, I can pinpoint the second big
problem. Hint: it's not the style.

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