Without starting a flame war, in 2026, is this still really a thing? I cannot recall any developer that I thought was excellent ever quoting "Clean Code [U]ncle Bob style" as gospel for how to write your code. There are just so many silly rules that he touts.
Like all extremists, he takes a mild view "if you have to explain the code, maybe it needs to be refactored" to "no comments ever". Never mind business logic or footguns that can't be fixed right now because of Reasons or "I tried to change this and it blew up because of some remote script calls it that isn't in the codebase" or any number of other very useful comments that inform engineers (and now LLMs) as guideposts along the way. But I worked at a company that loved Uncle Bob and enforced "no comments!" as a rule... just guess how clean and tidy that codebase was!
You raise some good points here. When I write comments, I only write what is not obvious from code. Example: Imagine there is some bizarre business rule that some insurance contract is 6% cheaper to write on the last business day of the month. That is exactly the kind of thing I will write inline code comments about. Someone without deep knowledge of that code would be clueless about that specific business rule.
I forgot about the no comments rule. Yeah, that sounds insane.
That's exactly how I see it. And 99% of LLM-generated comments are just that: annoyingly wordy repetitions of what's already in the code. Just redundant noise that is a waste of time to read. Usually because the LLM has no concept of the information that might actually be helpful in a comment.
The same goes for LLM PR descriptions and documentation. Those spaces were meant for additional information not already in the code, not superfluous prose.
The point of his argument is that if it isn't obvious from code, there is usually an opportunity to make it obvious by rewriting the code. This is often not practical, but it doesn't make it less true in the abstract. E.g., in your example one could make a constant for the 6% multiplier and call it LAST_DAY_OF_MONTH_DISCOUNT and take every possible other similar steps to have that idea of that comment embedded into the running code, not in the comments. This way everyone who reads the code can gain that deep knowledge by just reading it.
I find his particular style far from extrimist. I see the delivery as artistic style, serving to make a point. A kind of thought-bait, inviting one to consider the reason behind a jarring argument and hopefully arrive at a useful, even if milder and more practical conclusion on the no-comments only spectrum.
Comments
Like all extremists, he takes a mild view "if you have to explain the code, maybe it needs to be refactored" to "no comments ever". Never mind business logic or footguns that can't be fixed right now because of Reasons or "I tried to change this and it blew up because of some remote script calls it that isn't in the codebase" or any number of other very useful comments that inform engineers (and now LLMs) as guideposts along the way. But I worked at a company that loved Uncle Bob and enforced "no comments!" as a rule... just guess how clean and tidy that codebase was!
You raise some good points here. When I write comments, I only write what is not obvious from code. Example: Imagine there is some bizarre business rule that some insurance contract is 6% cheaper to write on the last business day of the month. That is exactly the kind of thing I will write inline code comments about. Someone without deep knowledge of that code would be clueless about that specific business rule.
I forgot about the no comments rule. Yeah, that sounds insane.
That's exactly how I see it. And 99% of LLM-generated comments are just that: annoyingly wordy repetitions of what's already in the code. Just redundant noise that is a waste of time to read. Usually because the LLM has no concept of the information that might actually be helpful in a comment.
The same goes for LLM PR descriptions and documentation. Those spaces were meant for additional information not already in the code, not superfluous prose.
The point of his argument is that if it isn't obvious from code, there is usually an opportunity to make it obvious by rewriting the code. This is often not practical, but it doesn't make it less true in the abstract. E.g., in your example one could make a constant for the 6% multiplier and call it LAST_DAY_OF_MONTH_DISCOUNT and take every possible other similar steps to have that idea of that comment embedded into the running code, not in the comments. This way everyone who reads the code can gain that deep knowledge by just reading it.
I find his particular style far from extrimist. I see the delivery as artistic style, serving to make a point. A kind of thought-bait, inviting one to consider the reason behind a jarring argument and hopefully arrive at a useful, even if milder and more practical conclusion on the no-comments only spectrum.
Has it ever been a thing in most companies? I have seen definitely more bad code and negligance than serious, skillful attempts to write clean code.
Which rules do you think are particularly outdated?