Mathematica Student Edition
Mathematica Home Edition
Computable Document Format (CDF)
Aerospace Engineering & Defense
Biotechnology & Medicine
Finance, Statistics & Business Analysis
Financial Engineering & Mathematics
Financial Risk Management
Software Engineering & Content Delivery
Authoring & Publishing
Social & Behavioral Sciences
Design, Arts & Entertainment
Game Design, Special Effects & Generative Art
STEM Education Initiative
Community & Technical College Education
Primary & Secondary Education
Computable Document Format (CDF)
High-Performance & Parallel Computing (HPC)
See Also: Technology Guide
Other Ways to Buy
Volume & Site Licensing
Does My Site Have a License?
Wolfram User Portal
About Wolfram Research
Stephen Wolfram's Home Page
Wolfram Functions Site
More Info >>
Mark as an Answer
Avoiding global vars in usage of multiple packages and data
I'm designing an app in MA to solve a fairly complicated problem.
It'll have a large data as input, in the process it'll generate quite a bit of intermediate data, at the end there will be a solution set of data and finally a report will have to be generated.
I've coded most of it already in a single unit and it is quickly becoming unmanageable and extremely hard to debug and maintain.
Because of the complexity and to ease the design I've decided to split it all up in several packages. The problem however is that I'm not sure how to best deal with the global vars. Here's a taste of what I have so far:
inputData3: a large list
inputData4: a large list too
a bunch of small parameters that may or may not be set by the user, like par1->whatever1, par2->whatever2....
I'm thinking of having the following packages:
inputPackages: routines to populate the various input lists from different file formats etc
dataPackage: data handling routines, once the input lists are generated - like add element, remove element, find element etc
dataCrunch: core package to solve the problem, generates solutionList, interList1, interList2.....+others
supportPackage: varous more generic data crunching routines that can live in a separate unit
reportsPackage: routines to generate final user friendly reports from the solution data
plotPackage: routines to generate fancy plots
Now - obviously most of the units will need access to the original input data lists as well as the intermediate lists.
Any ideas on how to organize this in order to minimize the use of global vars?
Can global vars be avoided altogether in this case and if yes - how?
Thanks in advance!
Global variables are one of the first things you learn to reduce when learning good programming practices. They cause a number of problems. They can make debugging harder because any section of the program's behavior may depend on the global value. It is also hard to tell what part of the program might make any use of the variable. Any variable's scope should be confined to the context in which it is used and not be accesible by parts of the program that shouldn't be using it.
Can global variables be avoided altogether? Yes, essentially. There is a programming paradigms called functional programing where global variables can't change value once they are defined. Learning different programming paradigms like this is helpful in learning good coding style.
I am not sure how helpful I can really be in describing the best practices for organizing code here. Learning how to structure code takes a while and requires a fair amount of reading and practice with things like design patterns and reading real world code.
From experience talking to people new to programming with Mathematica and other similar languages, my best advice is to write as much of your code as possible using stateless, pure functions (https://en.wikipedia.org/wiki/Pure_function). That is, to write functions which take input and then produce an output which only depends on that input. These functions should not use any global variable. If they do use a global variable, make that global variable an argument to the function instead. Your program then becomes the process of taking the input and running it through these pure functions to produce the result you want to see.