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

I agree with you, though I think a few things maybe don't hold anymore:

> Sign and date your comments!

> (Should be an editor command to do this)

Now that everyone uses a VCS (well, almost everyone), this is no longer necessary.



Yea. I know VCS are supposed to be a better option and handle all of that for you.

Our software vendor uses VCS, but has a long history of signing and dating code sections with paragraph explanations. They've been developing the same codebase since the 70's and release the uncompiled source along with the precompiled binaries. Their documentation is horrendous, but the source and comments help out quite a bit.

Some of the prolific coders have written lots of research papers and textbooks as well, so it is really cool to read one of their textbooks and see the code firsthand.


It's still a good idea. Hell, I recently configured my editor to expand "todo"/ into "TODO | -- $name, $date" (where | is where the caret ends after expansion).

Code often outlives its VCS history. I've seen it in every company (except one) I worked for. Signing and dating comments lets you evaluate whether the remark is still applicable and who to bug about regardless of how deeply the VCS goes, and doesn't require you to jump through multiple Blame sessions to filter out commits that only touched or moved, but otherwise not changed the comment.


Todo’s are probably the only place where signing and dating the code are not horrible. That way you can filter out all the random todos by intern Jim last summer.

But I have seen that people who put their name in comments are too lazy/ignorant to know how to use blame. It’s super easy and keeps your code clean. If the author is older then the VCS, they are no longer relevant.


> Todo’s are probably the only place where signing and dating the code are not horrible.

Not just todos. Also notes bringing in external context to why some code looks the way it is, because that external context can invalidate over time, and a date is then useful to evaluate whether the code needs changes.

> If the author is older then the VCS, they are no longer relevant.

You'd be surprised. Loss of VCS history happens for various reasons. In my career, I've seen one because the company switched to a different VCS. I've seen another because someone forked the project by copying out some parts of older project and committing them in a first commit of a new repo. I also worked with a codebase that's older than I am, predating Git, SVN and CVS, that someone at some point open-sourced on Github.


Might still be a good idea, actually. "I've checked that this comment is up-to-date as of ..." is not something that a VCS surfaces.




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

Search: