Is it beneficial(in terms of memory & space complexity) to write a few lines of code into a single line. Is it worth it?

Question

Example: Simple program of swapping two nos.

 int a = 10;
 int b = 20;
 a = a+b;
 b = a-b;
 a = a-b;

Now in the following piece of code:

 a=a+b-(b=a);

I mean What is the difference b/w these two piece of codes?

Addition : What if the addition of these two exceed the legitimate limit of an Integer which is different in case of Java & C++?

Answer 1

Neither of these looks good to me. Readability is key. If you want to swap values, the most "obvious" way to do it is via a temporary value:

int a = 10;
int b = 20;

int tmp = a;
a = b;
b = tmp;

I neither know nor would I usually care whether this was as efficient as the "clever" approaches involving arithmetic. Until someone proves that the difference in performance is significant within a real application , I'd aim for the simplest possible code that works. Not just here, but for all code. Decide how well you need it to perform (and in what dimensions), test it, and change it to be more complicated but efficient if you need to .

(Of course, if you've got a swap operation available within your platform, use that instead... even clearer.)

Answer 2

In C++, the code yields undefined behavior because there's no sequence point in a+b-(b=a) and you're changing b and reading from it.

You're better off using std::swap(a,b) , it is optimized for speed and much more readable than what you have there.

Answer 3

Since your specific code is already commented upon, i would just add a general aspect. Writing one liners doesn't really matter because at instruction level, you cannot escape the number of steps your assembly is going to translate into machine code. Most of the compilers would already optimize accordingly.

That is, unless the one liner is actually using a different mechanism to achieve the goal for eg in case of swapping two variables, if you do not use a third variable and can avoid all the hurdles such as type overflow etc. and use bitwise operators for instance, then you might have saved one memory location and thereby access time to it.

In practice, this is of almost no value and is trouble for readability as already mentioned in other answers. Professional programs need to be maintained by people so they should be easy to understand.

One definition of good code is Code actually does what it appears to be doing

Even you yourself would find it hard to fix your own code if it is written cleverly in terms of some what shortened but complex operations. Readability should always be prioritized and most of the times, the real needed efficiency comes from improving design, approach or better data structures/algorithms, than instead short - one liners.

Quoting Dijkstra : The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.

Answer 4

A couple points:

• Code should first reflect your intentions . After all, it's meant for humans to read. After that, if you really really must, you can start to tweak the code for performance. Most of all never write code to demonstrate a gimmick or bit twiddling hack.
• Breaking code onto multiple lines has absolutely no impact on performance.
• Don't underestimate the compiler's optimizer. Just write the code as intuitively as possible, and the optimizer will ensure it has the best performance.

In this regard, the most descriptive, intuitive, fastest code, is:

std::swap(a, b);

Answer 5

Readability and instant understand-ability is what I personally rate (and several others may vote for) when writing and reading code. It improves maintainability. In the particular example provided, it is difficult to understand immediately what the author is trying to achieve in those few lines. The single line code: a=a+b-(b=a); although very clever does not convey the author's intent to others obviously.

In terms of efficiency, optimisation by the compiler will achieve that anyway.

Answer 6

In terms of java at least i remember reading that the JVM is optimized for normal straight forward uses so often times you just fool yourself if you try to do stuff like that.

Moreover it looks awful.

Answer 7

OK, try this. Next time you have a strange bug, start by squashing up as much code into single lines as you can.

Wait a couple weeks so you've forgotten how it's supposed to work.

Try to debug it.

Answer 8

Of course it depends on the compiler. Although I cannot foresee any kind of earth-shattering difference. Abstruse code is the main one.