Me writing docstrings: God this is so much work for nothing... my code should speak for itself.
Me 6 months later: Thank god I wrote docstrings, what is this garbled mess.
Me 6 months later: Thank god I wrote docstrings, what is this garbled mess.
To each their own, but comments are generally a positive addition to code.
This does sometimes entail a few 'what'-style comments, so I'm disappointed to regularly read of programmers that have apparently taken up arms against them.
a "wat" comment, like the meme, is more of a "this is a really weird blob of code that might be obvious when you break the whole thing apart; but, what it's doing is _this_ this is the implementation of it because we have a complicated data structure that's connecting all these pieces"
I think in one of them, only a single source file (C++) had comments, and there were more comments than code. I was explaining an intricate locking pattern around a data cache.
Like you suggested, I added the comments after I'd done the work because it was a work in progress. I added the comments because it was a very fragile piece of code and sensitive to changes (e.g. really easy to cause a deadlock or race condition if changed).
When I'm writing something I'm generally "top down", breaking the problem into sub-tasks. In this mindset I'll often start a sub-task with a comment describing what it needs to do, and then set out to do it. If it turns out I was wrong about what I needed to do then I update the comment, but that's not that common.
I started this technique early in my career back in the late 90s after reading “Code Complete”.
It also helps me to pick back up faster if I get interrupted.
The idea is to write a rough draft that covers what the project is, what it does, the API structure, and how to use the project, then write the code, “projecting the document”, and finally sort out the documentation - comments in the source, everything else in a manual page, article, or research paper.
Do you ever get back to code you wrote and find a lot of misleading comments that you simply forgot to delete/update? Or are you always updating the comments before you try a new approach if the first one didn't work out?
//increment i
//Call the API to get a list of customers.
List<Customer> customers= GetCustomers();
Level 1: Garbage code with no or bad comment.
Level 2: Garbage code with good comments.
Level 3: Good code with comments
Level 4: Code good enough that it doesn't need comments, with rare exceptions.
Each level is better than the previous. You can't level up directly from 1 to 4.
Still, 4 is the best level. I know it sounds weird if you haven't seen it.
1. I did allow for "rare exceptions". Some things do need to be explained outside of the code. Maybe we're not so different after all :)
2. There are a number of techniques to write such code. Before I learned them, I had NO IDEA. One is to take what would have been comments and use them as variable or function names. This includes (and I had real resistance before I accepted this) breaking out a variable of function only in order to give it an informative name. "Level 4" doesn't just happen. You work at it for a long time and sharpen your skills in that area.
3. To me, much of the art of writing software is to find ways to divide a complex problem into simple pieces. If my code is real complex, I look for simpler way to write it. And I look hard.
I know some people don't feel that way, because I've been dinged for it in code reviews as something that should be covered in unit tests. But I think digging through unit tests to glean the structure of an object adds a lot of overhead.