I'm just a beginner in the programming world, and I'm not sure what's better in a mid/large program, a global variable that is accessible to all subs/functions, or local variables inside subs/functions where needed.
For example the NX session, UFsession, or a variable that is used/needed in multiple parts of the program.
If the variable is global, you have the variable in memory all the time, even if you are not using it on some parts of the program.
If the variable is local, you create/reference the object/variable, use it and, at the end of the sub/function, destroy it .
I wonder if there are best practices about this, or what other users do and why?
Is there any difference in performance/efficiency?
Any thoughts will be appreciated
Generally, professional programmers frown on the use of global variables. This is because they damage function "encapsulation" -- they make it difficult to understand exactly what inputs and outputs each function has, because they by-pass the function's argument list.
But, from a logical point of view, the current NX session is a "global variable" and it makes perfect sense (to me) to represent it as such in a program. In fact, in SNAP there is a whole collection of global variables in the Snap.Globals class, including things like the work part, unit type, tolerances, etc. The NX session logically belongs in this collection, too.
If you repeatedly call NX/Open functions to read these variables, there is a tiny performance degradation. But it's so tiny that it's not worth worrying about.Improving the clarity of your programs is the real point of the global variables, not the performance gain.
So, for things like the NX session (and a few other things) I would recommend using global variables. But, use them sparingly.
Yamada said it well. While there can sometimes be (extremely small) performance differences, the main reason programmers prefer locals is style, not performance. But style is very important! Style keeps your code from becoming so tangled it is impossible to work with.
The history of programming languages is a history of progressively tighter *restrictions*. In the early days, there were no restrictions, and it eventually led to a crisis:
Nowadays, programmers are trained to aggressively restrict the scope of every part of their code -- to break it up into small modules that each do only one thing, and that each are only able to affect the one piece of information they own. The fewer things a piece of code is able to do, the more things you can assume it doesn't do -- which helps immensely. Minimizing complexity is much much more a part of programming today than maximizing performance.
Cost varies linearly with performance (just buy more/faster processors, etc). Cost varies *exponentially* with complexity (cost to pay people to maintain and extend code that is a tangled mess, the cost of overlooking bugs and having to fix them after you've already delivered your product, etc). In almost every program, performance is "bottlenecked" by one or two areas in code, and *only there* is it worth spending the time to work on performance. 90% of the time is spent executing 10% of the code. First write the code to be simple. Then run a profiler upon it to find out where the bottlenecks are. Then optimize only those places for performance (because code optimization increases complexity).
In the above discussion, I am ignoring the topic of choice of algorithm -- which, of course has a huge effect on cost. But if you are talking about global vs local variables, you are talking about "code optimization", not "algorithm optimization".
My style: keep variables local is best. Global variables should be used sparingly. Declare locals inside the block closest to where they are used.
Premature optimization is the root of all evil -- DonaldKnuth
I didn't say it, Donald did...
As for global variable, just not avoid them, forbid them. As for your kids renting their first appartment, you will not listen to our advices. But eventually, you will learn it the hard way and conclude this was the best course of action.
Even the Work part global variable is evil in some sense since it prevents many functionalities of NX to work correctly if the work part is not set prior to run some functions. And there is no way of knowing that except trial and error... Evil as it is.