4 ms·

I'm really curious as to how this happened. In the app I work on, all of our debug features are wrapped in Preprocessor Macros so they'll only run in debug mode

I'm really curious as to how this happened. In the app I work on, all of our debug features are wrapped in Preprocessor Macros so they'll only run in debug mode.

ldidi 11y ago
Happened to me at my previous company. We had a bunch of #ifdef DEBUG that wrapped non user-facing code. One day someone added DEBUG=1 in debug mode, DEBUG=0 in release mode, which led to the macro check always being true. The change was hidden in the Github PR since it was in our .xcodeproj. Nobody noticed, but even if we did, I'm not sure we would have guessed the actual impact of it.
- Camillo 11y ago
  I think people overuse #ifdef when they should really be using #if.
  - mikeash 11y ago
    I'd wager that less than 10% of iOS programmers know that #if works (by treating as false) when the token is not defined.
to3m 11y ago
I've done this sort of thing once, and nearly done it several times more. The time the product was released like that, it was a Makefile setting a rather important flag using ?=, in a sub-Makefile two includes deep, and because that happened to have always been the first time CFLAGS was set, it worked. Until I added a new flag. (Solution: don't set your Makefile variables like that.) When I've nearly done it, it's always been on projects that have the fairly standard Debug/Release build config system (via whatever mechanism), and the Release build is the one that gets released. But then you have no config corresponding to Release-and-some-temporary-debug-stuff, which is something you basically always need. But if you manage this by hand, it's too easy to slip up and have some debug stuff end up in the final product. (Solution: have an extra build config, Final/Product/etc., that is what you use when preparing the final build. So if you get it wrong and leave your debug stuff in the Release build, the result never gets further than other team members.)

I'm really curious as to how this happened. In the app I work on, all of our debug features are wrapped in Preprocessor Macros so they'll only run in debug mode.

ldidi 11y ago

Happened to me at my previous company. We had a bunch of #ifdef DEBUG that wrapped non user-facing code. One day someone added DEBUG=1 in debug mode, DEBUG=0 in release mode, which led to the macro check always being true. The change was hidden in the Github PR since it was in our .xcodeproj. Nobody noticed, but even if we did, I'm not sure we would have guessed the actual impact of it.

Camillo 11y ago
I think people overuse #ifdef when they should really be using #if.
- mikeash 11y ago
  I'd wager that less than 10% of iOS programmers know that #if works (by treating as false) when the token is not defined.

to3m 11y ago

I've done this sort of thing once, and nearly done it several times more. The time the product was released like that, it was a Makefile setting a rather important flag using ?=, in a sub-Makefile two includes deep, and because that happened to have always been the first time CFLAGS was set, it worked. Until I added a new flag. (Solution: don't set your Makefile variables like that.) When I've nearly done it, it's always been on projects that have the fairly standard Debug/Release build config system (via whatever mechanism), and the Release build is the one that gets released. But then you have no config corresponding to Release-and-some-temporary-debug-stuff, which is something you basically always need. But if you manage this by hand, it's too easy to slip up and have some debug stuff end up in the final product. (Solution: have an extra build config, Final/Product/etc., that is what you use when preparing the final build. So if you get it wrong and leave your debug stuff in the Release build, the result never gets further than other team members.)