Hi Chris,

Nice article on the naming convention! As you know it is very close to the convention we use at CQM. 

One additional thing in our naming convention that I like to share, is that we prefix identifiers that are locally defined differently by adding an 'l’ for local. So, a parameter locally defined within a procedure becomes ‘lp_..’ contrary to 'p_...’ for global. We encourage the usage of local parameters and procedure arguments to get better maintainable code, and a specific naming style helps in that respect.

Regards,
Jacob Jan Paulus

I'm curious hear more on AIMMS' vision on the broad subject of code style and organisation. Naming convention is just a part of the style.

Within AIMMS the developers have extreme flexibility on how to structure code and workflows, which becomes a pitfall for larger projects when there is no guidance on the style and structure. Flexible use can quickly create chaos.

I know this is a really big question: Can you give guidance / best practices on how to structure code?

Just some of the questions from the top of my head:

• How to best organisation of sections / declarations?
• When to use a module vs a library?
• How to setup use cases and workflows (in combination with WebUI)?
• When (or should) there be a model, view, controller design pattern? 
• ...

Great addition, Paulus. We use some prefixes for parameters that are arguments from a procedure/function. E.g. p_”arg”_name.

We also use other prefixes to easily identify if a identifier is related to interface only (p_”gui”_), or if it’s just a pre-calculation for the optimization model (p_”exe”), or if it’s just direct result from the model variables (p_”exs”_), and so on.