There is a silver bullet: modularize as much as possible, split by generic/functional criteria first.
For example, in a frontend framework like Angular you split code by "frequency" (is it created once, a few times, or many times?), then by feature (the pages), then by section of the feature (components), then, at last, by technology (a component is a set of SCSS, HTML and TypeScript files).
Never ever split by technology high up in the tree or you'll have completely unrelated files of the same type slammed together for no reason. Ultimately, the best organization tries to keep related files close together.
I'm not entirely sure what you mean by "Never ever split by technology high up in the tree or you'll have completely unrelated files of the same type slammed together for no reason. "
Like don't put JavaScript tech beside JSON files, or something more like don't put database migrations by the JavaScript or something?
I mean organizing files with the same file type together only because of said common file type is not usually great unless they're related. For example, you put all assets in some /assets folder hence all .jpg are grouped together but they are only because they "make sense" together and they happen to be of the same type. Imagine grouping all css together of different frontend components in the same /style folder: that is an example of bad grouping.
But, in an MVC approach maybe it's a good thing that a /style folder exists in the View part with all the style files, because they make sense together in that case.
Grouping is all about keeping related files close and using functional criteria as much as possible.
A good question you can ask yourself is "are these two files/folders part of the same functionality?"
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There is a silver bullet: modularize as much as possible, split by generic/functional criteria first.
For example, in a frontend framework like Angular you split code by "frequency" (is it created once, a few times, or many times?), then by feature (the pages), then by section of the feature (components), then, at last, by technology (a component is a set of SCSS, HTML and TypeScript files).
Never ever split by technology high up in the tree or you'll have completely unrelated files of the same type slammed together for no reason. Ultimately, the best organization tries to keep related files close together.
I'm not entirely sure what you mean by "Never ever split by technology high up in the tree or you'll have completely unrelated files of the same type slammed together for no reason. "
Like don't put JavaScript tech beside JSON files, or something more like don't put database migrations by the JavaScript or something?
I mean organizing files with the same file type together only because of said common file type is not usually great unless they're related. For example, you put all assets in some /assets folder hence all .jpg are grouped together but they are only because they "make sense" together and they happen to be of the same type. Imagine grouping all css together of different frontend components in the same /style folder: that is an example of bad grouping.
But, in an MVC approach maybe it's a good thing that a /style folder exists in the View part with all the style files, because they make sense together in that case.
Grouping is all about keeping related files close and using functional criteria as much as possible.
A good question you can ask yourself is "are these two files/folders part of the same functionality?"