Marcelo's WebLog : Design

Debugging and PDBs

marcelolr — Wed, 13 May 2009 00:00:00 GMT

Debugging is hard. There are many things we do to make it easier on ourselves.

Feature-level things like building tracing and logging capabilities.
Design-level things like having clear points at which state is checked for consistency (internal or parameters passed in, for example), so we narrow down the areas where things might have gone wrong.
Code-level things like making sure that exceptions bubble up without losing the stack.
Operational-level things like using tools to capture dumps on failure and monitoring performance counters, to have good data about the program and its environment.

John Robbins has a great post about build-time and environment-setup-time things you can do to make your debugging life easier, and PDB files are a big part of it. If you haven't debugged symbol-indexed and source-indexed programs in the past, you're in for a treat.

http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx

Enjoy!

Abstraction, simplicity and predictability

marcelolr — Fri, 17 Apr 2009 00:00:00 GMT

As a short follow-up to my last post on reasoning about code, I wanted to touch upon abstraction in general - meaning "information hiding" in the general sense, and not necessarily a particular programming mechanism such as polymorphism or some such thing.

Abstraction buys us a number of good things for a design - the ability to think about things using fewer concepts (because we can focus on the more general stuff) and the ability to change system behavior by changing an isolated part (the abstracted part), to name the first two that come to mind. In general, abstraction is a great way to have the consumer of the abstract focus on something, by hiding or diverting focus away from the implementation particulars.

There is a price to the use of abstraction, however. Well, there's more than a single thing in practice, but I want to focus on one. When you choose what to hide, you may run into the risk of making the system behavior harder to predict, and as such more difficult to reason about.

For example, if my abstraction doesn't explain some basics of the performance characteristics of the implementation, my only recourse is to profile to understand how the system will behave overall (you should profile anyway, but that's a separate matter). Or an abstraction might not give clear rules as to what happens when an object enters an error state - should you "not touch it", try to dispose of it, continue using it, or what?

I'm not advocating any particular solutions or tradeoffs here, but instead I just want to bring awareness to the fact that there is a trade-off to be considered. It's good to know how others will reason about our code, even if just to say "this isn't specified and you can't count on anything, so you should be careful and something". Whether the "something" is 'ignore this', 'bail out', 'work around this', 'assume worst case', 'terminate the process', or something else, there should still be a clear way of explaining and reasoning about our code.

Reasoning about code

marcelolr — Thu, 16 Apr 2009 00:00:00 GMT

When we have conversation about API design, or more generally about fragments of code that we write or we think customers will write, we often talk about reasoning about code. We typically mean that someone reading the code will be able to understand the implications of making an API call for example, and write clean code accordingly. There is always a component of simplicity in code someone can reason about.

For example, someone might say that functional-style code is easier to reason about, because there are no side-effects and so you can concentrate on whatever local computation a given function does. Or someone might say that it's hard to reason about code that deals with an object that has entered an error state, because the results of operations are undefined and it's hard or impossible to keep track in your head about what the consequences of any given API call might be.

I think that beyond simplicity, the core of code you can reason about is predictability. To the extent that you can predict the behavior of a fragment of code, and it's straightforward enough, you can reason about what the code does and what the impact of changes would be.

Going back to the previous examples, functional-style code is easier to reason about because once you predict what it does locally, you understand the complete picture - there are no other, off-to-the-side effects. When an object is in an error state, you can't use it anymore ("you can't touch it", you might say) if you can't predict what it will do - the core of the problem is that you can no longer infer things about its behavior and put it together with other concepts to use it.