> Toyota engineers cramped tens of thousands of lines in a single file and the lines freely update hundreds of global variables.
While the "single file" part is not great, using all global variables in an embedded system can be a good thing. I've worked on a critical piece of software for aircraft that did this deliberately, for safety reasons.
One of the most important criteria for that software is determinism, which means no dynamic allocation since it is hard to predict how the allocator would behave. The stack can also be very limited in size, so what remains are global variables.
It also makes debugging easier. You know exactly which variable corresponds to which address in memory. And with a probe, you can know the full state of the program at any time. That's also how we tested "impossible" conditions (for coverage): by overwriting specific memory addresses.
Many of the reasons why globals are bad didn't apply there. We had no concurrency, no resources to share with other processes, in fact, we didn't even have an OS at first, Nothing was dynamic, all arrays were of fixed size, including strings, which were array of characters padded with spaces to the appropriate length.
Of course, we documented usage of these variables, proper up-to-date documentation was not an option as it was certified software. It was one of the most boring job I ever had, and it is probably for the best.