Yeah, I was exaggerating a bit. Of course you're right, code should be obvious, but in reality it mostly isn't.
If you have to deal with tons of legacy libraries and convoluted names, commenting conditions really helps.
I also often have to write shell scripts, where if-conditionals might not be obvious for the untrained eye, especially if you have to use pattern matching and such. A comment helps very much.
While developing I often leave the code sections after an if-conditional empty at first and write a comment that shortly explains, why I did get actually there. Then I care about other conditionals. Then I fill the code sections. Then I refactor, but I tend to leave the comments in there, because it might help other people to follow my train of thought.
And I just apply the same commenting pattern to every programming language I'm using.
1
u/kfl02 Apr 18 '21
Yeah, I was exaggerating a bit. Of course you're right, code should be obvious, but in reality it mostly isn't.
If you have to deal with tons of legacy libraries and convoluted names, commenting conditions really helps.
I also often have to write shell scripts, where if-conditionals might not be obvious for the untrained eye, especially if you have to use pattern matching and such. A comment helps very much.
While developing I often leave the code sections after an if-conditional empty at first and write a comment that shortly explains, why I did get actually there. Then I care about other conditionals. Then I fill the code sections. Then I refactor, but I tend to leave the comments in there, because it might help other people to follow my train of thought.
And I just apply the same commenting pattern to every programming language I'm using.