On 17 Mar 2025 at 02:09p, Adept pondered and said...
"Clean Code". It's bad advice, and my opinion is that Robert Martin is a blowhard and a charlatan. He's just not a very good programmer.
Come on, tenser - stop beating around the bush and tell us what really think :)
Well, in fairness, I don't think he kicks puppies or anything. :-)
Perhaps there's already something later, but I was hoping there'd be something describing why it's bad advice.
Others can probably say it better than I can. Something like
https://qntm.org/clean is a good reference.
The rest of it I don't particularly care about, since there are plenty of blowhards, charlatans, and bad programmers.
And, heck, most of us probably do those things to some extent from time
to time regardless.
Anyway, I haven't read Clean Code, but I'm very pro commenting. Yes,
there are such things as too much commenting, but aside from in school when people were commenting, "//adds 1 to x", it's not something I've
ever seen.
Then you probably wouldn't like "Clean Code." :-) Martin describes
a comment as a "failure".
I certainly think that there are times when a better name or a
temporary variable or something can make a comment completely
redundant, and that's good, but he goes entirely too far.
One of John Ousterhout's criticisms of Martin is that he doesn't
balance his advice: he goes to an extreme, so far as to call
comments failures, but doesn't discuss when they may be necessary.
The advice is thus not usefully weighted in situations where
things are ambiguous.
But random blocks of code where I'm supposed to just _know_ what the
heck the previous programmer was supposed to mean, based off of
variables? Yeah, those I've seen plenty of.
Martin's own example code is awful in this regard; he wrote a copy
of a prime number generator program he read about in a paper by
Donald Knuth, and ends up with a ton of silly little functions with
names like, `isLeastRelevantMultipleOfLargerPrimeFactor`. Yeah, I
don't know what the hell that means, either, and I'm positive that
Martin has no clue. Moreover, his code is just wrong in some places
(it doesn't handle integer overflow, for example, and fails for 2).
My own implementation of that program is here, btw; caveat that I am
not a Java programmer:
https://github.com/dancrossnyc/literatePrimes/blob/main/Primes.java
Especially when it's something where I don't understand the code base,
and I'm looking for _anything_ to help me to latch on what's going on in
a certain section.
This is the thing that clinches it for me. Martin's advice is all
extremely tactical: "here's how you should write this (class|function)."
It doesn't help with building larger systems at all.
--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)