10 months? More like a weekend for me.
I don’t care how much you think your code is readable, plain text comments are readable by everyone no matter the proficiency in the programming language used. That alone can make a huge difference when you’re just trying to understand how someone handled a situation.
Comments explain why, not what. Any comments that explain what a section of code is doing would probably be better off as separated methods.
Apart from basic documentation comments, like JavaDoc or C#'s XML documentation comments.
There’s nothing limiting what a comment should be as far as I know.
As an example of what I mean, I’ve seen in a 10k+ lines python code a few lines of bit manipulation. There was a comment explaining what those lines did and why. They didn’t expect everyone to be proficient in bit manipulation but it made it so that anyone could understand anyway.
There’s nothing limiting what a comment should be as far as I know.
Nothing technical, sure. Just good coding practices.
There’s nothing keeping the comments up to date with the code. Comments should be sparse and only on sections that aren’t obvious why they’re being done
Then someone needs to change something about the code and doesn’t bother updating the comment. Now you still have uncommented code but with a comment that confuses instead of helping.
IMHO the issue in this situation is not the comment but that the person updating the code didn’t do his job properly which shouldn’t be an excuse not to do it from the start.
Basic rule if someone claims X magically solves a problem they don’t follow X and are a huge generator of the problem.
For example people who claim they don’t need to write comments because they write self documenting code are the people that use variable names x1,x2,y, etc…
Similarly anyone you meet claiming Test Driven Development means they have better tests will write code with appalling code coverage and epically bad tests.
This is Bill.
Bill doesn’t need to minify his code, he names things using a single character even in compiled languages.
Bill is a heckin chad who can guess what the code does merely by looking at types and control flow.
Be like Bill
I’m no heckin chad like bill ima soyjak :(
Comments are lies that will happen sometime in the future
Comments are always overlooked if gode gets refactored. Language servers can’t/won’t parse them and they’re easy to overlook.
If you name your functions/variables clearly, put complex logic into clearly named functions and keep the same level of abstraction in every function (which never exceeds roughly 50 lines), you hardly need any comments, if any.
Comments are for behavior that’s not possible to convey clearly through code.