In embedded development, especially in programs for microcontroller OS-less systems, one of the most common mistakes is the excessive use of global variables.This phenomenon is often seen among programmers transitioning from early assembly language and beginners, who tend to treat global variables almost like function parameters.They define numerous chaotic structures in .h files, declare a bunch of globally scoped variables that make one’s scalp tingle, and then assign values like 123 in one module, while another module decides what to do based on the value of 123.Whenever I see such code, I can’t help but frown and slam the table in anger.Indeed, I am angry.While I do not deny the importance of global variables, I believe they should be used with extreme caution; their misuse can lead to more severe structural system issues.
Why Should Global Variables be Minimized?They can lead to unnecessary constants being used frequently, especially when these constants are not defined with macros, making the code extremely difficult to read.They can cause unreasonable software layering; global variables act as a shortcut, blurring the boundaries between the “device layer” and the “application layer” for programmers.Lower-level programs may mistakenly focus on higher-level applications.This may indeed be efficient during the early stages of software system construction, with rapid debugging progress, but later on, it often results in a plethora of bugs and patches everywhere.It would not be an exaggeration to say that it feels like a struggle to get through each day.Due to the unreasonable software layering, during later maintenance, even minor modifications or deletions of features often require digging deep from top to bottom, affecting most modules,while the original code comments are often forgotten to be updated.At this point, the system handed over to later maintainers increasingly resembles a “quagmire,” where the only function of comments is to add more confusion above the mire.The extensive use of global variables inevitably leads to some variables lingering between interrupts and the main loop.If not handled properly, system bugs will appear randomly and erratically, revealing the early signs of a terminal illness; without a strong expert to save the day, it is doomed to a slow death.Needless to say, you have successfully created a malformed system,which exists in a mysterious state of stability!You look at this machine, and the machine looks back at you, both silent, with a sense of unease in your hearts.You are unsure when it will crash or when the next complaint will arise.What are the Consequences of Extensive Use of Global Variables?“The veteran” is proud because the system cannot do without him; he knows all the “danger zones” like the back of his hand.When an urgent bug arises, only he can fix it.You cannot only not fire him, but you also have to give him a raise.Newcomers meet their demise quickly,anyone hired to maintain this system, apart from creating more bugs, usually leaves within a month, and they go out to proclaim that the software quality of this company is terrible.As the product undergoes subsequent upgrades, the original creator, who hasn’t touched this system for months, will find that he has forgotten many of the danger zones, leading to increasingly longer maintenance cycles for product upgrades,because modifying one feature will trigger many bugs, andfixing one bug will pop up even more bugs.During this period, even more global variables will be generated.Eventually, one day he tells the boss, “It’s no good, it’s no good, we don’t have enough resources, RAM or flash space is too small, we need to upgrade.”Customer complaints are incessant, after-sales support is on the verge of collapse, and salespeople are afraid to recommend this product,leading to a shrinking market share and a deteriorating company image.
To address this, there are only two principlesMinimize the use of global variables whenever possible; I believe that apart from system state and control parameters, communication handling, and some efficiency-critical modules, most issues can be resolved through reasonable software layering and programming techniques.If it is unavoidable to use them, hide them as deeply as possible.
- If only a certain .c file uses it, make it static to that file, and also include the structure definitions;
- If only one function uses it, make it static to that function;
- If it must be exposed for reading, return it through a function, thus making it read-only;
- If it must be modified, fine, I will open a function interface to allow you to pass parameters for assignment;
- If extern must invade me, I can still strictly control which objects include my .h file, rather than letting it be seen in the public includes.h, causing embarrassment.
Thus, you can understand how deeply I feel about global variables,unfortunately, I have had to rewrite all those cases that the “veterans” handed over to me for maintenance back in the day.
Screenshots from Some Electronic Books
Screenshots from Some Course PPTs
【Complete Set of Hardware Learning Materials】
