So first a little disclaimer, I don't feel how I write files to be better than the next person. This is more of an open forum to discuss how people go about naming theirs and how the manage files as a system grows.
So what exactly do I mean?
So you are working in your company, personal project or whatever it may be and it starts to scale. You get lots of files, loads of components etc.
So in general how do you make sure that you understand what something is? Coming from starting in Angular and reading Clean Code by Robert Martin I am very used to the approach of naming my files according to the thing that it is:
- Component
- Service
- Router
- Util
(communication.service.ts or button.component as an example)
The list goes on. Each has a reason for the name, each has a difference in its responsibility. Just like a function would have its single responsibility.
Now coming into React/Vue most components stick to UpperPascal for their naming and a lot of people just name their files without saying what it is but sometimes what it does. Its just a different approach to file splitting.
So the question comes in how do you go about naming and scaling your code base? What approaches did you take to ensure you don't get overwhelmed by files with hidden meaning behind their names?
Top comments (7)
Usually in our codebases these 'groups' would have their own directory. For a web frontend project it goes something like Component/Template/Lib (includes services, classes)/Routes/Util.
And then the filename would tell you a little more. Classes or components are UpperPascal. Of course if there are enough in the same "family" like TextInput.html, TextArea.html, Radios.html they can have their own directory like 'form'. If it's in somewhere like Lib, it'll probably be called something like
communicationService. If it's just a group of related functions it will probably find itself inutil/time.jsInteresting. So if I understood this correctly as an approach you are taking a feature lets say 'X' that would contain its component/styling and business logic?
Feature X:
featureXComponent.js
featureXService.js
featureXTemplate.html
Would the above be correct understanding?
My bad, probably didn't articulate that too clearly. let's say feature X is some sort of blog functionality, it'll break down something like this
components/blog/Hero.html,components/blog/InfoBox.html,components/blog/Article.html,component/blog/IndexCard.html,components/Footer.html(not in/blogsince it's the same everywhere across the site)Since I am using svelte nowadays, templates are found in
routes/so I'll have something like/routes/blog/index.htmland/routes/blog/[slug].html.in
lib/probably something likelib/communicationService.jswhich is generic.lib/blogService.jsmight have methods.getLatest()or.report(blogId, user, reason)Ah I follow you now! Yea that is a pretty similar approach to how I approach it. Thanks for the insight!
I am used to a module organised with a MVC approach.
Often people use Vue/Model/Controller folders, I much prefer organisation with module-a/module-b/module-c and inside module-a-model, module-a-vue etc. I prefer that because for large project it was awfull to have a huge list of Controller/M/V. Also you often have to work on a specific module so you have everything in one place.
For naming convention I used to do UpperPascal as it suits what most people use for naming Class. But in my company we use only kebab/spinal case mainly because of windows bad case sensitivity. I really got used to it.
For utils we tend to have a different folder.
Last but not least, you can automatise creating new module using some tools like plopjs. It's super easy to use and it gives you consistency.
I see so you take the approach of grouping by module. I have definitely worked with this approach, you tend to get that sort of structure with something like Angular.
I would imagine that you keep similar functionalities at some commons layer?
Also PopJS looks really cool never used it!
I like the {resource_name}.{folder_name}.js approach. Inside app/controllers for example, random-resource.controller.js