Clean and organized working environments!
This is a great question to ask, especially considering a majority of people who experience issues with their game have a very messy working environment, and don't bother asking how to fix it. Here are a few ways you can keep your game (and code) organized, and clean...
Names
A lot of people find giving specific names to certain objects, tasks, variables, etc, very annoying and tedious, and therefore opt for something shorter quicker. This however, is something you should give a considerable amount of thought to when necessary. Not only will good descriptive names help you remember where or what something is, or how it functions, but it keeps your code (or working environment) a lot more human readable (and subsequently, easier to navigate and debug!). Would you rather your dragon model be named something like aabbcc, or TheMightyDragon?
Location
You should have a place for everything, and everything should be in it's place. Have a lot of remotes in your game? Create a folder and name it Remotes. Have a ton of module scripts that both the client and server should have access to? Create a modules folder and throw it in ReplicatedStorage. Everything should be a hierarchical system that contains something relevant to it's category. If you have a bunch of treasure chests in your game, create a folder for treasure chests and throw them all in there. Both you, and your script will find it a lot easier to look through.
Use the right service
This kind of fits with location, but using the correct service isn't just for making your working environment cleaner, it's also highly practical. For example, if you have a set of objects that you don't want replicating to the client right away, you can store them in ServerStorage, where all contents are stored completely server-sided until parented somewhere else by the server. If you do want them to replicate, throw them in ReplicatedStorage. Don't go and use something random like Lighting to hold everything. If you want to create an introduction system, try using ReplicatedFirst with a local script instead of cloning something to a PlayerGui when the player joins, etc etc etc... Point is, storage services exist for a purpose, and you should know what their purpose is!
Don't duplicate scripts
Before you just read this title and decide to only use one script for everything, hold on. Having multiple scripts for handling different tasks is not a bad thing. I'd in fact, encourage it. However, if your game is creating a hundred different scripts for a hundred different parts, perhaps then you should consider a better method. Most of the time, I'd suggest keeping it at one script to manage everything, and having a bunch of modules that script can require to organize each task it carries out. If you feel like it's necessary to have more than one script manage one end of your system, go ahead! It is not deemed inefficient, and you shouldn't be hesitant to split up your code into subsections for different tasks. Just make sure it's absolutely necessary.
Anyway, that's my opinion on keeping your code and working environment clean and organized. Others may have different opinions, and that's fine too. As long as what you deem "organized" isn't beyond practical, and it helps you understand something better, you should implement it. If you have any questions, just let me know.
1 comment
One thing to note is that you don't always have to reference something with script.Parent. If you can get the path to it, you can access it. For example: workspace.Model1.Folder.Part. You can also loop through the children of an instance and do something to every one.