I'm starting to work on increasingly larger projects and I'm realizing my code is turning into a mess. I've tried following various tutorials but each one suggests a different structure. Is there a standard practice that companies use too, or does it really depend on the project?
Don't make the mistake of thinking there's a universal structure that works for everything. Even in companies, the approach changes depending on whether they're building a monolithic app, a microservices system, or a library. What you can do is learn the common principles and then adapt them to your specific project, instead of chasing whatever's trending in tutorials.
The foundation that works almost always is dividing code by responsibility: UI components/logic separated from business logic, API calls isolated in dedicated services, utilities in separate folders, tests alongside the code they test. If you're using a framework like React or Vue, leverage its natural structure and add organization on top of it for config files, constants, helpers. If it's vanilla JavaScript, you could think about a layered architecture (presentation, logic, data access) or self-contained modules with specific purposes.
What really matters is that your team (or you six months from now) can navigate the project without losing your mind. If you open a folder and immediately understand what's in there, if file names tell you what they do, if you can find where to modify a feature without digging everywhere, then the structure is working. Start simple, expand as the project grows, and don't be afraid to refactor folders if things start getting messy.
You're right about this: there really isn't a universal standard - it depends on the project, the team, the requirements. What does always work, though, is starting with a clear separation between business logic, state management, and presentation - if you use a framework like React or Vue it already guides you, otherwise you need to be more disciplined. One practical trick that helps: before you write code, map out on paper (or in a text file) which files and folders you actually need for your specific case, and write down some simple rules for your team about what goes where (a kind of personal convention). That way you avoid ending up with utility functions scattered all over the place or files with 2000 lines, because at least you have a clear criterion when you need to decide where to put a new function.
Log into answer.
