alt Hacker News> Converting the idiomatic math into non-idiomatic words would not be an improvement in clarity in this case.
You seem to be missing my point. It's not about improving "clarity" about the math each line is doing -- that's precisely the kind of misconception so many people have about comments.
It's about, how long does it take me to understand the purpose of a block of code? If there was a simple comment at the top that said [1]:
# Calculate top-left point of the bounding box
The original assertion that "This code is so literate, so easy to read" is demonstrably false. Naming something "pt" is the antithesis of literature programming. And if you insist on no comments, you'd at least need to name is something like "bbox_top_left". A generic variable name like "pt", that isn't even introduced in the context of a loop or anything, is a cardinal sin here.
Replies
I think at certain calibers of work, like graphics programming in lower level languages, the best you can do is be readable and clear to others who are experts in your field. In other words, you aren't the target audience. There is likely no way to write this specific kind of code in a way that satisfies all audiences. I'm willing to concede then that the 'best' way to write this type of code is determined by the ones writing it, not us with standard views on software.
It all depends on how much context the reader has. For some audiences a comment explaining bounding boxes would be helpful; for others your example comment adds nothing that isn't immediately apparent from the code.
Part of figuring out a reasonable level of commenting (and even variable naming) is a solid understanding of your audience. When in doubt aiming low is good practice, but keep in mind that this was 2D graphics software written at a 2D graphics software company.
A graphics programmer does not need that.
To help understand, you need to see this code as math. Graphics programming algorithms are literally math.
You're asking for training wheels comments, which just get in the way for those who are familiar with the domain.
I'm sure a few graphics programming engineers might want calls to react useState(), useEffect(), etc. to be documented in a codebase, yet a react programmer would scoff at the idea.
To a graphics programmer this can feel like call for comments to explain that
increments the loop variable. A newbie to programming might find such a comment useful, but to people who are maintaining such a piece of code that would be distracting line noise.It all depends on who your professional peer is that you are writing the code for. It's totally fine to write for a peer who is familiar with the domain, as it's fine to write for a beginner, for pedagogy, such as in a text book.