undefined | Better HN

0 pointsRHSeeger1y ago0 comments

> And therefore, comments can easily become outdated.

I am firmly of the opinion that keeping the comments up to date is part of the job of the developer. And if they're not doing it, they're not doing their job. It's no different than taking the time to write code that does the right thing, expresses the intent of what it's trying to do, etc. And, when code is peer reviewed, not including/updating comments in places where they are important should be a reason to send the code back to the developer.

I feel the same way about automated testing. They're both (testing and comments) way to make our code better; easier to understand, easier to maintain, more likely to be correct, etc.

0 comments

makeitdouble1y ago

> I am firmly of the opinion that keeping the comments up to date is part of the job of the developer.

I see where this comes from, but practicality is a huge issue. Comments don't become obsolete just by laziness, but also because they are human targeted and can't easily be managed the same way code is.

For instance if you comment on a function call to explain it's needed because of its side effects, when the function gets fixed and loses that side effect your comment becomes obsolete.

Will the person fixing the inner function go back to every single comment that vaguely references it's behaviour and fix them ? And do they also go to the one-up parent function to check the comments there ? If we're assuming large orgs with expansive code bases, it's just not realisitic to be dealing with all that prose and maintain consistency when what you're modifying can be mentioned anywhere is any tangential way.

RHSeegerOP1y ago

> For instance if you comment on a function call to explain it's needed because of its side effects, when the function gets fixed and loses that side effect your comment becomes obsolete.

And if you have a function call in your code that doesn't look like it does anything and don't comment it, then you're doing it wrong.

And if the person who wrote `functionWithSideEffects` changes it to not have side effects anymore, and the places that call it for the side effects don't get updated then, once again, someone isn't doing their job.

Keeping comments up to date is no different than keeping code up to date, or tests up to date, or removing code that isn't needed anymore, or cleaning code up so it doesn't turn into spaghetti, or anything else we do as developers. Does it always get done? Of course not. But that doesn't mean it shouldn't get done.

makeitdouble1y ago

> And if you have a function call in your code that doesn't look like it does anything and don't comment it, then you're doing it wrong.

We'll leave a comment, but it needs to be accepted that it will rot.

That's where personnally I'll explicitely date the comment to give the future dev a fighting chance to understand the context, if it's not directly linked to a ticket or some other documentation.

> And if the person who wrote `functionWithSideEffects` changes it to not have side effects anymore, and the places that call it for the side effects don't get updated then, once again, someone isn't doing their job.

It will work or not. In the meanwhile the side effect might not be useful anymore and become a useless call, or it might actually be doing something else that is now a primary effect. Hopefully there will be tests or external checks to validate the functionnality isn't broken.

It won't be ideal, but it's also a reality of a huge code base.

> Keeping comments up to date is no different than keeping code up to date,

The big difference being that at the end of the day comments are just comments, and they will always be a second class citizen relative to executable and parsed code. Sure in an ideal world we could ask people to treat them as critical, but short of having an actual organization wide strict enforcement of it with successful detection of comments that haven't been properly updated, it would unprofessional to ignore the reality of it.

For code we have static analysis, dynamic analysis, white and black box tests, and user feedback. Comments won't have that level of scrutiny, so accepting that fact and treating them accordingly feels logical to me.

1 more reply

j / k navigate · click thread line to collapse

0 comments

makeitdouble1y ago

> I am firmly of the opinion that keeping the comments up to date is part of the job of the developer.

For instance if you comment on a function call to explain it's needed because of its side effects, when the function gets fixed and loses that side effect your comment becomes obsolete.

RHSeegerOP1y ago

> For instance if you comment on a function call to explain it's needed because of its side effects, when the function gets fixed and loses that side effect your comment becomes obsolete.

And if you have a function call in your code that doesn't look like it does anything and don't comment it, then you're doing it wrong.

makeitdouble1y ago

> And if you have a function call in your code that doesn't look like it does anything and don't comment it, then you're doing it wrong.

We'll leave a comment, but it needs to be accepted that it will rot.

That's where personnally I'll explicitely date the comment to give the future dev a fighting chance to understand the context, if it's not directly linked to a ticket or some other documentation.

It won't be ideal, but it's also a reality of a huge code base.

> Keeping comments up to date is no different than keeping code up to date,

1 more reply

j / k navigate · click thread line to collapse