21–30 of 42 posts
Why is "public static void ..." written in Cyrillic here? I guess this might be a joke?
In Writing Solid Code [0], Steve Maguire recommends stepping through every line of code, in a symbolic debugger. Sounds crazy, but I usually end up doing that, anyway, as I work. Another tip that has helped me, is to add code documentation to inline code, after it’s written (I generally add some, but not much inline, as I write it. Most of my initial documentation is headerdoc). The process of reading the code, helps…
> Sounds crazy, but I usually end up doing that, anyway, as I work.
This doesn't sound crazy to me. On the contrary, it sounds crazy not to do it.
How many bugs do we come across where we ask rhetorically, "Did this ever work?" It becomes obvious that the programmer never ran the code, otherwise the bug would have exhibited immediately.
Does this person also identify performance issues by reading the code? This is completely impractical.
This sounds like every technical job interview.
In Writing Solid Code [0], Steve Maguire recommends stepping through every line of code, in a symbolic debugger. Sounds crazy, but I usually end up doing that, anyway, as I work. Another tip that has helped me, is to add code documentation to inline code, after it’s written (I generally add some, but not much inline, as I write it. Most of my initial documentation is headerdoc). The process of reading the code, helps…
> In Writing Solid Code[0], Steve Maguire recommends stepping through every line of code, in a symbolic debugger. > Sounds crazy, but I usually end up doing that, anyway, as I work. This doesn't sound crazy to me. On the contrary, it sounds crazy not to do it. How many bugs do we come across where we ask rhetorically, "Did this ever work?" It becomes obvious that the programmer never ran the code, otherwise the bug w…
Writing Solid Code is over 30 years old, and has techniques that are still completely relevant, today (some have become industry standard).
Reading that, was a watershed in my career.
[flagged]
>If you want a single piece of advice to reduce your bug count, it’s this: Re-read your code frequently. After writing a few lines of code (3 to 6 lines, a short block within a function), re-read them. That habit will save you more time than any other simple change you can make.
So, more focused on a ground-up, de novo thing as opposed to inheriting or joining a large project. Different models of "code" and different strokes for different folks, I guess, but the big takeaway I like from that initial piece is:
>I spent the next two years keeping a log of my bugs, both compile-time errors and run-time errors, and modified my coding to avoid the common ones.
It was a different era, but I feel like the act of manually recording specific bugs probably helps ingrain them better and help you avoid them in the future. Tooling has come a long way, so maybe it's less relevant, but it's not a bad thing to think about.
In the end, a lot of learning isn't learning per se, but rather learning where the issues are going to be, so you know when to be careful or check something out.
[flagged]
There is a layer above this: To understand, really, what are the requirements and to check if are delivered. You can have perfect code that do nothing of consequence. Is the equivalent of `this function is not used by anything` but more macro.
But of course, the problem is to decipher the code, where what you say helps a ton.
Isn't this basically what a debugger gives you? You say "follow the control flow" and "track state," but those are exactly what I do when stepping through code with invariants and watchpoints. The only real difference I see is that reading doesn't require a reproducible example, while debugging does. Otherwise, the habits seem nearly identical.
You can manipulate values in a debugger to make it go down any code path you like.
[flagged]
Yes, yes, why bother reading your code at all? After all, eventually 15 years will pass whether you do anything or not!
I think if you read it while it's 500 lines, you'll see a way to make it 400. Maybe 100 lines. Maybe shorter. As this happens you get more and more confident that these 50 lines are in fact correct, and they do everything that 500 lines you started with do, and you'll stop touching it.
Then, you've got only 1,5m lines of code after 15 years, and it's all code that works: that you don't have to touch. Isn't that great?
Comparing that to the 15m lines of code that doesn't work, that nobody read, just helps make the case for reading.
> What actually prevents bugs at scale is boring stuff: type systems, invariant checks, automated property testing, and code reviews that focus on contracts instead of line-by-line navel gazing.
Nonsense. The most widely-deployed software with the lowest bug-count is written in C. Type systems could not have done anything to improve that.
> sure, but treating it as some kind of superpower is survivorship bias
That's the kind of bias we want: Programs that run for 15 years without changing are the ones we think are probably correct. Programs that run for 15 years with lots of people trying to poke at them are ones we can have even more confidence in.