GAMS has no encapsulation. That is, all symbols, except for $setLocal, have global scope. This creates challenges when the code grows. I work with a model that has been developed during decades by a many contributors. A lot of the code consists of data preparation and reporting in various “modules”. For each new such module, the modeller possibly introduces new symbols - which become instantaneously available in all other modules downstream in the code. The risk of changing a symbol in one module in such a way that another module breaks increases when the number of symbols floating around in the memory amounts to hundreds or even thousands, many of which have similar yet distinct uses and meanings.
One way to make the code more structured and truly modular would be by code encapsulation, so that the scope of a symbol is limited to a certain unit of code. That is not currently possible in GAMS - or is it? But are there perhaps workarounds or other good practice in this respect? I could imagine working with something like “namespaces”, where the user would give the symbols prefixes separated by some character, like the dot “.”. For instance, one could declare
parameter module1.price(d1,d2) “Price used in module 1”;
to signal the scope to the developer. Clever editors or scripts could ensure that some modularization rules are not violated, i.e. the symbols are not used outside of their intended “scope”. This particular example doesn’t work because the dot is not permitted in this way. It would also look a bit odd with variables, where there can be suffixes that are also separated with a dot. But perhaps you have some other trick that works to the same effect that you would like to share?
A related topic would be the possibility of unit testing, but that merits its own topic. Please hint in a comment if a thread for unit testing in GAMS already exists here (I found none).