Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When choosing a value based off of 2 boolean values in this format

var foo:int;

if (X){
    foo = 50;
} else if (Y){
    foo = -50;
} else {
    foo = 0;
}

I discovered that I can condense this down by typecasting the boolean operations to integers, and mathing it up a bit like so:

var foo:int;

foo = ( int (X) - int(!X && Y) ) * 50;
// int() typecasts a boolean argument to an int of 1 if true, 0 if false.

Here are my questions:

  1. Is this approach less resource intensive?
  2. Is this approach readable to you?
  3. Is assigning values in this way common?
  4. If 1 is true then in your opinion, does the performance increase justify the less readable nature of this approach?

This situation arose in ActionScript 3.0, but I am interested in answers from all languages, and from a best practice perspective.

share|improve this question
1  
"i am interested in answers from all languages" – I don't even know any programming language that would allow such a horrible thing. –  Jörg W Mittag Mar 24 '13 at 1:39
1  
The second approach, when I see it in code I am maintaining, is the kind that makes it quite likely I will become the psychopathic mass murderer, who will find out where you live, that your tutor should have warned you about. –  mattnz Mar 24 '13 at 6:30
    
I'm self taught, so i'm really not sure what would be readable to other people. –  kris welsh Mar 25 '13 at 7:41
    
I've learnt quite a bit since posting this and for the love of god please don't use this. Children will spit at your feet as you walk past them for enacting such a travesty. –  kris welsh Aug 12 '13 at 19:25
add comment

2 Answers

up vote 5 down vote accepted

This is to some extent a matter of style, but I really believe your single-line option is much, much less readable, and is not a common approach.

The first classic if is very easy to read and check. There's no complex nesting, just a plain, "boring", chain of conditions that is well understood in all languages that have an if/else if/else construct.

The second is very tricky:

  • Two conditionals, one of them a composite for which you need to know operator precedence
    (is !X && Y interpreted as (!X) && Y or !(X && Y))
  • Two casts for which you need to know that true is converted to 1 and false to 0 (or are those function calls?). This might be common, but it's something people aren't always aware of, or aware that the language guarantees that. (That is if you're indeed using a built-in cast in this example - if it's a custom function call, then that needs to be known too)
  • Then you have to figure out what the result of that - operation will be in what circumstances. Pretty basic maths, but needs a few brain cycles more than the trivial if/else cascade.

As for the second version could somehow be more efficient? I don't think so. In fact, it might be not only less efficient, but not behave the same way as the first. X is evaluated twice (so potentially more expensive). If the evaluation of X has side-effects, the two versions aren't equivalent.

(And let's not mention C-type macros that could break the second version while the first works, or the issues with un-sequenced operations your second version could entail in C and C++ because of that double evaluation in a single statement - I don't think that's the point of your question here.)

tl;dr: less lines of code does not mean more efficient. Your code should be written so that it can be efficiently maintained. Your compiler/runtime/interpreter will take care of the dirty work of optimizing as long as you've chosen the right algorithms and data structures and expressed them clearly in your language.

share|improve this answer
    
+1 for emphasising maintenance –  SpacedMonkey Mar 24 '13 at 10:43
    
Thank you, i knew that the if/else chain was the more readable approach, but i was unsure of which was more efficient, and i hadn't thought of the ramifications of the double X evaluation or operator precedence. –  kris welsh Mar 25 '13 at 8:47
add comment

Is this approach less resource intensive?

I wrote two simple bits of C and looked at the dissassembly of each.

#include <stdio.h>

int main(int argc, const char * argv[])
{
    char x = argv[1][0] == 't';
    char y = argv[1][1] == 't';
    int foo;

    if(x) {
        foo = 50;
    } else if (y) {
        foo = -50;
    } else {
        foo = 0;
    }

    printf("%d",foo);
    return 0;
}

and

#include <stdio.h>

int main(int argc, const char * argv[])
{
    char x = argv[1][0] == 't';
    char y = argv[1][1] == 't';
    int foo = ( x - (!x && y) ) * 50;

    printf("%d",foo);
    return 0;
}

Pardon my dissasemblines, I'm on a mac rather than a linux box and so I don't have easy access to gcc -S so I'm not going to paste them here. When looking at the sequence of events in each that is the if statements or the expression:

This sequence in the first is:
cmpb je movl jmp cmpb je movl jmp movl jmp leaq movl movb
The same reigon in the second version is:
movsbl cmpb movl movb jne movsbl cmpl setne movb movb leaq andb movzbl movl subl imull movl movl movb

The first you can see the compare, jump equal, assign, jump to end, compare, jump equal, assign, jump to end, assign. IN the second, there is a significant amount of operations being done. One can see the andb, subl and imull doing arithmetic operators.

The first will do a small number of comparisons to constants and branches. The second does a significant number of operations.

Is this approach readable to you?

The first is by far more readable and maintainable. Even if the second was to produce more optimal code, I would still write the first as the fractions of a second that are saved in the code are lost many times over when someone comes back to maintain the code and goes WTF?!

Is assigning values in this way common?

No. I have never seen it before this situation.

If 1 is true then in your opinion, does the performance increase justify the less readable nature of this approach?

As I mentioned, the maintainability of the code is paramount in any situation where someone else may ever have the joys of touching your code later.

As a perl programmer, I recognize the value of hubris:

Hurbis: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer.

I know I would say bad things about a programmer that writes the second, so I'm not about to do so.

share|improve this answer
    
thank you for your response. i am not advocating the second method, i just stumbled upon it and didn't think i'd seen it before anywhere else so i wanted others thoughts on it, i should have realized that it's not good practice from the fat that i hadn't seen it elsewhere. –  kris welsh Mar 29 '13 at 9:47
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.