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

The premise of the article is that you happen to stumble upon a messy piece of code and that the explanations related to it might be located into the source history. Yet the only reason why these explanations would actually be there is that someone would have enforced doing that as a rule. And the point of the counter-argument is that before enforcing this rule this same person should be enforcing a rule saying that writing messy code like that is prohibited.

In short, maintaining a clean code base has always higher priority than maintaining a clean log.



That's like saying that a "counter-argument" to wearing a seatbelt is that drivers shouldn't be getting into accidents in the first place. Yes, it would be nice if all code was well-commented and well-factored with well-named functions, classes and variables, and we should all strive to make code like that. And if that never failed, then perhaps we wouldn't need any other best practices or rules to help us along.[1] But we all know the real world is not like that. We need all the help we can get. Having good practices for writing good code is not, I repeat not an argument against having good practices for commit comments. You make it out to be an either/or proposition. It's not.


jesus christ

http://lsolum.typepad.com/legal_theory_lexicon/2003/09/legal...

this article is about recommendations of what to do ex post once a comment-less line of code has been committed in the past that you need to understand. arguments about ex ante things such as how it got there in the first place and how to prevent it from happening is completely orthogonal to the point of the article.


Strong disagree. The article is about recommending and making ex post use of a policy for good commit messages. The point argued is in favor of a future rule for good commit messages. Therefore it is very reasonable to suggest a superior rule for the future.


As rymohr indicated, the author of the code given as example is actually the author of the article himself:

https://github.com/madrobby/zepto/commit/3d92f20966aa02dee82...

Which means the OP genuinely thinks that commits like this one are good practice, and the purpose of the article is to show how to deal with it.

Yet as it was argued above, commits like that should never happen in the first place.


And it didn't. This was the commit that actually happened: https://github.com/madrobby/zepto/commit/2ed0123eaddc023a857...

Notice the code comment. I took it out for the example in the blog post to illustrate how we would deal if there was never a code comment in the first place.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: