Exactly that!
Everyone can See “what” is happening, the code is right there. But the code usually doesn’t tell you “why” that is happening - good comments help understand the authors intent and give context, so you don’t have to guess.
Good comments should explain the things that are not obvious.
Good comments more than once prevented me from accidentially undoing a fix.
I was running out of time so this it’s mostly copied from (stack overflow url)
refactor when time allows
This is a side effect of doing lots of tiny websites , microcontroller code and mini web apps for under budgeted marketing projects with constantly changing designs and requirements that don’t need to last too long.
comments are for explaining why you did things a certain way
A while back I spent more than a year modifying my company’s iOS apps so that they would work properly with VoiceOver (Apple’s screen reader technology for blind people) and be compliant with FCC regulations for accessibility (and save us from $1 million per month fines lol). The thing about VoiceOver is that it’s bizarrely buggy (or was - maybe they’ve fixed the problems since then) and even when I didn’t run into VO bugs, the way that developers tended to architect these apps often made getting them to behave properly with VoiceOver extremely difficult.
I often had to resort to very strange hacks in order to get things to work, and I would always leave comments explaining what I had done for this. My manager was one of the new breed who not only thought comments were unnecessary in ALL cases but also thought comments were a “code smell” and indicative of professional incompetence on the part of anyone who used them. Whenever he reviewed my code, he would leave in the hacks (after trying and failing to fix the problems without them) but remove my comments. This resulted in many cases later of developers contacting me to ask me why some bizarre bit of code was in the app in the first place. I always referred them to my manager with an NMP (Not My Problem any more).
This resulted in many cases later of developers contacting me to ask me why some bizarre bit of code was in the app in the first place. I always referred them to my manager with an NMP (Not My Problem any more).
I hope this isn’t a real story. It would have taken you just as long to refer them to the commits with your comments still in, and run a git blame to show your manager took them out. Instead you just make yourself look unhelpful and incompetent.
Yeah, another way I’ve heard it phrased is comments are for explaining why you did things a certain way, not for explaining what it’s doing.
Exactly that! Everyone can See “what” is happening, the code is right there. But the code usually doesn’t tell you “why” that is happening - good comments help understand the authors intent and give context, so you don’t have to guess.
Good comments should explain the things that are not obvious.
Good comments more than once prevented me from accidentially undoing a fix.
Yup my comments are generally along the lines of:
This is a side effect of doing lots of tiny websites , microcontroller code and mini web apps for under budgeted marketing projects with constantly changing designs and requirements that don’t need to last too long.
A while back I spent more than a year modifying my company’s iOS apps so that they would work properly with VoiceOver (Apple’s screen reader technology for blind people) and be compliant with FCC regulations for accessibility (and save us from $1 million per month fines lol). The thing about VoiceOver is that it’s bizarrely buggy (or was - maybe they’ve fixed the problems since then) and even when I didn’t run into VO bugs, the way that developers tended to architect these apps often made getting them to behave properly with VoiceOver extremely difficult.
I often had to resort to very strange hacks in order to get things to work, and I would always leave comments explaining what I had done for this. My manager was one of the new breed who not only thought comments were unnecessary in ALL cases but also thought comments were a “code smell” and indicative of professional incompetence on the part of anyone who used them. Whenever he reviewed my code, he would leave in the hacks (after trying and failing to fix the problems without them) but remove my comments. This resulted in many cases later of developers contacting me to ask me why some bizarre bit of code was in the app in the first place. I always referred them to my manager with an NMP (Not My Problem any more).
I hope this isn’t a real story. It would have taken you just as long to refer them to the commits with your comments still in, and run a git blame to show your manager took them out. Instead you just make yourself look unhelpful and incompetent.
Bold of you to assume they were using source control under that manager…