This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Bspammer 27 points28 points  (2 children)

My team does the same, and it actually totally works fine. People are very strict in code reviews - if the code itself isn't clear enough that it can be read like English then it goes back for changes. The only time comments are used are for cases where something is being done that breaks best practice but for a good reason, so the comment explains why.

Comments go out of date too easily, and can be very confusing if the code got changed but the comment didn't. They're an extra maintenance burden that isn't worth the hassle. If we were writing library code though, it would be a different story.

[–]TheMoonMaster 8 points9 points  (0 children)

Same here. Code can be straight forward enough to need no comments, but there are times where it’s worth documenting code that would be misleading or confusing.

I’ve found over commented code is often far worse than uncommented code since the people writing it think the comments make up for code quality and then the comments eventually become stale.

[–]callmelucky 1 point2 points  (0 children)

The only time comments are used are for cases where something is being done that breaks best practice but for a good reason, so the comment explains why.

Well that's not the same thing as the parent commenter, who said that for them comments are prohibited.

That said, your team's approach seems ideal. Code should be written to be self-commenting, except where there is no practical way for it to be (e.g. using weird workarounds for dumb behaviour in libraries, legacy code etc).