question on global versus local usage

[Marc Kaulisch]

Dear Clyde Schechter , in this thread (https://www.statalist.org/forums/for...61#post1701361) you have stated that

"That said, there is no reason to use a global macro here. Local macros area safer programming practice and should always be used in preference to global macros unless it is simply not possible. (I have been using Stata since 1994 on a more or less daily basis and in all that time I have only once encountered the need to use a global macro--it's really very rare.)"

I am also used to use locals and I think the reason is quite obvious. But in recent projects I started to use globals more often. After your quote I think about rethinking my approach.
So at the moment I see two use cases for globals:
1. Setting up paths at start of Stata (a do-file called within profile.do) to be able call the paths in a shorthanded way (and to share do-files)
2. Setting up (graph) options at the beginning of a do-file to be able to test various alternatives or iterations without rerunning locals again and again

Both practices are explained by Worldbanks' DIME. Use case 1 at https://dimewiki.worldbank.org/Stata...ces#File_Paths and use case 2 at https://dimewiki.worldbank.org/Stata..._Visualization

I think these use caes show good and legitimate reasons to use globals, or am I wrong? Given your quote I wonder whether you see alternative, better approaches to use globals in these use cases.

Marc

[Nick Cox]

The case against globals is on at least three distinct if related levels:

1. You almost never need them. There are always other ways to pass information from place to place when needed. My almost is that I do use some of Stata's inbuilt globals. I can't think of when I last used global macros I define on purpose.

2. They may bite you very badly. The whole point about changing a global is that the effects are potentially visible anywhere. It follows that you can be bitten by a change in your code that has effects in a place you wouldn't dream of looking. It does not much matter how unlikely this is. If it bites you, you can waste a lot of time tracking it down. For example, imagine the effects of changing a global macro that Stata's official code may use too. Whether this is innocent or unwitting or done with good intentions won't help you at all if it bites you.

3. They are bad style. In programming, as in security, information should be shared on a need to know basis. There are decades of experience of thousands if not millions of programmers behind this principle.

A meta-principle is that all users are programmers and should take responsibility for their own code. Deciding that @Clyde Schechter's advice on code is less trustworthy than your instincts would be a decision for which you are responsible.

On the specifics in #1

Setting up paths at start of Stata (a do-file called within profile.do) to be able call the paths in a shorthanded way (and to share do-files)

It seems much simpler to me to have each project in its own directory. Projects that cross-refer to files in different places are more likely to go wrong. If I do something like this when playing around I don't call it good practice.

Setting up (graph) options at the beginning of a do-file to be able to test various alternatives or iterations without rerunning locals again and again

I don't understand this one. I often put often used options in local macros, and the whole point is that they are very quickly understood by Stata. There is no need to use globals for this. In any case what is here called "rerunning" is something that Stata does quickly, regardless of whether the macro is local or global.

[daniel klein]

2. They may bite you very badly. The whole point about changing a global is that the effects are potentially visible anywhere. It follows that you can be bitten by a change in your code that has effects in a place you wouldn't dream of looking.

Nick points out how your code might mess with code by others, perhaps even code by StataCorp. I would like to add that it works the way round, too. If your code relies on global macros, any command (or do-file) that you call, official Stata or community-contributed, might change that global macro; your code will fail and you will spend quite some time figuring out why.

[Clyde Schechter]

So at the moment I see two use cases for globals:
1. Setting up paths at start of Stata (a do-file called within profile.do) to be able call the paths in a shorthanded way (and to share do-files)
2. Setting up (graph) options at the beginning of a do-file to be able to test various alternatives or iterations without rerunning locals again and again

There are better alternatives for both of these use cases. All of them can be done as locals defined in a separate do-file. You then use the -include- command to import those local macros to any other do-file that needs to use those paths or graph options. You only define the locals once. But any do-file that needs to use them gets them by just putting a single -include- command in the file.

Do read -help include- to see how this works. I use this approach in nearly all of my projects to define paths or even individual files or lists of files that are used accordingly. I also often place definitions of value labels into the file I -include-, so that the same definitions will apply to all files created in the project.

I would nominate -include- as the single most underrated command in Stata.

[Marc Kaulisch]

Dear Nick, Daniel and Clyde, thank you very much for your answers. I appreciate your advice and reevaluate my coding practices accordingly.

Nick, each of my projects has a distinct folder. Due to possible changes to the paths, I like to change the paths only once. In a former setting I used an ado-program for this. I'll switch to this practice again.
Clyde, using -include- is a very good idea. I try this. In addition it reduces the size of do-files referring to the same locals.

Marc