CODEWITHSUNDEEP
logicvariable-assignmentlogical-operators
zigzag
zigzag

Reputation: 415

Blending Boolean Algebra and Numeric Algebra to assign variables

I have written some code which assigns variables using the results of condition expressions without the explicit use of IF-ELSE statements.

In the simplest form, the problem looks like this:

Version 1

if (x < K)
   y = A;
else 
   y = B;

I've seen a "trick" in the past in which people accomplish the same task in one line without the conditional like this:

Version 2

y = (x < K) * A + !(x < K) * B;

This approach extends relatively easily to handle IF-ELSE IF-ELSE assignments. The trick is to ensure that the conditions are all mutually exclusive.

From a unit testing perspective, I'm required to achieve 100% code path coverage.

My coworkers agree that the Version 2 is more elegant, but they contend it is less readable. Furthermore, they argue that I am "side-stepping" the path coverage requirement and that I would be able to achieve 100% path coverage by "hiding" the conditional logic inside the single line of code without actually exercising both conditions ((x < K) and !(x < K)).

I argue that I am able to blend Boolean algebra and numeric algebra to perform variable assignment because the computer treats Boolean 'true' and 'false' as '1' and '0' which can be multiplied by 'float' and 'int' variables. To me, it becomes simply an arithmetic expression with zeros and ones multiplying variables.

Why am I doing this?

I am doing this blend of Boolean and numeric algebra to minimize the number of IF-statements, minimize lines of code, and general code cleanup. Obviously performance can be improved by saving the result of the condition to a variable and referencing.

The Question

Is this practice (and ternary operators) frowned upon from a unit testing perspective?

If this question is too subjective, please suggest edits.

Upvotes: 0

Views: 49

Answers (1)

Alexey Romanov
Alexey Romanov

Reputation: 170859

I'd suggest avoiding it (this trick is actually useful when the intention is to avoid branching, which may be the context you've seen it in). Given that the language doesn't have a conditional operator, you should be able to define the equivalent of 

cond(bool, x, y) { if (bool) return x; else return y; }

yourself and write y = cond(x < K, A, B). It's more readable, harder to make a mistake when writing, is usable with non-number types, and is considered correctly in path coverage. It evaluates both sides, unlike the actual conditional operator (unless the language has macros or lazy evaluation), but so does the described trick.

Upvotes: 1

Related Questions