- **Epistemic status:** #budding When working on software, making data globally accessible is an antipattern, going against [[Modularity]] and the [[Easier to Change (ETC) principle]]. It acts as every method in your application gained an additional parameter because it can be used inside each method. Global data couples your application code, where if the implementation of it changed in the future it could potentially affect all the code in the system. The impact could be limited, but only when you know each location that needs to be changed. Depending on the complexity, it can be a lot of places. This also includes external dependencies that often don't contain unit tests because developers trust the library. When thinking on this problem, ask yourself if you were to change the implementation of the global data, would the change propagate to the system? If that is a yes, the solution to this is wrapping the global data in an [[Application Programming Interface (API)]] that you can control and only including it where it is needed. You can then introduce unit tests confirming the output of each method. By including it where it is needed, the developer can then track where they need to go to make a change. --- ## References - GordonM. “Answer to ‘Why Is Global State so Evil?’” _Software Engineering Stack Exchange_, May 10, 2012. <https://softwareengineering.stackexchange.com/a/148109>. - Thomas, David, and Andrew Hunt. _The Pragmatic Programmer, 20th Anniversary Edition: Journey to Mastery_. Second edition. Boston: Addison-Wesley, 2019.