@andros@twtxt.andros.dev Just before the pandemic, we watched Uncle Bob videos once a week in the lunch break. While almost all of my old teammates agreed with his views, I partially found them to be very odd and even counterproductive.
I didn’t come across John Ousterhout or any of his work before, at least not deliberately. So, this document is my first contact.
I only finished the chapter on comments and I totally agree with John so far. This document just manifests to me how weird Bob’s view is on certain subjects.
I always disagreed with the concept of a maximum method length. Sure, generally, shorter functions are probably better, but it always depends. And I’ve certainly seen super short methods that just made the code flow even worse to follow. While “one function should only do one thing” is a nice general rule, I’m 100% in team John with the shown examples. There are cases, where this doesn’t help readability at all. Not even close.
To me, a function always has to justify its existence. Either by reusing it at least at another place or by coming up with dedicated tests for it. But if it is just called once and there are no tests, I almost always decide against it. Personally, I don’t mind longer methods. We just recently had a discussion about that and I lost against two other workmates who are more in Uncle Bob’s camp, they refactored one medium sized method into three very short ones. Luckily, we agree on most other topics.
Lol, what!? The shorter the method, the longer the variables inside? I first thought I misread or the writeup mixed it up. I’ll always do it the other way around.
I’ve been also bitten badly by outdated comments in the past, but Bob must have worked on really terrible projects to end up with such an attitude to dislike comments. Oh well. No doubt, I’ve come across by several orders of magnitude more useless comments, in my experience (autogenerated) JavaDocs fall in the category more frequently than not. So, I know that there are different types of comments. A comment doesn’t automatically mean that it is good and justified.
But I also partially agree with Bob and John and think that a good name has a proper chance to save a comment. Though, when in doubt, I go John’s route and use a shorter name with a comment rather than use a kilometer long identifier. Writing good comments typically takes some time, sometimes much longer than writing the code. It regularly takes me several minutes. It’s a hard art.
I perhaps should read up on John’s work. He seems to be more reasonable and likeminded. :-) Let me continue to complete this document.