Things I learned the hard way
Gregor Mückl
gregormueckl at gmx.de
Thu Jun 27 09:10:36 UTC 2019
On Wednesday, 19 June 2019 at 02:41:31 UTC, Exil wrote:
> On Wednesday, 19 June 2019 at 01:15:33 UTC, Walter Bright wrote:
>> https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/
>>
>> Debuggers are over-rated
>> I heard a lot of people complaining that code editors that
>> don't come with debugging are terrible, exactly because they
>> don't come with debugging.
>>
>> But when your code is in production, you can't run your
>> favorite debugger. Heck, you can't even run your favourite
>> IDE. But logging... Logging runs everywhere. You may not have
>> the information you want at the time of the crash (different
>> logging levels, for example) but you can enable logging to
>> figure out something later.
>>
>> (Not saying debuggers are bad, they just not as helpful as
>> most people would think.)
>
> This I don't agree with. Maybe specifically for his job it
> might not have been. If you are more of a tech support and you
> need to remote into a customer's computer and use whatever they
> have available on their computer, sure. But I doubt that's the
> case for a large majority of programmers. Also you can debug a
> crash that happened on a customer's computer for a native
> production application with a stack trace. You might be missing
> some variables because it is a production build that were
> optimized away but you still get a lot of relevant information.
I think you're looking at this paragraoh from the wrong angle.
For me it is more about the skill of debugging than about the
availability of a debugging tool. I would rewrite it as "learn
how to debug code in your head". It makes more sense that way: be
sure that you can reason about your code's behavior reliably
without tool support. This includes keeping things as simple as
possible and knowing how stuff works, including stuff you didn't
write.
So, for example the nifty container class you're relying on may
make things simpler to code, but maybe you're hitting a usage
pattern that the code on the other side of the container
interface doesn't like. In C++, this means e.g. knowing exactly
when a std::vector might reallocate its backing memory. And that
might be the reason that the one reference you kept from before
the push_back call might no longer be valid. Figuring out things
like that with a debugger is usually hard because of the way most
STL implementations are written. Their internals might be
suppresses by the debugger, show up as a convoluted chain of
method calls, or be optimized so much that you can't make heads
or tails of it.
So, bottom line: even if you have a debugger, don't count on it.
If you get that right, this make you a better programmer and
improves your code.
Enough preaching to the choir.
More information about the Digitalmars-d
mailing list