Thanks for the comments! Amusingly, my biggest pet peeve right now has to do with comments that are in legacy code that I have been tasked with cleaning up and adding new features too.

I’d prefer clear, working unit tests over code comments any day when maintaining code, and I am sure others would too. Which would you prefer? A bunch of outdated code comments that don’t help much or a suite of unit tests/specs that fail if you do something in the code that breaks things? I surely know I would prefer the latter.

Forgetting that not all development is agile and that many teams are geographically distributed, you need to understand that you and your co-workers won’t be the eventual caretakers of the code.

Whoever takes over control of your code needs to be able to understand it and to understand the low-level decisions that were made in the code. ‘Why does the code always call the service twice in a row?’ ‘Why did you use an array when a hash would seem to fit better?’

You seem to be primarily concerned with ad-hoc coding decisions being made by a single developer who passive-agressively notifies the rest of the team through comments. That’s a management problem, not a reason to ban comments. And it’s the least important problem. Your comments shouldn’t be a communication medium to the developer in the next cube, they should be communications to the maintenance developer two years down the road.