3 ms·
As an embedded engineer I’ve never heard of this and it seems… unwise. Yes, we avoid dynamic memory allocation but using globals for everything? Assuming C:
by thebruce87m 3y ago
As an embedded engineer I’ve never heard of this and it seems… unwise.
Yes, we avoid dynamic memory allocation but using globals for everything?
Assuming C:
For inter-file access static variables with getters/setters achieves the same thing and makes it easier to split/test
I’ve never went as far as not using local variables in functions but you could use static here too to avoid the possibility of two functions sharing the same variable.
- GuB-42 3y agoWe still had local variables, for internal calculations and the likes of course, but most of the interface was done through globals. (btw, it was indeed C) Perhaps what is missing is that the way we did testing was a bit unconventional. That is, we didn't have unit tests. Instead, we did it all through integration testing on the real hardware. And setting these globals was how we got coverage. We also had a particularly good traceability, so we knew exactly which tests to run after each code change and get our coverage back, which made up for the fact that we couldn't tests the functions independently. It was a rather successful project, we got audited a couple of times with only minor issues. It certainly made testing more difficult, but we in exchange, it was much closer to real life conditions. Note that it was a while ago, newer project use a more modern approach with a continuous integration platform, unit tests with an emulator, etc... We also use less C, instead using industry specific tools and certified code generators, multitasking RTOSes, etc... With C and ADA for the inner and legacy parts.