Hacker News new | past | comments | ask | show | jobs | submit login

Changed formatting isn't a problem IMHO. You can ask git to skip whitespace changes, and you can (and should) enforce consistent formatting anyway to make history cleaner. And even if for some reason you don't want to do either - you can just click "blame previous revision" if you do encounter "changed formatting" revision.

I envountered it a few times and it was never a big problem.

The problem with comments in the code is - they have to be maintained "by hand", and they are often separated from the context after a few independent changes.

When you change a function called inside the foobify function because of another change request you will most probably forget to check all the calling places all the way up the callstack and fix the comments refering to foobify function. And then comments may start to lie.

I encountered lying comments a few times and it usually is a big problem. I started to ignore comments when debugging, and I'm not the only programmer that I know that does that.

I do think there is a place for comments in the code, for example for documentation of some API, but IMHO commit messages are the perfect place for explaining reasons of particular change, and I prefer not to repeat that.

http://cdn.meme.am/instances2/500x/4310914.jpg




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

Search: