Open jngrad opened 5 years ago
The one you mention is also a linking hazard. In general most should also be static.
Other example: there is a global variable energy
:
https://github.com/espressomd/espresso/blob/182020aa5d0c09c4283b3b55db7439038e98a7a2/src/core/energy.hpp#L38
which can easily be shadowed in functions calculating energies, forcing the use of alternative variable names, like _energy
, eng
, ret
.
Removing globals is also an option: e416e7e528bf3da75, d47a73138a, 34b8821dd3f682, fab58ca37ae, 6b56534
Progress report:
local_cells
have been removed (#2899) and the last occurrences are now being accessed through a function (#3501)Progress report:
int fluidstep
and double fluidstep
into a single global: 37e7e4c7a61cbbcf15b96d91444ebdb531544853
Global variables make code difficult to read and maintain. Tracking their origin is an annoyance, and name collision with local variables is always a risk. Should we consider prefixing global variables with
g_
, just like we prefix class member variables withm_
and enum values with their enum name? Or enclosing them in namespaces, like enum values from enum classes?Here is one special example, hiding in the global scope of some LB code: https://github.com/espressomd/espresso/blob/b25c0148bde7908af926e6360198ac7532c6688a/src/core/grid_based_algorithms/lbgpu.cpp#L115
Documentation is also affected by this situation, because Doxygen doesn't have a reliable scope resolution mechanism (Doxygen incorrectly states this variable is referenced by 380 functions).