7

I was looking through some of the CFArray code after finding out it was open source and I found some, to me, strange code. What is the point of these "empty" if (0) conditionals? Is there some crazy benefit or is this just left over from something? This code is on line 957 of CFArray.c at GitHub.

if (0) {

} 
else if (NULL == array->_store) {
    if (0) {

    } 
    else if (0 <= futureCnt) {
           // blah blah
    }
}
Matthias Bauch
  • 89,811
  • 20
  • 225
  • 247
Halnry
  • 418
  • 2
  • 10
  • 2
    It looks to me like a "don't execute this code" hack. – Robert Harvey Jun 28 '13 at 20:25
  • That's what I thought at first because of the indentation but it's actually `if (0) {} else if(validStuff) {}. – Halnry Jun 28 '13 at 20:28
  • might be a leftover from debugging the code. but i can merely guess... – katzenhut Jun 28 '13 at 20:30
  • I think it's just a placeholder, like the author is planning on replacing that `0` with some other condition later and just wanted to get the code into a state where the later changes will have a minimal diff. – Aaron Golden Jun 28 '13 at 20:30
  • 9
    Ah, I see. Well, then it's probably just a placeholder. I personally wouldn't do it. Using it causes people to post questions on public websites like Stack Overflow because they're confused. Bonus floggings for the original programmer not explaining himself in a comment. – Robert Harvey Jun 28 '13 at 20:31
  • That makes the most sense. I originally started wondering if it some how caused the compiler to be able to do evil things but I really don't see how. – Halnry Jun 28 '13 at 20:32
  • The comment above the lines you pasted says `// region B elements are now "dead"`. That doesn’t explain why they didn’t just delete it, though. – Zev Eisenberg Jun 28 '13 at 20:38
  • It's perfectly natural, upon "deleting" some code in a large app, to be reluctant to totally delete the code, since you often can't totally comprehend/anticipate all of the implications of what you're doing, and may want to go back and at least study (if not restore) the deleted code some time in the future. I prefer to either comment it out or use `#if 0 / #endif` to "kill" it, but have used `if(0)` on occasion. – Hot Licks Jun 28 '13 at 21:53
  • It is less about reluctance and more about risk reduction. By replacing the existing `if () { .. }` clauses with `if (0) {}` the structure of the scopes is entirely unchanged and, thus, there is less chance of screwing something up. That and, yeah, there are only so many hours in the day. – bbum Jun 28 '13 at 22:09

2 Answers2

7

They are most likely remnants from one of the many migrations of the codebase from platform to platform over its many year history. And, in general, if you have a tool that automatically and correctly migrates code from form A to form B, you generally don't want to manually muck with it after the fact because there is too much risk of introducing error.

If you go way back in time to the transition from NeXTSTEP to OpenStep, there was a conversion technology called TOPS that was used to automate the conversion from API to API. A second variant was created to migrate from Objective-C to Java in the WebObjects days.

It was, effectively, a sort of automated refactoring engine focused on transmogrifying API and language.

TOPS was quite powerful and could easily be extended. It has been used quite effectively to perform various kinds of migrations -- version, API, style, etc.. -- both in the 3rd party community and inside of Apple/NeXT.

(Personally, the last time I used TOPS was ~2002ish to migrate a 750,000 line NeXTSTEP 3.3 Objective-C++ application to Mac OS X 10.2. Required migrating from 3.3 -> 4.2, 4.2 -> PR1, PR1 -> 10.2. Was quite a challenge, but a lot of fun. There is a little more background here: http://www.cocoabuilder.com/archive/cocoa/221418-porting-from-windows-to-mac.html.)

bbum
  • 162,346
  • 23
  • 271
  • 359
1

Likely, that was done to omit a codepath without incurring an unreachable code warning/error.

LexLythius
  • 1,904
  • 1
  • 12
  • 20