Programming Principles: Assignement vs Conditions

Question

I did some research but couldn't find the answer I was looking for so I figured I'd address this issue here. I guess it's better to demonstrate it using examples, so consider the following snippets of code:

int delta = 0;
if (some_condition)
    delta = 42;

x1 = regular_value1 + delta;
x2 = regular_value2 + delta;
// ...
// where delta is used a lot of times
// basically - if (some_condition == true) => add delta to all variables
// if FALSE - add 0 (thus, effectively not changing anything)

versus

int delta = 42;

if (some_condition)
{
    x1 = regular_value1 + delta;
    x2 = regular_value2 + delta;
    // ...
}
else
{
    x1 = regular_value1;
    x2 = regular_value2;
    // ...
}

For example, a very simple real-world scenario would be: Let's say I'm creating a windows form that might contain an image on the left and might not. If there's no image - create all the rest of form controls on the left, and if there's an image, shift all other controls to the right of the image (add delta to every control's X location).

I'm programming a C# XNA game (therefore performance is somewhat relevant, but OOP principles shouldn't be omitted by any means), thus my question is - which code would run faster provided that "some_condition" would be TRUE 50% of time? As well as, which code block is easier to maintain/read?

I'm aware that this isn't a huge issue, but I'm just trying to get into a habit of writing "the best" code possible. Any input and even personal experiences would be appreciated.

Thanks.

Answer 1

The latter might be slightly faster, or they may both be optimized to the same thing. That doesn't matter, you can always change it later if you find that it becomes an issue (which this particular case certainly won't - this is just general advice). But the former, I find at least, is easier to read and maintain. If you wanted to change regular_value1 or regular_value2, you only have to change it in one place, not two. Go for that.

Answer 2

This is certainly a trivial case, and both might indeed optomize to the same code. I'd suggest using whichever is easiest to understand--a decision that ought to be based on more of the program than you've shown here.

But the second solution is apt to be faster, particularly if "delta" is turned into a constant. If "some_condition" is false, no adds need to be done, and an optmizer might be able to come up with some way to speed the actual assignments, so I see a performance edge there. I think it's best to write the fastest code you can if you don't hurt maintainability. Even with something with a much bigger performance difference than this, you are realistically never going to come back later looking for ways to speed it up. You may as well code for performance now and forget about it. Keep this up over time and your code will run faster at no cost to you.

Maybe someday profiling will point to this code as being the slowest point in your program. But most likely you--and others--will just accept the fact that the code runs at a certain speed and use it accordingly. The fact that it could be speeded up and used in new places--say between keystrokes--without annoying the user will never be thought of.

The difference in performance here is minor and the code will probably never be used in speed-critical conditions anyway, but I do think coding for speed is a good idea. It doesn't really take any time once you get into the habit, and you know what your code can do if tweaked because its already tweaked and doing it.

(It's been my experience that fast code and readable code are much the same thing. If a human can understand the code easily then so can the optimizer, and these days the optimizer is king. On those rare occasions where I have to choose, I do go for clarity rather than speed unless I know everything depends on the code being fast. Then I document like crazy to atone.)

Answer 3

This is a bit of a subjective question, but one the things that affects readability (and also importantly maintainability) is how much code is repeated. In this case the first option results in less code to maintain and read through (less redundancy) and would be my preferred method

Answer 4

As pointed out by @minitech, the second approach can and will certainly cause problems in maintainability (points to ponder: how long is the life cycle of the application? Is the code you are writing going to be reused or consumed by others?) and readability. Given, that you have already considered these factors, I would recommend that you decide and set some performance numbers that your application should conform to.

Once the performance requirements have been clearly established, then you can decide on which approach to follow. OOP principles and readability are every programmers dream, but remember that once you ship the application to the customer, it does not matter which approach you had followed, the only thing that matters is your application runs as expected (from the point of view of both functionality and performance).

You will need to gauge with the stakeholders on the implications of writing the 'best' vs actual performance impact that the 'best' code might cause.