Spamming comments is rather controversial, especially in high-level languages. Problem is, they only show up in one place, so they’re just not very useful, but also have a high chance of becoming inaccurate over time. In particular when you spam them to explain relatively trivial stuff, people will stop reading them, meaning they won’t update them.
The ‘what’ can be documented with meaningful variable/function names, log/error/assert messages and perhaps most importantly unit/integration tests (which should be understood like a specification that checks automatically that it’s applied correctly).
Comments are indispensible for explaining the ‘why’, though, whenever that is not obvious.
Yeah, there’s a balance. If you comment every row of your code, you aren’t naming things clearly. If you never comment, the context is always incomplete.
“Clearly” is also subjective. What might be perfectly clear to me reading my own code may be really confusing to someone else, and vice versa. Especially if the person reading the code isn’t as familiar with the language as the person who wrote it, or if the code is using some syntactic sugar that isn’t super common, or plenty of other reasons.
Aren’t you supposed to spam comments and use meaningful variable and function names? That’s what I do with my bash scripts.
Oh wait I ain’t a programma’. You call this shit R9GFJKL34LTYLKFÇDS and hope for the best, right?
I’m also not a programmer, you’ll find my longest comments to explain why I’ve done some terrible mangling, what this does and how.
Spamming comments is rather controversial, especially in high-level languages. Problem is, they only show up in one place, so they’re just not very useful, but also have a high chance of becoming inaccurate over time. In particular when you spam them to explain relatively trivial stuff, people will stop reading them, meaning they won’t update them.
The ‘what’ can be documented with meaningful variable/function names, log/error/assert messages and perhaps most importantly unit/integration tests (which should be understood like a specification that checks automatically that it’s applied correctly).
Comments are indispensible for explaining the ‘why’, though, whenever that is not obvious.
Yeah, there’s a balance. If you comment every row of your code, you aren’t naming things clearly. If you never comment, the context is always incomplete.
You don’t comment what something does, ir can clearly be seen from the code itself. You comment why you do it.
“Clearly” is also subjective. What might be perfectly clear to me reading my own code may be really confusing to someone else, and vice versa. Especially if the person reading the code isn’t as familiar with the language as the person who wrote it, or if the code is using some syntactic sugar that isn’t super common, or plenty of other reasons.
Yes, that would be the context I’m talking about
Bonus points for the cedilla
Hello fellow basher.