When I code a large, complex system and continue it the next day, I forget everything and it all seems overwhelming.
Because of this, I constantly restart and try to do everything in one sitting. I’ve just now noticed that this has been happening for quite some time.
For those of you who have experienced and overcame the same thing, how did you do it? Or rather, how do you keep track of everything in a large system as you work on it?
Comments.
You should be commenting your code, especially if it’s large. It’ll help you keep track of what everything does.
I’ve felt something similar before — not constantly, but every now and then I do come back to a project and feel a bit disconnected from what I was doing. It’s not severe, but enough to slow me down if I’m not careful. What helped me was building a small organization system around my code so I don’t have to rely purely on memory.
I usually break the project into smaller, focused modules, each with a clear purpose. I also give both my local and public functions descriptive names so it’s easy to understand what each one does at a glance. That alone makes it much easier to regain context when I return to the project.
Something else that helps me a lot is leaving short notes about what I’m working on or what I plan to do next. I put them as block comments at the very top of the module — kind of like a quick “state of the project” snapshot. They’re simple, but they save me from that “wait… what was I doing?” moment when I open the file again.
I already have my own way of organizing my code, but I recently found a post that might be really helpful for you too: Rules That I Follow for My Luau Programming.
Always write your code as if someone else is going to read it. Problem solved.
You from the past isn’t you from the now and you from the now isn’t you from the future.
How big are we talking? Like in lines of code
Ensure you are always following the single responsibility principle. Compose large functions out of smaller targeted functions. Keep your scripts focused on what they need to do, and code for an interface if other stuff needs its functionality. Ideally all code is a set and eventually forget pattern. But when you do have to go in to make changes, you should be able to tell where those changes need to be pretty easily just from good file names and good function names. Comments help too, but well named stuff removes the need for most comments. But when you follow the single responsibility principal and compose your larger functions out of smaller ones you should only have to care about what the part you are editing is doing. Also decoupling which is basically trying to minimize the dependencies external systems have on your system. Things should manage themselves and then you should tie them together with a logic handler above it.
tldr; break it into pieces with clear roles. And decouple your code if you can.
I’ll use comments to mark down where I left off and comment on lines where there are bugs or like if I’m going to add another feature or something I’ll comment it on that specific line. What helped me a lot though was spacing my code out more, and I don’t mean like putting new lines or space in-between your code (although you should definitely do this if you aren’t already) I mean like making different scripts for different features in your game. Don’t put all your code for your entire game in a single script, make multiple different scripts for different features of your game. Like for example if you have scripts for Gui and scripts for player camera put them in separate scripts, don’t put them all in the same script it will just be more confusing. I’m sorry if this is long (⩾﹏⩽)
I made a script that allows you to write a todo list, in which it prints in the output for you to see.
Clean code writing practices and code organization will mitigate this issue. Always write code as if someone else without context needs to understand your code. @NyrionDev makes a very good point
I have a discord server with just me in it, and a channel called #ideas.
I just jot down any random thoughts I have, and be sorta descriptive to where in the code those thoughts apply. Really helps me get back into a rhythm.
Here’s a saying I keep with me ever since I first heard of it:
You are never coding solo. You are always in a team, even when you’re alone.
You are coding with your past, present, and future self. So even if you are the project’s sole developer, you must always provide documentation to help your future self understand it.
To summarize the past replies…
Comments are great to use, but a clean code structure needs minimal comments to be understandable. Make use of good naming conventions for your scripts and functions.
Single Responsibility Principle - Simply put, make your scripts, modules, and functions have as little purpose as possible. Don’t make a resizeAndRotate(part) function, make resize(part) and rotate(part) functions instead.
Adding in TODOs will definitely help you in keeping track of what you need, well, to do. Studio even underlines the comment if you prefix it with -- TODO.
Like everyone says, this issue is largely because you lack code comments or they aren’t clear enough.
Here are some tips for commenting your code:
documenting your code is very important and is very much the solution for your problem, but also ensuring your code is written in a manner that its easy to read and understand i.e. the code explains itself
in regards to writing actual comments in code, only do it where its needed, like a complicated chunk of code which you should look into refactoring so its more readable and self-explaining. and its better to explain the why of the code, rather than what it does
I’d say 700+, split into many modules and (potentially) across server/client. To give you a better understanding, Here’s the codebase that prompted me to make this post:
PLEASE make self.object.TextArea.InputBox its own variable for the function on like 192 
I’m already reworking the system, and it should indeed be a variable of its own. Thanks for the suggestion!
No worries :D
function SidebarChatFrame:rename()
local selfObjectTextAreaInputBox = self.object.TextArea.InputBox -- needs a better name
selfObjectTextAreaInputBox.Interactable = true
selfObjectTextAreaInputBox:CaptureFocus()
self.maid:GiveTask(selfObjectTextAreaInputBox.FocusLost:Connect(function()
selfObjectTextAreaInputBox.Interactable = false
local newName:string = selfObjectTextAreaInputBox.Text
--Packets.RenameChat: Fire(self.chatName, newName)
end))
end
yeah you can do a better variable naming btw local inputBox, textArea, etc…
That is good to know, that does seems like clean code, well classic OOP I guess
I personally try to keep things simple. I’ve got a loose way of making my scripts, in a modularized fashion where logic naturally breaks down into independent systems, stuff like that?
700 lines is a lot but not too much, split into modules is nice, but sometimes it’s nicer to have bigger scripts. If, to script a particular feature, you are split between 2 modules (instead of making 1 module, then the other that depends on the first, and perhaps go back to the first to add missing features), then I’d say you’ve separated it too much.
That also applies to functions. I don’t know how you make your functions but, if you keep all your functions small and concise, I would perhaps suggest you try to keep big functions, if the logic inside works best as 1 big block rather than segmented chunks. Too many small functions, are you can’t read the whole logic without moving everywhere in the file
I also like to package my code with an OOP like structure, without metatables. I’ve talked about it here
Organization is needed for remembering your code.
Comments are helpful for other people and sometimes yourself, but you shouldn’t need a guide just to read your own scripts that you wrote.
One of the issues a lot of scripters have is deeply nesting their code. Deeply nested code is very hard to read since you have to remember stuff from all the previous indents.
When I started avoiding that I noticed that I was remembering things a lot better and my code started to get scalable.
Just find a system that works for you and stick with it forever.