The goal I always strive for is simpler and easier to understood. My idea of a clever solution is one that introduces a major simplification. For example, if you can say, "Hey, wait a minute, we have to do all the same processing for take-out orders that we do for eat-in orders, except for this one little part about recording the tip to the waiter for tax purposes. Why is all the code written twice? Let's just write it once and call it twice." That simplifies the code and is clever. Or, "Hey, we're following the textbook formula that says to compare the cosines of the angles. But our angles are and must always be less than 90 degrees, so if cos A < cos B then B must be > A. Why don't we just compare A and B and skip the whole cosine calculation?" Etc.
"Too clever" is when you make the code harder to understand. Like when you say, "Hey, instead of this couple of IF statements that make completely clear to the reader what I am doing and why, I could just write 'x=x&0x374 + (y==1 ? 32 : 89) ^ (z-x)'. That's cool because not only is it one line instead of 4, but it looks really neat and no one will understand what it means except me!"
In real life, there are lot's of hazy cases. Well, here's one I just wrote myself recently. We had a block of code that was comparing two Java strings, but it had to consider the case where either or both were null. So the original code said this: (Apologies to those not familiar with Java. Hopefully the gist of the idea will be comprehensible).
if (s1==null && s2==null)
return true;
else if (s1==null && s2!=null)
return false;
else if (s1!=null && s2==null)
return false;
else if (s1!=null && s2!=null && s1.equals(s2))
return true;
else if (s1!=null && s2!=null && !s1.equals(s2))
return false;
else
return false;
There were some unnecessary tests in there that could certainly be eliminated. I simplfied it down to:
return s1==s2 || s1!=null && s1.equals(s2);
My version was certainly shorter and more efficient. Was it simpler or too clever? I think it's debatable. But I did it, which I guess says that I thought it was better.
Final comment: A solution that is just marginally "too clever" can be made "clever" by adding a comment that explains it.
To take a trivial example, I once worked on a program that performed a series of transformations on a matrix. It would start with matrix[0] and build matrix[1], then it would do its next transform reading matrix[1] and writing to matrix[0], etc, back and forth. So I had a couple of lines of code that said:
old=new;
new=1-old;
That could certainly be cryptic. So I included a comment that explained that this toggled us between 0 and 1. In that case, I thought a one-line comment adequate to explain to any competent programmer what I was up to.