1

It appeared, that I have in my pet project two abstractions: asset loaders and drawing tasks. For each abstraction I have some classes representing them (currently a single class for drawing task abstraction and factory, which returns new classes, for asset loaders), a store (formerly a manager, but I found it is a bad practice to use "Manager" word in naming) and some other helpers (e.g. decorators). I am thinking how to put all this in a project structure. When I started the project, there was a folder for abstraction itself, separate folder for stores, and another one for helpers. Currently I realized, that this two systems are actually parallel, and hence should be developed separately. So I decided to create to folder for each.

So what I am interesting it:

  • How do you split your files in directories:
    • By use
    • By abstraction they describe
    • By language construction types (i.e. classes, functions)
    • Something else
  • How do you name them:
    • you use some words, representing it is a group (i.e. assetLoadersSystem, assetLoadersUtils ...)
    • you name it as main concept (just assetLoaders directory with the same file in it)

Is there any place I can read about it? I found some interesting chapters in "Clean code" and "Code complete" about variable naming tips. Is there anything like that for my problem?

New contributor
Yaroslav Kishchenko is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • What language is this for? Conventions and best practices vary between languages. – Martin K Feb 13 at 21:30
  • 2
    @MartinK I am using JS here, but I think my question is language neutral. Just to mention, I am not asking for camelCase vs snake_case, or something similar. I am more interesting in files grouping logic and how to name those groups after. – Yaroslav Kishchenko Feb 13 at 22:08
1

I try to avoid complex directories structures to begin with. Distributing files across directories for no particular reason has no particular advantage, yet it can have a couple of disadvantages. If all files belong to the same module, I keep them in the same directory. If this leads to directories with so many files, that common file systems may get a problem (e.g. a performance problem), then your module is definitely way too big and this needs to be fixed first.

Sometimes, though, it makes sense to break up a big, complex module into multiple sub-modules. Even if these are not exposed publicly (everything might still be distributed as a single module), each sub-module would get an own directory, which also makes it easy to one day make separate modules out of it. And this shifts your question from "How do you split your files in directories?" to "How do you split your module into sub-modules?" And apparently, you've already found an answer to that later question. Personally I prefer to break up modules by functionality.

As for the naming, if directories group files of modules or sub-modules together, you should name them like you'd name modules or sub-modules.

New contributor
Mecki is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

Yaroslav Kishchenko is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.