Proposal: namespaces for global variables

[paulromano]

I've found it really useful to have global variables be members of a namespace below openmc::. For example, when moving all settings-related variables to C++, I put them in a openmc::settings:: namespace. The big benefit is that when they are used around the code, it's a lot more obvious what is a global variable and what is not because the global variables have a namespace prefix. In fact, with our existing rules, it makes everything unambiguous:

• Local variables: nothing_special
• Class data members: use_trailing_underscore_
• Global variables: somens::global_var

@openmc-dev/committers What do others think about adopting this as a formal rule going forward?

[nelsonag]

Good idea.

To be clear, it doesn't seem that you are proposing simply a global:: namespace, but a few namespaces with informative names (just like settings::), is that right? (I also agree with that)

If so, it would be good to agree on what those namespaces should be early on instead of adding them in later to avoid re-work.

Here are my suggestions for the global categories, with explanation if needed:

1. settings
2. tallies
3. data (I intend for this to be material and nuclidic properties, open to other naming options since data, while short, is vague)
4. geometry (I would prefer shorter, maybe geom?)

[paulromano]

Exactly, having a few categories would help keep things straight. I was thinking:

• settings (already exists)
• simulation (already exists) -- place for holding things that are only used during a simulation like the fission bank, k-effective, etc. This is a little long so we might want to consider just sim?
• model -- this would have geometry and materials (and maybe tallies?)
• data -- cross sections and other fundamental nuclear/atomic data

[smharper]

"Namespaces are one honking great idea -- let's do more of those!"

I agree that the settings namespace is very helpful. I fully endorse putting all of our global variables in one namespace or another.

[paulromano]

FYI, I have a branch where I've taken care of this that I'm planning on putting a PR in for after #1118 is merged.

[paulromano]

Adopted with the merging of #1120