Perhaps one of the boolean literals used to be a variable, and they just didn't think to change the operator when they changed the operand. Obviously the logic is equivalent.

More likely, they were thinking that in the second case, they want to retain the result of evaluating the first "if" condition. Of course, that's false reasoning.

A simpler equivalent statement:

bool tmp = somecase | someOtherCase;

EDIT

As pickypg notes, this statement could be confusing, since most people don't expect | with boolean values, and many won't notice it, or won't think about the implications for side effects. The best way to be explicit (if indeed there are side effects) would be minitech's solution: just change the |= to =.

Or, if there are no side effects to the someOtherCase expression, use Jakub Konecki's solution : someCase || someOtherCase.

That's what we thought.. or maybe a lucky type-o.
–
carny666Mar 28 '12 at 14:48

1

I suspect that was the original code, but even that should be converted to bool tmp = somecase || someOtherCase; to let short circuiting do its job. If you want the side effects, then chances are you're destroying readability by one-lining the code, particularly by implicitly associating the two methods that can only be loosely associated at that point (as the first is not preventing the second by "failing" or whatever false represents).
–
pickypgSep 7 '12 at 18:58

@pickypg I agree that one-lining the code with | decreases readability. There's also a huge chance that someone will "correct" the | to || at some point. Both of these are true because using | with boolean values isn't really idiomatic C#. I find that a shame, but there's not much to be done about it.
–
phoogDec 5 '12 at 14:42

A clever compiler could avoid the assignment in this case, though it probably wouldn't as it shouldn't short-circuit a bitwise operation. In any event, it seems like a micro-optimization. In reality I suspect it's a hold-over pattern the author has from using bit flags (or s/he just doesn't understand how it works). It would be better as:

This does not preserve side effects of someOtherCase, if there are any to be preserved.
–
phoogMar 28 '12 at 14:51

@phoog - that's true. if the cases are functions or otherwise contain statements, then using lazy evaluation wouldn't be the same and they shouldn't be combined.
–
tvanfossonMar 28 '12 at 14:53

You could combine them with the | operator.
–
phoogMar 28 '12 at 14:55

1

@phoog that would be the purest sort of evil. IMO, depending on the reader to distinguish between bitwise OR and logical OR to determine the evaluation of a statement (on booleans) is the worst sort of coding magic. I'd rather split the condition and evaluate in two statements to make it clear what the expectations are. I've long used the rule that you only use logical operators on boolean variables.
–
tvanfossonMar 28 '12 at 14:58

I agree with you; the subtle difference between the two operators makes it far too easy to misread one for the other. Your terminology doesn't agree with Microsoft's, however; they classify both operators as logical, and make a distinction between bitwise logic and boolean logic: msdn.microsoft.com/en-us/library/6a71f45d(v=vs.100).aspx
–
phoogMar 28 '12 at 15:15