Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why do you say that? As a developer the comments are talking to me, not to the HR department and not to the computer. I want to know someone has thought about this area regarding the way bad comments get in the way of collaboration and the way good comments facilitate it.

The point is that answers to these questions show the extent of introspection a programmer has regarding code. I am looking for thoughtful answers, not right answers. If you think they are stupid questions, I don't want to put you in charge of doing the basic creation of new frameworks.

Edit: One really good follow-up question is something like, 'So you are reading code and you see a comment that says "This is broken." Is that a good comment or a bad one? Why?' It's a good question because right or wrong isn't in "good" or "bad" but rather the reasons they might give.

Edit2: If it's such an easy question what's your answer? ;-)



"As a developer the comments are talking to me"

-- As a developer the code is talking to me.

It's a trivial question, comments are a chore that developers do because they provide someone who is later looking at and/or modifying their code with the knowledge about how it works in a way that isn't obvious from the code itself. Comments have morphed into more structured form with annotations that the IDE can make use of in some languages, but asking about comments in an interview is asking to get spoon fed what you want to hear.


If you are explaining how your code works, shouldn't you be rewriting it so it is obvious rather than adding comments?

I don't know about you but I go after people in open source projects I help manage who write comments like that. Such comments add no value collaboration and indeed they get in the way of debugging more than they help. Folks debugging shouldn't be debugging based on comments but rather based on code.

But with clear code, comments are still helpful if they are used to describe difficult design decisions, or flag issues the developer sees down the road. "This is a kludge" is a much more helpful comment than "looping through an array of invoice lines so we know what to print." The first draws the developer's attention to the fact that an area of code may be unusually troublesome, while the second may be out of date, may be wrong, or may otherwise distract from debugging.

Of course there are function header comments, etc, but those don't really need to be under discussion.

You are right about the code needing to talk to you, but if you see comments as a way of explaining what your code does, then it's both a distraction to the next guy and a crutch for you.

Edit: I think this shows the point of the question and why the trivial spoon-fed answers are likely to be ones I would find inadequate.

Edit2: So the way I read your answer is "programmer just wants to get things done and doesn't mind writing non-clear code to do it, explaining it with comments. Suitable for a maintenance programming role but may in time grow into others."


Here's a good example btw of a comment that I found very helpful.

One day a number of years ago, I was reading through some part of the Linux source code (somewhere in the 2.4 series I think), and I was looking at a section of the TCP stack and came across a comment to the effect of "This is the max timeout value as specified in the RFC. This means FTP to Mars will never work"

Perfect comment. Besides making me laugh, it explains why a specific line is the way it is and explains that this may cause some issues where latency in the connection is high enough.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: