↳
In-reply-to
»
This document is the result of a series of discussions between Robert "Uncle Bob" Martin and John Ousterhout, held between September 2024 and February 2025. The text addresses three main topics: method length, comments, and Test Driven Development (TDD).
https://github.com/johnousterhout/aposd-vs-clean-code/blob/main/README.md
This is something to read and reflect on for days.
@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.