| Good points. Some rebuttals: First, in the context of this argument, I'm talking about work in high level languages like Python, JS, fairly expressive C++, etc. If we were coding in assembler -- LEA, LDR, JNZ.. -- I'd definitely want a ton of low level comments! When I say wasting space, it's not about disk space, or shrinking your screen size, or even formatting. It's more about what you can see all at once. Think back to a recent time when you had a tough to fix bug. Like something really not trivial that you beat yourself up about for a while. I bet it involved you working through various levels of libraries, opening them side by side or paging back and forth, trying to figure out what went wrong in the logic. It probably wasn't cuz you misunderstood what a variable did. We have great ways to document that, like the function header. Now imagine that process if it's all on the same screen. If everything feels "tangible" to you, because each level of logic (to some reasonable point) is visible, accessible. When I encounter a code base with hundreds of source files in various folders and some flimsy abstraction tying it all together, such that I can't see a clear delineation between parts, I go nuts! Here's a very practical example. Imagine you have some library that wraps a remote API. Something important, like Payments. The hard part there is understanding failures (does it retry?), edge cases (whats diff when i run a test CC#?), stored state (can I resume this from a different part of the code?).. those things are mighty hard to glean even from good statement-level comments, even if I could take the time to read all 3,000 lines of code. We need higher level great docs. I'd love to code in English or something like it, but looking at the code on my screen right now, those would be some really complex sentence structures. :) |
You'd trip at my code in the payments example because whatever is 3000 for you would easily be 5000 for me. Not only do I write comments before each line of verbose syntax, but I also add blank lines after braces and between logical "blocks" of operations.
However, that structure also gives me a mostly searchable index of every logical block of my code. That gives me a very straightforward way to bisect down to the problem, no matter how far away that code is linearly. It feels like lots of little sandwiches instead of a giant sandwich, and I'm looking for one bad slice of meat. I at least can quickly scan and jump to sandwiches containing meat when they are so explicitly separated and annotated.
I'd also argue that since good comments (written before syntax) can be read as their own document, I also have full coverage documentation by default. If I wanted to produce a crazy deep documentation page, I could actually just pull every line starting with // or /* (but really I just use Docstrings/JSDoc/etc on top of my inline comments).
I believe I've arrived on this out of practicality. I maintain 10+ codebases of differing platforms at any one time, and my most frequent problem in life is arriving at a codebase and thinking "Okay, what was going on here?". My approach now is just "read the green" (I color my comments slightly green gray) and within minutes, I can understand the entire functionality of that code and search for patterns I know will exist. I don't believe that's possible in equivalent time by executing the program line by line in your head.