Apologies, this is going to be a bit of a short rant, though it’s about something that’s been bothering me for quite a while now. Us programmers - we tend to create too many files when we write source code! But why is this bothering me?

Let’s start by looking at some facts. First of all, at execution time the machine does not care about how many files things were split into - it all lives in the same memory space. Secondly, all decent programming languages already offer different ways of structuring your code in logical units (function, classes, namespaces, etc.) in a way that can be automatically validated.

So why do we keep splitting code into different files, in different folders? In my opinion, there are only two valid reasons for splitting code into separate files: size limitations imposed by compiler/interpreter/editor and moving common code into a place where it can be shared so that we don’t require copy and paste. There is a third reason, however, which I think is the main reason why we tend to split code into files; namely that a lot of our tools used to suffer from a lack of dealing with code structure in a proper way. But that is a thing of the past - nowadays editors have features like code folding, code bubbles, editorconfig, et cetera, so this cannot really be a reason anymore.

“But wait, what is the downside of splitting code into files for other reasons than the first two?” I hear you asking. And here’s my answer: It creates an additional structural level that is ambigious and cannot be automatically validated without writing special tools for it. Suddenly you have to deal with questions along the lines of “should this code be in this file or that file?”, “will this create circular imports?” or “Where do I have to put configuration values again?” - how can this be an acceptable additional headache to anyone who is working on a major (read: not just a simple automation script) project? Every major project already has tons of other, in my opinion more important, aspects to consider - namely those directly required for fulfilling the projects duty. There are even more drawbacks that are introduced - for example, you need to deal with filesystem restrictions (granted these are pretty relaxed nowadays) and coming up with meaningful names - already a hard problem when programming - gets added to yet another layer (“defines.h” or “constants.json” are not helpful). And don’t forget the major culprit of forcing this extra burden on your co-workers.

All this takes energy away from actually solving the problems posed by your project, and thus reduce turn-around times and time-to-market.

Hence: Stop creating all those source code files!