In 4D "Process" and "Interprocess" variables are generally considered to be in the class of "Global Variables" and many programming style guides consider "Global Variables Are Evil." This is a pretty strong statement, especially for something that is so prevalent in older deployed software. But, if you can build your system without using global variables, you’ll be a lot better off.

As with all Heuristic Rules, or Rules of Thumb, this is not a rule that applies 100% of the time. Code is generally clearer and easier to maintain when it does not use globals, but there are exceptions.

Global variables (called globals for short) can be accessed from any part of a software system, and have a globally visible scope. In its plainest form, a global variable is accessed directly by name rather than being passed as a parameter. By way of contrast, non-global variables (called locals for short) can only be seen within a particular methods.

Why Global Variables Should Be Avoided When Unnecessary

• Non-locality -- Source code is easiest to understand when the scope of its individual elements are limited. Global variables can be read or modified by any part of the program, making it difficult to remember or reason about every possible use.


• No Access Control or Constraint Checking -- A global variable can be get or set by any part of the program, and any rules regarding its use can be easily broken or forgotten. (In other words, get/set accessors are generally preferable over direct data access, and this is even more so for global data.).


• Implicit coupling -- A program with many global variables often has tight couplings between some of those variables, and couplings between variables and functions. Grouping coupled items into cohesive units usually leads to better programs.


• Namespace pollution -- Global names are available everywhere.


• Memory allocation issues -- Some environments have memory allocation schemes that make allocation of globals tricky.


• Testing and Confinement - source that utilizes globals is somewhat more difficult to test because one cannot readily set up a 'clean' environment between runs. More generally, source that utilizes global services of any sort (e.g. reading and writing files or databases) that aren't explicitly provided to that source is difficult to test for the same reason.

Why the Convenience of Global Variables Sometimes Outweighs the Potential Problems

• Form object varialbes and variables used within 4D HTML tags are process variables by nature.


• Variables shared between processes, such as flags, are interprocess variables by nature.


• When global variables represent facilities that truly are available throughout the program, their use simplifies the code.

Really Bad Reasons to Use Global Variables

• "What's a 'local variable'?"


• "I'm a slow typist. Globals save me keystrokes."


• "I don't want to pass it around all the time."

4D makes it really easy to make global and local variables visibly distinctive and easy to select when writing 4D methods. The tool that makes this easy is 4D Preferences for Methods.




One "Rule of Thumb" that helps limit process and interprocess (global) variables in 4D code is to make the code as "cold" as possible. By setting the colors for process and interprocess variable to a "warm" color (red family) and local variables and methods to a "cold" color (blue family), then write code so that cold colors dominate the code.

Example of a "Cold" coded method