Skip to content

The Core Folder Anti-Pattern

There is an interesting pattern that you can find in many projects, that usually starts with a good idea and turns into a dump in no time: the core folder. You start with an application and think about the core business, the important stuff. So, you go on and create a core folder. Here is now the place for the important stuff, right? No. Here is the start of your mess that from now on only grows.

Core and common are different things

The problem with the core folder is that what goes there is not the core business supporting parts of the application. It is a space for things you want to reuse, reuse in many parts of the application. That code is not core to the business nor the application. It is common code that offers functionality that you need in many places. Unfortunately, the more common the code is, the less “core” it can be. It still is important, but only an afterthought in terms of the business.

The dump is growing

Naming things is hard, finding a fitting place for code is even harder. But with the core folder we have now a place for everything. You do not know where to put it? Is it important, then put it into core. And let me tell you, there is no unimportant code at this stage of development. Now the core folder grows, the naming declines and we move fast and undisturbed into the direction of an unmaintainable application. All in the name of importance and reuse.

No reuse of the core folder

But even if we ignore all the fundamental problems and say that this is just nitpicking and syntactical sugar, there is more to show the futility of this approach. The core folder should allow reuse, but how will we reuse the code there if it is only in a namespace in the main project? Will we reference the main project everywhere? Will we load all the code of the whole application just to use the helper function inside the core namespace?

What usually happens is the opposite. Developers create a core folder in each project, which leads to .Net solutions with 10 projects and 8 core folders. A few projects do not yet have a core folder, but most will have one. That pattern repeats itself in the test projects, where we end up with most projects having a core folder but not all.

Digging out of the core hole

If you do not catch this pattern early on, you end up with a core folder in all your projects and half your classes will be in them. Sometimes a form of reuse happens by copying the code from one project to another, sometimes by including it as a dependency. Either way, the mess keeps growing.

To stop it, we need to act fast and decisive. A good list of steps to follow for me is this one:

  1. Write a test that checks for the number of classes inside the core folder and make sure that this number does not grow. If a developer adds another class, this will fail the build and force them to find a different place to put their code. That way we stop the growth and can use the current number of classes as a high-water mark that we continue to lower until we reach 0.
  2. Make a list of the code in the core folder and assign a category to each class. Is it UI related? Is it infrastructure? Is it for database access? The categories vary from project to project, but you find a fitting set of 5 to 10 categories for each application.
  3. Refine your categories and divide the classes in core into reusable projects or NuGet packages, so that code that should be reused can be reused in other applications.
  4. The remining classes are application-specific and need to stay somewhere in the application. Here we need to do the hard work of finding a fitting abstraction that gives us a better location for these classes than the core folder. When we found a better place, we move the classes to their new location.
  5. If the core folder is now empty, we rewrite our test from step one to check that there is no core namespace or folder with this name in any of our projects in this application.

All this looks easy, but cleaning up the mess is demanding work. If it would be easy to find the right name, we would not end up in the mess we now need to clean up. Therefore, prepare yourself for a bumpy ride with a lot of discussions and many angry developers.

This clean-up will hurt a few feelings, but you can do it now with 10 classes or later with hundreds of wrongly placed classes. Trust me, the problem does not go away if we wait.

Conclusion

What starts innocent with a core folder and a lot of good intentions quickly turns into a rotting garbage dump. It goes unnoticed for far too long, but at some point, you can no longer ignore it. Then it is time to act, to split the mess up and start refactoring that part of the application. The sooner you notice it, the less work it takes to find a proper place for each class in the core folder. Therefore, make sure to check if core folders start to show up in your applications and act early.