3 ms·
> Since global variables are "evil", define a structure to hold all the things you'd put in globals. Call it something clever like EverythingYoullEverNeed. Make
by pure-awesome 8y ago
> Since global variables are "evil", define a structure to hold all the things you'd put in globals. Call it something clever like EverythingYoullEverNeed. Make all functions take a pointer to this structure (call it handle to confuse things more). This gives the impression that you're not using global variables, you're accessing everything through a "handle". Then declare one statically so that all the code is using the same copy anyway.
I see this in practice WAY too often... Heck, I've been somewhat guilty of it myself before.
(Bonus points if it's in a functional language :P )
- kevin_thibedeau 8y agoAnd it's perfectly valid on constrained systems where you don't have or want to make heavy use of malloc() and don't have namespaces. Provided the structs stay reasonably focused on one domain.
- pure-awesome 8y agoEmphasis on the "reasonably focused on one domain" part - it's when you're passing through your entire program state in one gigantic state object that things get messy. Also, I've been led to believe that design of constrained / embedded systems follow different rules. Your code can be unreadably complex if you have to squeeze out that extra performance (however, even then, it should probably be well-commented or well-documented), and generally (though not alway) such programs will be smaller and made by smaller teams. It's when these kind of practices are applied in enterprise software with large number of programmers, where maintainability is more important than performance, that this is an issue.