Donald Knuth, who gives money to people who spot bugs in his code, even invented literate programming to mix prose explanation and code better. Is he an idiot?
Donald Knuth, who gives money to people who spot bugs in his code, even invented literate programming to mix prose explanation and code better. Is he an idiot?
They are the crutch of people who can't read code: "Add more comments because otherwise I can't make sense of what the statements are doing." It is the English speaker demanding that every French passage have an English translation, rather than simply learning French.
They are the crutch of people who can't write code. "My code is a gigantic, illiterate mess, so instead read the comment at the top that has no guarantee of being robust or accurate."
Bringing up mathematicians and Knuth are both irrelevant distractions. Software development in the modern world is a very structure, self-describing affair, or at least it should be. Comments are the short-circuit from having to figure out how to do that.
You seem to have lots of experience with expressing intent in code, and making that intent 'canonical'. How do you make the machine check the accuracy of your code? What language are you using for that?
I mean, I can write self documenting code without any comments, and it's perfectly understandable.
before_create :auto_increment
def auto_increment
self.count + 1
end
That code fails to tell the programmer why it's in the application logic and not defined in the database schema. What should I do instead, so I can code without crutches? def auto_increment_natural_key
self.count + 1
end
That's not a great deal better, it's still just saying what it does, not why it's there in the first place. def auto_increment_natural_key_because_another_app_relies_on_it
self.count + 1
end
Is that it?Now we just put the comment in the variable name. The compiler just checks the variable names all match up, but doesn't check whether their names make sense.
Perhaps the example chosen was too much of a toy to yield valuable insight?
Pretty sure that's it.
Why isn't it a GUID? Why is it 32 bits instead of 64? Why is it signed yet starts at 1? Why isn't it a string? How will the identities be merged?
The notion that answering one single question provides clarity is ridiculous.
I would argue that in this case, it is far better to just understand the code and then fix it appropriately. A comment would leave you second guessing.
def auto_increment
self.count += 1
end
(though, for the purposes of self documenting code, count probably is not a great variable name either)Though, I think your example turned out to be a great one because it highlights that not everyone reads code the same way. Personally, I load large segments of code into memory and then mentally step through. You left me wanting more to see the context in which the method was to be executed, but I didn't really feel the need for comments.
However, with just the one method that you wrote in your example, that seems to indicate that you read just one function at a time. If you are not observing the code as whole, I guess a comment would help. I often find them taxing though, as they have to be read into memory as well.
I think that discrepancy is why the comments vs. self-documenting code debate exists.
But the way in which people read code is an interesting point, which I actually think might be worthy of its own discussion. Looking at the psychology behind this would be good, I think.
Actually, I would say your intent there was quite clear, which is where I came to realize that the code did nothing. Without that context, one could assume the method was used for its return value where the code could very well have had purpose as written.
What wasn't clear was how the count attribute was intended to be used throughout the rest of application. In the real world I would start to build a mental model around the uses of count, which was not available from your example. In terms of self-documenting code, I liken a short code snippet like your example to a sentence fragment in english. The entire sentence, or statement if you will, encompasses much more of the codebase.
This is definitely an fascinating topic, but unfortunately one that is very difficult to discuss for many reasons. I wonder how we can dig into the physiology aspects that you raise without the prevalent "my way is the only true way" attitude?
I'm not trying to be an a$$hole btw. I am not a coding guru, I genuinely want to minimize the need for comments in my code and am willing to learn from examples.
Read almost any non-trivial successful project for good examples. The Linux kernel. Firefox. etc. The frequency and verbosity of comments tends to have a direct correlation with the simplicity of the code (which is the exact opposite of normal expectations).
Have you written any large projects that you've had to maintain over years, or worked with large teams, or handed off maintenance of a large project to others?
To your questions, while you're rhetorically asking, trying to wink to the crowd in the implication that the answers are telling, yes, actually I have. To very good effect. I'm speaking from actual experience here, not just the hilarious patter of the bottomfeeder that is far too typical on HN.
No.
> "Messes". Indeed.
Yes, messes. Why do you think Chrome is eating Firefox's lunch ? Google has both a better-implemented product and sufficient marketing clout to push it.
Have you worked on Linux kernel code?
> I'm speaking from actual experience here, not just the hilarious patter of the bottomfeeder that is far too typical on HN.
What have you worked on?
I've worked on FreeBSD, Mac OS X, and an assortment of smaller widely used software projects, including user-facing applications.
Humorous given that both webkit and from that Chromium are largely comment free. What nonsense are you arguing again?
I've worked on FreeBSD, Mac OS X, and an assortment of smaller widely used software projects, including user-facing applications.
"Worked on" in HN parlance means "I did a coop term and wrote some test cases for some irrelevant little utility". Given your comical claims about Linux and Firefox re: Chrome, I have enough information about your skills.
Seriously?
http://src.chromium.org/viewvc/chrome/trunk/src/ipc/ipc_chan...
// If the channel has already been created, then we need to send this
// message so that the filter gets access to the Channel.
http://src.chromium.org/viewvc/chrome/trunk/src/ipc/ipc_chan...And so on.
> "Worked on" in HN parlance means "I did a coop term and wrote some test cases for some irrelevant little utility".
Please go back to Reddit.
You clearly have no idea what you're talking about. I hope I never get stuck cleaning up your messes, but chances are that someone as intellectually lazy as you -- if not you -- will leave me an uncommented code base to maintain.
The fact that you actively advocate intellectual laziness is distressing.
Further it's utterly astonishing that you would equate writing clear and non-ambiguous code rather than nebulous code of uncertain purpose -- like the example Chromium code you linked -- is "intellectual laziness". That you hold good coding as deficient compared to lazy commenting is hardly surprising given your comments.
"I don't need to comment" is really "I don't want to document my work because that's boring and I'm much too smart to need to do that".
You're not that smart. If you were, you'd realize just how dumb everyone is, and thus, just how necessary comments are.
As has been said, comments explain why you are doing something in a certain way. That why is often related to a business process, several business process, and/or 25 different outside cases.
The code can be amazingly clean and organized, but you comment to indicate why you did something one way and not another.
Sure you are. And that's okay.