[mentos]

What is wrapping all new features in a #ifdef NEW_FEATURE //code #endif called?

My process over the last 7 years working in game dev has slowly evolved to this where I'll ask a contractor to implement a feature on the main branch but make sure that it is completely toggleable via a #define NEW_FEATURE

I thought I was pretty clever until I read an article on HN a few years ago that this is exactly what Google does lol

[jan_g]

This approach works surprisingly well for most features, but care should be taken to remove those 'ifs' once the feature is stable/complete. Or, when implemented cleanly, they could also be left in place and used as long lived feature toggles that can be driven by configs (or user settings, ...).

The hairy part is when the new feature or change cuts across different parts of the code and then, given enough time, those 'ifs' pollute the codebase. Solution here is to be mindful of how the system grows, keeping things isolated and (perhaps counter-intuitive) favor duplication over shared logic/libraries. Regardless if it's about one big thing (i.e. monolith) or multiple small things (different projects even).

[erezsh]

Yeah, and let me tell you, it's an absolute nightmare to get to work when you need two features that weren't written to compile at the same time.

I'm not saying it's necessarily a bad idea. Just that it isn't a replacement for abstraction. If you have more than a couple of #ifdef blocks per feature, you might be setting yourself up for future pain.

[kkirsche]

I think you are describing build-time feature flags or feature toggles. Similarly, this type of thing can be managed at runtime via integrations or implementing a database backed version yourself.