creative & complex vs simple and readable

Question

Which is a better option?
It's not always that when you have something creative your code is going to look ugly.
But at times it does go a bit ugly.
e.g.

if ( (object1(0)==object2(0) &&
     (object1(1)==object2(1) &&
     (object1(2)==object2(2) &&
     (object1(3)==object2(3) )
    retval = true;
else
    retval = false;

is simple and readable

bool retValue = (object1(0)==object2(0)) && 
                (object1(1)==object2(1)) && 
                (object1(2)==object2(2)) && 
                (object1(3)==object2(3));

but having something like this will make some newbies scratch their heads.

So what do I go for? including simple code everywhere might sometime hamper my performance.
What I could think of was commenting wherever necessary but at times you get too curious to know what is actually happening.

Answer 1

Your second version IS far more simple and readable, and much better in every way. It's not creative or complex, but perfectly normal, straightforward code.

The only way in which it might confuse newbies is that it requires them to understand that complex boolean expressions are A) still expressions like any other and B) can be used wherever a boolean value is required, rather than just inside an if clause.

But this is something newbies really need to understand, so you should never let the possibility of someone not yet understanding it influence your code.

Answer 2

I don't see what's creative about either example at all, you're mostly just changing whitespace. If you think it's (potentially) unclear, try clarifying your intent, eg:

bool sameForEvery(int begin, int end)
{
  for (int i = begin; i <= end; ++i)
  {
    if (object1(i) != object2(i)) return false;
  }
  return true;
}

bool allthesame = sameForEvery(0, 3);

in general, understanding the implementation is easier if you know what the code is trying to achieve, and if the function (and variables) are well-named, you don't need to read the implementation to have a reasonable idea what the caller is doing.

---

Edit: went back and read the original version of the question.

Are you suggesting that manually unrolling this loop is a complex optimisation that might confuse people?

Answer 3

including simple code everywhere might sometime hamper my performance.

Don't prematurely optimize. Readable code is likely maintainable code. It is easier to optimize maintainable code, than to maintain unreadable (but fast) code.

That being said, both of your examples are less than readable. iterating through (as in @Useless's) answer, might help.

Answer 4

Respect to above mentioned example, both are readable and understandable perfectly. In general we should balance both.

Answer 5

Edit: The first revision of the question for which I have provided the answer below was changed. Since the question has already been well answered, I won't update this answer.

Your first approach is extendable to accommodate for more occurrences. If in the future your business would require to accommodate 50 objects for example, you must go with the first approach and even abstract the count by providing a variable limit for the loop. If this is not the case, option 2 is better because it is much simpler, contains less variables, and more concise.

Side notes:

1-What if one of the objects is null? Is this possible? One should consider this case.

2-Why did you not initialize the result before the loop in method 1? It is a good practice to do that.*

Answer 6

I think that both your examples are simple and readable. In general, I follow the Occam's razor or KISS principle: do not use a concept that is more difficult to understand unless you have some real gain from it.

In other words, the problem you are trying to solve is probably complex enough, do not make your solution even more complex. I would add that sometimes a simple solution requires a deeper analysis and much more creativity than a complex one.

I think these principles are particularly important if

1. You are working in a team: other programmers are going to have to read your code. They all know you are a good programmer already, no need to show off, just make it simple and readable.
2. You are developing something you have to deliver in time and according to some quality requirement: do not add extra complexity that you will have to manage yourself sooner or later. Customers won't read your source code.

On the other hand, if you are coding for your own fun and you want to try out new stuff, then do what you like better.

Just my 2 cents.

Answer 7

When doing any sort of optimization - whether trying to write it all in one line (optimizing my time), or use a shortcut to do the work (optimizing the compiler's time, or maybe the end user's time) - I try to balance the gain against the loss of time on the part of the reader who will come along later and try to understand my code.

One way to try to judge the cost/benefit is to add a comment to the optimized code that will make it as clear as the readable version. If it's too hard to explain well in a comment, it might be too costly.

Answer 8

Others have covered the "what's good/bad"-- here's an additional point that may have been missed:

Newbies scratching their heads is good.

By "newbie", I mean new programmer. Not "new addition to team".

Whenever a newbie scratches his head, he learns something. He may have to ask someone else, but he'll learn in the end. The example you've given is readable to any intermediate programmer, and will teach the fact that "the conditions inside ifs can be used directly to make bools--thus conditional statements are bools". Pretty useful thing to know--but AFAIK never really explained in books/courses.