No, I fix bad code, then I don't comment it, because the vast majority of code that fits the 'this is within 10% of as good as it could be written' doesn't need comments.
Comments cannot be unit tested and thus can flow into a buggy (i.e. no longer relevant or even actively misleading) state, and are tedious to keep up to date even if you do realize you're making updates that don't mesh with what the comments say. Of course, for the few cases where there's no way to let the code speak for itself, by all means comment. i.e. you tried something that seems simpler or a more logical way to do it, but there's an easy-to-miss problem doing it that way. Another aspect of source history delving that's important to _try_ to get your developers to do right is keeping the version control tree clean. This is perhaps a YMMV thing, but, I _really_ like it when the commit history is mostly devoid of superfluous merges and each individual commit is part of a sensible whole and has a decent commit message. This means I use git, and this means I'll be extensively rebasing a local branch into a sane whole before I rebase it on top of master. Now a git blame on a line that makes me go "WTF is this?!?" leads me to the commit and the message there usually explains to me exactly why its needed (or, better yet, makes me understand the brainfart that caused it, so that I can fix it secure in the knowledge that I'm in fact smarter than the original commit, instead of dumber, i.e. overseeing some nuance). -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
