S
Stratadox
Guest
This is all very relative... Personally I HATE seeing various code actions in a single event, and find it incredibly difficult to work with projects like that. Far better to use one code action and then set SCRIPTS to be the sections (imho). You can see in the action each script that is called all in one place and then MMB on each script to open it and edit it. Now, you may think this is a horrible way to do things, but that's why I say it's all very relative...
The advantage of multiple (named) script blocks is that the event window provides a clear overview of the high-level commands, while hiding the implementation details in a separate yet accessible window.Yeah I thought about using scripts to replace code actions, but it's not that its horrible, rather utterly lazy and innefficient, becuase looks like I'm forced now to make lots of scripts which I'll use only once, each one with it's own name for something otherwise could have been just the "Initialize" code block for instance variables in each object. or the block which stores string arrays for language. or the collision code exclusive for an individual object, perfectly identified. So you HATED it, kudos. But it was considered a best practice by many, and people who HATED it had the options not to use it. Now the rest of us don0t.
I'm sorry, but that's not even a proper solution to help users keep long chunks of code organized. Great.
A strong disadvantage is that the implementation is tightly coupled to the executing object and more specifically to that one event.
This decreases re-usability, which often leads to code duplication and therefore to a code base that becomes exponentially harder to maintain.
Prominent advantages of using scripts are that they promote code reuse, that they can be used to separate implementation details from the intentions of the object.
A huge disadvantage is the pollution of the global namespace, which promotes informal naming conventions and/or name collisions.
I'd argue that the inability to rely on abstractions (due to GM's lack of interfaces) forces the project into a tightly coupled state, whichever of these methods are used.
That would be a blatant violation of the single responsibility principle.Well, if that's the problem, how about using annotations or blanks to clear it? like,
(a wall of codes about doing thing A)
//that code is for A
(another wall of codes, this does thing B)
//that code above is for B
like this. you can you use Ctrl+F to find out what code you're looking for. the blank line is for dividing A and B more clearly.
Initialising local variables (i.e. the properties of an object) is something I would (indeed) keep as close to the object itself as humanly possible.looks like I'm forced now to make lots of scripts which I'll use only once, each one with it's own name for something otherwise could have been just the "Initialize" code block for instance variables in each object
Implementing all other logic, however, is not something the object in question* should be bothered with.
The better way is to encapsulate the logic as much as possible into highly cohesive modules (independent packages), and to keep these as replaceable as you can.
*This goes for GM-objects more than for those of other languages, as GM-objects are almost always models.