That's intense and really quite silly. It makes sense to modularize large or complex (or some better modifier?) portions of the code base, but there's a point at which it just becomes too deep of a rabbit hole. I don't believe there is a formal definition of how deep down the rabbit hole that mark is, but I'm sure it would be a function of the module's (and the project's) size, readability and complexity.
Lewis and Fowler provide a nice definition in their Microservices article. [1]
They drive modularity through the pattern of change, so their judgement is based on the development, rather than the code itself.
"You want to keep things that change at the same time in the same module. Parts of a system that change rarely should be in different services to those that are currently undergoing lots of churn. If you find yourself repeatedly changing two services together, that's a sign that they should be merged."
Although that article is about services, believe it can be applied to any type of modules.
