Context

I believe context as a concept is one of the most under-appreciated ideas in programming. When it is not appreciated and planned for, context can leak into areas of code that it shouldn't.

In the "Data, Context, and Interaction" (DCI) model, context takes a central role. The intuition is that code and ideas may be correct in a certain context while being confusing and unclear in another.

We have an intuitive grasp of what context is. If we talk about a small piece of code, context might refer to code from the same package, class, or module. Or, it might refer to the code's usage – the context from which it is invoked. I think this is the most subtle form of coupling due to context that may arise.

Occasionally, I encounter code that looks a little strange. Typically, I'll then do a search of the code base, trying to find where that code is called from. Normally, I'm able to understand what confused me: some oddity in the caller prompted the author to change the code-in-question, adding some behavior specific to that caller.

What problems does context leaking cause?

1. It hampers reuse. I'm less likely to find code useful that has strange pieces that were specific to some other story from a year ago. Often, the behavior
2. It makes the code more complicated. As I hinted at above, this kind of thing almost always makes the called code look bizarre. The only way to make sense of it being to look up and understand the context of another caller.

What can be done?

1. Limit context-specific code to that context. For example, don't add logic specific to CSV importing to your core models. If you identify something that is essential to the model, sure, add it.
2. Break your application into modules. When all the concepts in your application are blended together, it can be really hard to identify kind of context leakage.

Failure to recognize context and conceptual boundaries will make your code worse. Throughout my career, it's something I've seen over, and over, and over again.