Commenting the why not is key. Half my comments are explaining why I had to use this hack as a warning that the obvious fix doesn't work!

I would argue that if an if statement is hard to parse, replace the entire condition with simpler to read (but way more specific) variables that you assign values (the original condition expression) in the line above. No need for comments in that case

Good advice, just to add to this:

• Comments should be part of code review, having at least two pairs of eyes on comments is crucial. Something that's obvious to one person maybe isn't so obvious to another. Writing good comments is as hard or harder than writing good code, so having it checked for mistakes and quality is a must
• Comments aren't the actual documentation and aren't a reason not to write documentation to go along with your code. Often I see larger projects where each class and function is documented in comments, but the big picture and the how and why of the overall structure is completely missing. Remember that in the real world you often have a lot of folk that need to understand how the code works, who aren't programmers themselves. They can't read the code or don't have access to the code. Writing documentation is still important.
• Please for the love of god when you change code, check if the comments need to be updated as well. Not just around the immediate area, but also the entire file/class and related files. I've worked on large codebases before with a high wtf factor and having the code do something different to or even opposite the comments is a nightmare. I'd rather have no comments than wrong comments.

Don’t comment what a line is doing. Instead, write your code, especially names for variables, constants, classes, functions, methods and so on, so that they produce talking code that needs no comments.

Over and over and over again in my experience this just doesn't work. Readable code does not substitute for comments about what the code should be doing.

It's an art, not a science. Which is where I think a lot of people misunderstand software development.

This brings back trauma

okay but which 'if' is ending ??

Bash is a shit „language” and everytime i need to write the simplest thing in it I forget which variable expansion I should use and how many spaces are the right amount of spaces. It’s impossible to write nice to read bash, but even in C you can write code that comments itself.

I've been programming for almost 25 years and I'd still rather see too many comments than too few. A dogmatic obsession with avoiding comments screams "noob" just as much as crummy "add 1 to x" comments. If something is complex or non-obvious I want a note explaining why it's there and what it's supposed to do. This can make all the difference when you're reviewing code that doesn't actually do what the comment says it should.

Wrong. Too many comments makes the code messy and less readable and also it provides ZERO value. Just look at the post, WHAT is useful about ANY of that comment???

All it is is a waste of goddamn space, literal junk crowding the actual code.

I love how you admit you aren’t a developer but feel quite confident to tell us that a larger number of comments automatically means it’s better.

This person articulated it better than I: https://midwest.social/comment/10319821

Better than writing beginner level crap that is at the same time super cryptic and not documenting at all. We have a bunch of that in our codebase and it makes me wonder why these devs are writing extension methods for functionality already built into the standard libraries.

Better than writing beginner level crap that is at the same time super cryptic and not documenting at all. We have a bunch of that in our codebase and it makes me wonder why these devs are writing extension methods for functionality already built into the standard libraries.

Lol that's exactly what this was. I wrote this python script, and he went through and added comments like this a day before the deadline.

Not trying to throw shade on him though, it's more the university's fault for not explaining what makes a useful comment. I just thought it was funny

I've worked in a few startups, and it always annoys me when people say they don't have time to do it right. You don't have time not to do it right - code structure and clarity is needed even as a solo dev, as you say, for future you. Barfing out code on the basis of "it works, so ship it" you'll be tied up in your own spaghetti in a few months. Hence the traditional clean-sheet rewrite that comes along after 18-24 months that really brings progress to its knees.

Ironically I just left the startup world for a larger more established company and the code is some of the worst I've seen in a decade. e.g. core interface definitions without even have a sentence explaining the purpose of required functions. Think "you're required to provide a function called "performControl()", but to work out its responsibilities you're going to have to reverse-engineer the codebase". Worst of all this unprofessional crap is part of that ground-up 2nd attempt rewrite.

The problem is that many don’t leave the starting line