I'm taking the blog in a different direction for a while. We'll be looking at Maintainable Code in the context of general problems you might want to solve. In particular, we'll be looking at various ways to reuse code for the next few articles.

I will also try borrowing from the style of Herb Sutter, posing questions to you in one blog entry to be answered in the next. I'm hoping you'll post your answers in the comments!

So, for next time:

1) Why is it beneficial to sometimes have the same function/struct name do different things depending on their parameters? For example:

assert(abs(-5) == 5); //calling abs with an int
assert(abs(-2.3) == 2.3); //calling abs with a double

2) What techniques allow us to create such differences? How can I write code so that calling a function foo(5) may produce different results than calling foo("hello")?

3) For each technique that you identify, in what ways is the code allowed to vary? Is it possible for me to sneak in some optimization code for a particular case when I use one technique vs. another?

4) Do the techniques you've identified work equally well for functions and structs? Why or why not?

What lies ahead:

Here's a rough preview of what I expect to be writing about over the next several blog entries. Everything is subject to change. We will be finding solutions to these fundamental problems:

1) How do I reuse the same implementation code with different types?
2) How do I use the same code to invoke different fundamental implementations selected by type?
3) How do I reuse code for some types but select different fundamental implementations for others? What if there are patterns to the "exceptions" to the "default code"?
4) How do I select between different implementations when only a small piece of the implementation varies between types?
5) How can I add the same set of features (capabilities) to completely unrelated types? Part 2: How can I do this selectively, at an instance by instance granularity?
6) How can I design my code so that it is easy to test and try different data structures to determine which is fastest?

Along the way, we'll explore ideas like how we can insulate our users from such problems, so that we can provide a higher level of abstraction that "just works", and doesn't look like a mess from the outside. We'll also talk about deliberately bringing our users into the conversation to let them selectively change the behavior of our code. Lastly, we'll be sure to keep a close eye on the performance and maintainability implications involved in the solutions to these problems.

A Reminder:

Don't forget to post your answers to today's questions in the comments! (They'll help me both provide more complete answers and also explore other fundamental questions we might ask about code reuse).