Not an opinion i hold. But i’ve heard others say that code should be written in a way thats simple and easy to understand, e.g. variables/methods with meaningful names. Logic kept simple within aptly named methods that define what it does.
The stance seems to be that if you should keep code simple enough, or named well enough that comments aren’t necessary in the first place (excluding niche situations).
I can even begin to imagine how I’d explain with only code how various hacks are necessary because of a bug in something it’s interfacing with, or how various mathematical expressions were derived.
Yeah. Code explains how, comments explain why. I can see what happens, but I surely cannot see why someone thought this was a good idea. Please don’t write intaddSomeSpecificFillerBytesBecauseTheLegacyAPICountsTheHeaderAsPartOfTheDataStructureAndTheCurrentAPIDoesNot()
I ran into this when I was doing the Accessibility/VoiceOver stuff for an iOS app. VoiceOver is (or was at the time - maybe they’ve fixed most of the problems) buggy as shit in lots of weird ways, and I sometimes had to do strange things in the code to get things to work properly in VoiceOver mode. I would always add comments explaining why I had to do these weird hacks before I would submit the code. The guy approving our pull requests was a young developer solidly in the “all comments are bad” camp and he would always just delete my comments. Sometimes, because he wasn’t even remotely aware of what VoiceOver was for or how it worked, he would also delete the changes I had made to get VO to work in the first place. For good measure, he also badmouthed me to our bosses whenever possible, calling me technically incompetent (because of the comments).
The fun part was when our app failed its annual accessibility review (badly) and he had to scramble to restore all my changes that he had deleted. He didn’t restore my comments, though, which apparently led to us failing the following year’s review as well because other developers deleted my shit, having no idea why it was in the app. He and I had both been laid off at that point so there wasn’t any institutional memory of it at that point - another reason why comments are important, as they’re essentially the only form of documentation that there’s even a chance future developers will read.
Not an opinion i hold. But i’ve heard others say that code should be written in a way thats simple and easy to understand, e.g. variables/methods with meaningful names. Logic kept simple within aptly named methods that define what it does.
The stance seems to be that if you should keep code simple enough, or named well enough that comments aren’t necessary in the first place (excluding niche situations).
I can even begin to imagine how I’d explain with only code how various hacks are necessary because of a bug in something it’s interfacing with, or how various mathematical expressions were derived.
Yeah. Code explains how, comments explain why. I can see what happens, but I surely cannot see why someone thought this was a good idea. Please don’t write
int addSomeSpecificFillerBytesBecauseTheLegacyAPICountsTheHeaderAsPartOfTheDataStructureAndTheCurrentAPIDoesNot()I ran into this when I was doing the Accessibility/VoiceOver stuff for an iOS app. VoiceOver is (or was at the time - maybe they’ve fixed most of the problems) buggy as shit in lots of weird ways, and I sometimes had to do strange things in the code to get things to work properly in VoiceOver mode. I would always add comments explaining why I had to do these weird hacks before I would submit the code. The guy approving our pull requests was a young developer solidly in the “all comments are bad” camp and he would always just delete my comments. Sometimes, because he wasn’t even remotely aware of what VoiceOver was for or how it worked, he would also delete the changes I had made to get VO to work in the first place. For good measure, he also badmouthed me to our bosses whenever possible, calling me technically incompetent (because of the comments).
The fun part was when our app failed its annual accessibility review (badly) and he had to scramble to restore all my changes that he had deleted. He didn’t restore my comments, though, which apparently led to us failing the following year’s review as well because other developers deleted my shit, having no idea why it was in the app. He and I had both been laid off at that point so there wasn’t any institutional memory of it at that point - another reason why comments are important, as they’re essentially the only form of documentation that there’s even a chance future developers will read.