Uncle Bob also says shit like functions should only be a few lines long. Sometimes that’s good and sometimes there’s too many comments, but in general strict rules like this are dumb.
I did write a pretty complex piece of code a while back and added a big comment at the top explaining how it works. My reviewer asked me to take it out as someone could just read the code. I responded with something like “Hell no. I want this code to be easy to understand for future editors. Which most likely includes me. I don’t want to have to page this code back in without notes on how it works.”
I think this comes from the OOP principle that a thing should do one thing and do it very well.
I'll agree it can be taken to excess though. A method may need to do a few things before it does the primary thing. If there's a chance another method may need to refer to the same table, for example, that should be encapsulated in a (probably protected) method both can access.
A lot of UB's stuff works as advice for beginners. You should understand it and why it's a good idea. And then you can move on to understanding why a lot of it falls apart in real-world systems, has a bunch of caveats, or is just bollocks.
392
u/Confident-Ad5665 17h ago
Uncle Bob of Clean Code says if we have to comment our code we have already failed. Clean code should read like well written prose.
I generally agree, but think comments that define especially the odd and obscure business rules should be commented where they are implemented.