Happy Friday,

One of the things I love about consulting is that I get to see so many different approaches to things across my clients. While I don't typically write about very specific code issues, I do work with my clients on those issues, and I wanted to share an example that contrasts two very distinct styles of writing code.

You can look at the code here.

What is chunking and splitting?

Well, in a nutshell, chunking and splitting represent two styles of writing code, and this example puts them side-by-side.

Chunked code favors keeping everything together so that it is easy to read and navigate. One bit of functionality is likely going to have everything it needs right in there.

Split code, by contrast, will turn one thing into many smaller things. Splitting favors skimming code and creating shortcuts of meaning by breaking complex code into smaller, well-named functions and classes.

Chunking

Admittedly, chunking code isn't my style, but I've worked with some folks who do, and what they care about most is being able to navigate through as few things as possible when making changes and additions.

This leads to fewer larger methods and classes that can be highly cohesive. In other words, it may not be a bad design even if it isn't your style.

One of the downsides to working this way is it also tends to create duplication. Because chunking wants everything in the place it is used, copying and pasting the same things across methods happens more frequently. This preserves the goal of readability and limited navigation but at the cost of lowered cohesion. A bug in copied code will exist in each paste.

Another downside appears with testing. Writing tests against large classes and methods has additional challenges.

Splitting

When splitters work, they favor at-a-glance simplicity. That means if 5 lines of code can be turned into a small method with a name that acts as a useful reference, they'll do that. The same applies to creating smaller classes that act in a large network.

Splitting, when done well, can also create highly cohesive code as it tends to favor reuse.

A downside to splitting code is that while it is easy to skim, it might take longer to isolate the specific place you need to change as you bounce between classes and methods trying to find where to work.

Another downside is that when code is split poorly, it can create coupling issues, as the desire to create more classes can create undesired coupling.

It is usually easier to start testing against split code, but in the long term, there can be challenges due to the network of dependencies that may exist.

An exercise...

Why am I sharing this? Well, I created this example for developers to look at and talk about their preferences, where they match their peers, and where they differ. You can do the same with your developers. Something useful to bring to the table is to suggest that they make a significant change, like adding persistence and then asking which version they'd prefer to start their work in.

If you do use this example, I'd love to hear how it goes!

Sincerely,

Ryan