The only moment you write comments is when you are doing something extremely weird for a specific reason that will not be immediately obvious and you want to warn the person doing a refactor in the future. In any other case, writing self documenting code is the way. If you are unable to do that, then your code needs to be rewrtitten.
Mmmm kind of? I wouldn’t categorize most comments as describing “extremely weird” reasons, though. Code will generally explain the “how”, while comments can describe the “why”. For example, think of an enum with ViewSize “mini” and “full”. It might be nice to have a comment to briefly summarize what ViewSize is meant to represent, and maybe link to a spec. Basically, a comment here will connect the intention with the implementation.
A more inline-comment example of this might be if there’s a slightly nuanced case that you want to be very clear about, ala maybe a Javascript true/false/null case, where you might be checking === false, and specifically don’t want someone to refactor it into a falsy check. Kind of contrived example , but that sort of thing. This is probably more the “extremely weird” comment you’re talking about; almost just a warning that this might not be what you think it is.
The other common use-case I find good for comments is for summarizing the goals/purpose of a complex function. This is mostly for future people who might utilize this function, and don’t want to read through a bunch of code, just to remember the nuances of what it’s supposed to do. For example, a “sortEvents” function, you may want to summarize the business requirements of the sort at the top. Although, this kind of thing may be different depending on how documentation is stored.
Self documenting code is a myth as what’s self documenting to one person is not to the next. Code comments and process/workflow documentation is needed for a healthy codebase.
I thought the same, until I spent a few years on a codebase where self-documenting code was enforced with detailed code reviews. That does a very good job of clearing up the ambiguity.
If you can’t get that kind of review, then by all means use comments.
I have given well documented code to plenty of juniors, it comes with being a senior dev / techlead. And it was perfectly understood. Maybe you simply don’t write self documenting code.
You dont. Thats why you write comments!
You dont. Thats why you write code that explains itself. For higher level info you write documentation.
Yes. And also comments :-)
The only moment you write comments is when you are doing something extremely weird for a specific reason that will not be immediately obvious and you want to warn the person doing a refactor in the future. In any other case, writing self documenting code is the way. If you are unable to do that, then your code needs to be rewrtitten.
Mmmm kind of? I wouldn’t categorize most comments as describing “extremely weird” reasons, though. Code will generally explain the “how”, while comments can describe the “why”. For example, think of an enum with ViewSize “mini” and “full”. It might be nice to have a comment to briefly summarize what ViewSize is meant to represent, and maybe link to a spec. Basically, a comment here will connect the intention with the implementation.
A more inline-comment example of this might be if there’s a slightly nuanced case that you want to be very clear about, ala maybe a Javascript true/false/null case, where you might be checking === false, and specifically don’t want someone to refactor it into a falsy check. Kind of contrived example , but that sort of thing. This is probably more the “extremely weird” comment you’re talking about; almost just a warning that this might not be what you think it is.
The other common use-case I find good for comments is for summarizing the goals/purpose of a complex function. This is mostly for future people who might utilize this function, and don’t want to read through a bunch of code, just to remember the nuances of what it’s supposed to do. For example, a “sortEvents” function, you may want to summarize the business requirements of the sort at the top. Although, this kind of thing may be different depending on how documentation is stored.
Self documenting code is a myth as what’s self documenting to one person is not to the next. Code comments and process/workflow documentation is needed for a healthy codebase.
I thought the same, until I spent a few years on a codebase where self-documenting code was enforced with detailed code reviews. That does a very good job of clearing up the ambiguity.
If you can’t get that kind of review, then by all means use comments.
Lmao. Sure buddy.
♫tale as old as time♫ ♫opinions that are mine♫
Not really an opinion when most companies run on self documenting code since time immemorial.
Try handing over your “self documenting code” to a junior dev who doesn’t know the language it’s written in and see how far they get with it.
Now hand that exact same codebase with comments to the same junior dev, and I guarantee you they’ll get further than without the comments.
I have given well documented code to plenty of juniors, it comes with being a senior dev / techlead. And it was perfectly understood. Maybe you simply don’t write self documenting code.
Lmao. Sure buddy.