Local Vs. Global

[Joshua Tobias]

Hi everyone! I'm a grad student with a few years of experience with Stata. In all my courses that use Stata, I never really understood the difference between a local and global macro. From the limited knowledge I do know, local stores string or numerical values that can be later used to have a very clean do-file. And from what I understand, global does the same thing, but applies to the whole program instead of specific instances within the do file.

This is how I imagine it would be in a do-file:

global proj regress1
- - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
local desc age educ female publications
regress citation `desc', vsquish
- - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
export $proj-01.do
log close


Any clarification would be great!

[Joro Kolev]

They save the same thing, but they are differently accessible. The global as the name says is globally available and the local is available only in the "Stata session".

I pretty much never use globals.

[Wouter Wakker]

This blog post explains the difference well in my opinion.

The Stata User Guide section 18.3 is also useful.

[Clyde Schechter]

I'll go a step farther than this. Because global macros are globally available, they are dangerous and should be used only when there is no alternative. Your program may call other programs, including some that you aren't even aware of the existence of. Any of those programs can change the value of your global macro, without warning, and then when you try to use the global later you get a nasty surprise. Now, most programmers who use global macros are pretty careful to give them names that you aren't likely to choose for your own global macro--but there is no guarantee of that. You can probably use them for a long time before this ever bites you. But I can tell you from painful experience, that if you ever do get bitten by this, the resulting bug will be so difficult to find and fix that you will swear to never use a global macro again as long as you live.

Almost everything that you see done with global macros can actually be done with local macros. They are completely safe because they only exist ("have scope") within the do-file, or highlighted piece of do-file where they are defined, and not in any programs that call or are called within your file. While this can occasionally be a nuisance because in order to make their information available to programs you call, you have to actually make them arguments of the program or pass them through options. It can be a nuisance if you want to define a local macro at the top of a file and then you want to run some code at the bottom of the file that uses it and you don't want to run all the code in between (though in recent versions of study this is easily done by commenting out the intervening code with a single keystroke). But in a lifetime of programming, those inconveniences will not cost you nearly as much time and trouble as once having your global macro stomped on by some program you didn't even know was there.

So my advice, based on hard experience (not in Stata, but with things analogous to global macros in other programming languages) is to never use a global macro unless you are more than 100% certain that neither a local macro nor anything else will do. Avoid global macros like the plague. For what it's worth, in the not quite 26 years that I have been using Stata, I have only had to resort to a global macro on one occasion. So it's pretty rare that you really need them.

[Joshua Tobias]

They save the same thing, but they are differently accessible. The global as the name says is globally available and the local is available only in the "Stata session".

I pretty much never use globals.

Thank you for the link! I had to re-read for it to make sense.

[Joshua Tobias]

So my advice, based on hard experience (not in Stata, but with things analogous to global macros in other programming languages) is to never use a global macro unless you are more than 100% certain that neither a local macro nor anything else will do. Avoid global macros like the plague. For what it's worth, in the not quite 26 years that I have been using Stata, I have only had to resort to a global macro on one occasion. So it's pretty rare that you really need them.

It seems global macros aren't utilized unless you really need to. I've been told by many that they're similar, and useful. However, after reading that post on them, I really shouldn't use it if I don't need to. Thank you!

[Nick Cox]

Not quite the question but not understanding that local means what it says is a frequent source of puzzlement. For yet another write up see

SJ-20-2 dm0102 . . . . . . . . . Stata tip 138: Local macros have local scope
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N. J. Cox
Q2/20 SJ 20(2):499--503 (no commands)
focuses on a common misunderstanding of how local macros work

[bibha dhungel]

I am trying to use "i." with a global macro but it does not work as intended.

webuse lifeexp, clear
generate lexp_cat = (lexp < 70)
encode country, generate(country1)
generate country_cat = 0 if country1 < 25
replace country_cat = 1 if country1 >=25 & country1 < 50
replace country_cat = 2 if country1 >=50 & country1 < 75
global delVar = "region country_cat"
logistic lexp_cat i.$delVar

With the logistic regression, I expect to see the analysis for the region and country_cat as categorical variables. But 'i.' worked only for the first variable i.e region while country_cat was treated as continuous. Can anyone please help?

[Nick Cox]

logistic lexp_cat i.$delVar

expands to

logistic lexp_cat i.region country_cat

as the space is respected. The best way here, and more widely, to use a global macro is not to use it at all. That is, write directly

logistic lexp_cat i.region i.country_cat

If your global contained not 2 but say 20 variable names, there would be better ways to approach this.

[Bjarte Aagnes]

Also, see

help include

to share common definitions (locals) among several do-files.

[Joro Kolev]

If you insist on using a global, try

logistic lexp_cat i.($delVar)

[James Voss]

I was thinking about using global, but am 99% certain I should not.

What would you recommend one should use to have a macro work across multiple sub-do files within an uber-do file (a uber-do file that is essentially a list of other do files)?

This is my first time writing an uber-do file, and I'd like to get this correctly the first time.

Most of the sub-do files start with the same two locals, and the locals in all the files are always going to reference the same two years.
Currently, those years are: 2025 and 2019.

local CurrentYear = 2025

local FarthestBackYear = 2019

To change the CurrentYear and the FarthestBackYear, e.g. to 2030 and 2016, I need to edit the two locals within each individual sub-do file.
for example:

local CurrentYear = 2030

local FarthestBackYear = 2016

I'd like to be able to set the CurrentYear and the FarthestBackYear at the beginning of the uber-do file, and then not have to edit the sub-do files.

Since global is to be avoided (per the general lesson taught in this thread), what else would you suggest?

Thank you!

[Clyde Schechter]

I would create a separate "sub-do" file, maybe calling it years.do. It's sole content would be:

local CurrentYear = 2030
local FarthestBackYear = 2016

Then in the "uber-do" file and all of the other "sub-do" files, I would remove the definitions of those local macros, replacing them with

include years.do

Yes, you will have to edit all of the sub-do files once to make this change. But with that done, any time you want to redefine those local macros, you just need to edit years.do and the change will automatically propagate to all the rest.

Do read -help include- to understand how it works. It is, in my view, one of the most underrated and underused commands in all of Stata. And it is the perfect solution to precisely this kind of problem where we need to harmonize the definition of local macros across many files.

[James Voss]

Thanks Clyde Schechter!

- include - works like a charm, is very cool as the equivalent of - do - command but without the dropping of the local macros after the code runs, and is going to make the use of uber-do files so much more efficient.

I wonder why this is considered for "advanced" programming. I wish it had been in the STATA course that included a discussion of macros. They focused on - local - vs - global -.
Now, I feel like - include - is far more useful to know than - global -.

Thanks, again, very much.