By coding style trap, do you mean (and we've all seen it) that you just end up adding to the if
statement? So you'd eventually get:
if ( a == 2 || a == 3 || a == 5 || a == 14 ) // etc.
as more conditions are added, supported. For example, imagine that a
is a message type or tradable commodity and as more message types or commodities are supported, the code gets more and more convoluted.
Additionally, this check can get duplicated around all over the place as programmers who don't understand the original necessarily or are not given the time to refactor simply seek to duplicate this condition without understanding it.
Before you know it, the code is (a) very difficult to read and understand (what does i == 5 || j == 3
actually mean?) and, (b) because you're adding conditions to code, it becomes far more difficult to test.
Much better if possible to put this logic in one place where it can be documented:
inline bool isEngineStarted() { return i == 5 || j == 3; }
if ( isEngineStarted() ) // etc.,
That would be my first consideration - make it work in an understandable and easily maintainable way.
In terms of performance one suggestion you might want to look at is if you have a few different values in a relatively small range to compare to, you might find that a sparse vector of booleans may work better as, in theory, the lookup costs the same regardless of the number of alternative value (i.e. O(1) rather than O(N) ) So if you had, say:
for ( int a = 0; a < 1000000000; ++a )
{
int c = a % 16;
if ( c == 2 || c == 3 || c == 5 || c == 14 ) b++;
}
You might find it works quicker like this:
int b = 0;
bool sp[] = { false, false, true, true, false, true, false, false, false, false, false, false, false, false, true, false };
for ( int a = 0; a < 1000000000; ++a )
{
int c = a % 16;
if ( sp[ c ] ) b++;
}
I have to say, when I tried this, surprisingly, the first one worked faster! I'd be interested to know if anyone can suggest why.