How to split the code?

Question

JavaScript

I am writing a library in native es6 without dependencies, I need to somehow divide the code into logical "modules".
There are several functions that work with the hash, there are several functions that work with events, scatter them around the house. The problem is the stringing of such code. Now 200 lines of code have been written, and you are already starting to get confused in it, since the functions are mixed up, and not in the order of execution, and it’s not realistic to put them in order, since some functions are independent of each other.
For example, the functions responsible for hashing and scattering events around the house are independent of each other. But in the end they refer to the same function.
Tell me how such code will be structured more correctly. The problem is that if you take it out, it's all in separate files, you will have to connect quite a lot.
I thought it was to be packaged in some big functions, with functions nested inside, in which there will already be executable code.
And another question. I believe that arguments and all variables should be prefixed with some kind of prefix to make it easier to understand where the data comes from.
My variable or argument can come from another function inside the library, be passed by the programmer, or, it was generally taken from the user, for example hash. Inside the library, this needs to be somehow divided in order to understand where in the function this data came from.
People who wrote their own libraries, or something similar, experienced programmers, tell me how best to write so that the code does not turn into shit that even you yourself are not able to read!?

Answer 1

Now 200 lines of code have been written, and you are already starting to get confused in it, since the functions are mixed up, and not in the order of execution, and it’s not realistic to put them in order, since some functions are independent of each other.

And it doesn't have to be in order.
Group by meaning, by functionality. And give a clear name, say, all handlers start with On.
I believe that arguments and all variables should be prefixed with some kind of prefix to make it easier to understand where the data comes from.
It is enough to name arguments identical in meaning everywhere the same way. But only at one level of abstraction. Trying to use a through name is absolutely not necessary.
Well, local variables can be distinguished, for example, with the l prefix.
It is absolutely not necessary to trace the entire chain from where the data comes from.
It is not necessary to see in what order the categorical functions are executed.
This is a typical beginner's mistake - trying to keep everything in your head.
For the programmer, the norm is "divide and conquer" - abstraction at each level from the previous level.
The most important (well, or one of the most important) skills of a programmer is decomposition.
In general, read a series of articles by Uncle Bo "Clean Architecture" and its adaptation to your programming language (there are several adaptations of articles for different programming languages).

Answer 2

There is no problem in dividing into files and directories and including these files. If it bothers you - you need a normal editor / IDE with navigation and learn how to use it. There are many ways to structure the code - decompose into files, the easiest. You can also do everything in the spirit of OOP if it makes sense.
For users of your library, there is no difference how it is arranged inside as long as everything works, the API that you provide is important to them, so you need to think it through well. No one is interested in what prefixes the variables have there, and no one except you will remember which prefix what it means either.
If you want to better structure everything very clearly and understand what it came from and what it is, you can take Typescript.

Answer 3

Objects and classes (clauses 6-7)