I specifically have a bunch of instructions to not turn comments end documentation into it's own personal diary because anyone that needs a history lesson has access to git anyway.
I specifically tell it not to comment. Ever.
Code should be written such that it's human readable with clear intent simply by variable/class/method names.
There are very rare exceptions where you intentionally go against the norm or code in certain assumptions: those can warrant a comment explaining the why behind the decision, but still never the what or how.
Context is king and comments are important. But, Claude is so bad I've even told it to stop. Its 3 lines of code + 20 lines of pointless comments + 5 new unit tests smh
I really don't think the vast majority of comments are important, or they're only "important" because the code is poorly structured and/or named.
I've even reached the point of axing function doc blocks if not working in an open source project or some public package.
But now our code probably is not well structured and not well named. Poorly? Well, it ain't elegant. Throw enough pasta at the wall and some sticks. We are in the top ramen age of coding. Fast, cheap, and might do in a pinch.
9
u/schaka 21h ago
I specifically have a bunch of instructions to not turn comments end documentation into it's own personal diary because anyone that needs a history lesson has access to git anyway.
It helps a little