Hacker News Reader

Comment by usewik | Hacker News Reader

> If your variable is not named well and you need a comment, name your variable better.

100% agree. While you are at it, consider naming and writing your functions in such a way that doesn't require a wall of comments. Clean Code uncle Bob style.

View on HN

Indeed. If you’re going to have an essay on top of a function or anywhere in code, earn the essay. That code better be operating on a ton of assumptions or using some creative logic to get to how it is that a simple reading doesn’t make sense.

I’ve done it myself on:

* engine definitions for complex workflows and DSLs

* heavy graph theory sections that included ASCII diagrams to clarify flow.

But those functions are probably 1 in 100 or rarer. Basically everything else is good enough with basic IDE-helping javadoc style comments at best, maybe with some input parameter clarification and business logic-clarifying 1-2 line comments sprinkled throughout.

    > Clean Code [U]ncle Bob style

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.

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?

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.

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.

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.

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.

Reply on news.ycombinator.com