Subj : Re: Software development book recommendation
To   : tenser
From : Adept
Date : Tue Mar 18 2025 21:14:17

 te> Others can probably say it better than I can.  Something like
 te> https://qntm.org/clean is a good reference.

I did like your breakdown of it, though, as it did seem to well explain why you feel the way you do toward the idea.

 te> Then you probably wouldn't like "Clean Code."  :-)  Martin describes
 te> a comment as a "failure".

Yeah, I'm sure I'd fundamentally disagree.

I tend to code by first commenting, then refining the code and comments as I go along.

But even after things are pretty tight, I _still_ want the comments in there, because it'll explain what was in my head as I wrote the code, and give me a chance of explaining the code in a second way that might make more sense to the next person to come by.

Obviously, I'll try to use good variable names, have easy-to-follow code, and so on, but even with perfect code, it's a guarantee that all but the simplest situations will have people with a different mindset coming through and wondering what the heck was going on.

 te> I certainly think that there are times when a better name or a
 te> temporary variable or something can make a comment completely
 te> redundant, and that's good, but he goes entirely too far.

Yeah. It does sound like it's combining a good idea (make things readable) with a bad idea (if variable names aren't enough in all situations, it's bad code).

 te> comments failures, but doesn't discuss when they may be necessary.
 te> The advice is thus not usefully weighted in situations where
 te> things are ambiguous.

Beyond that, what I like about comments is that it's a way for a coder to say, "this is what was going through my head when making this, and what I was trying to do". Even with perfect variable names, you'd have to infer that info.

 te> names like, `isLeastRelevantMultipleOfLargerPrimeFactor`.  Yeah, I
 te> don't know what the hell that means, either, and I'm positive that

Oof, yeah, if that's in the example...

 te> This is the thing that clinches it for me.  Martin's advice is all
 te> extremely tactical: "here's how you should write this (class|function)."
 te> It doesn't help with building larger systems at all.

I guess he's all set for Leetcode...

--- Mystic BBS v1.12 A48 (Linux/64)
 * Origin: Storm BBS (21:2/108)

.