I have this ugly code:
if ( v > 10 ) size = 6;
if ( v > 22 ) size = 5;
if ( v > 51 ) size = 4;
if ( v > 68 ) size = 3;
if ( v > 117 ) size = 2
why somebody have not suggested switch statement. it is far better then if else ladder.
public int getSize(int input)
{
int size = 0;
switch(input)
{
case 10:
size = 6;
break;
case 22:
size = 5;
break;
case 51:
size = 4;
break;
case 68:
size = 3;
break;
case 117:
size = 2;
break;
case 145:
size = 1;
break;
}
return size;
}
Just for completeness, let me suggest that you could set up an array SIZES with 145 elements so the answer could be returned directly as SIZES[v]. Pardon me for not writing the whole thing out. You would have to make sure v was in range, of course.
The only reason I can think of for doing it that way would be if you were going to create the array once and use it thousands of time in an application that had to be really fast. I mention it as an example of a trade-off between memory and speed (not the problem it once was), and also between setup time and speed.
It is interesting that there are plenty of beautiful answers for a simple "ugly" question. I like mfloryan's answer best, however I would push it further by removing the hard-coded array inside the method. Something like,
int getIndex(int v, int[] descArray) {
for(int i = 0; i < descArray.length; i++)
if(v > descArray[i]) return i + 1;
return 0;
}
It now becomes more flexible and can process any given array in descending order and the method will find the index where the value 'v' belongs.
PS. I cannot comment yet on the answers.
Here's my shot at it...
Update: Fixed. Previous Solution gave incorrect answers for exact values (10,22,51...). This one defaults to 6 for the if val < 10
static int Foo(int val)
{
//6, 5, 4, 3, 2 ,1
int[] v = new int[]{10,22,51,68,117,145};
int pos = Arrays.binarySearch(v, val-1);
if ( pos < 0) pos = ~pos;
if ( pos > 0) pos --;
return 6-pos;
}
My commenting ability isn't turned on yet, hopefully no one will say "rightfully" based on my answer...
Pretty-ing up the ugly code could/should be defined as trying to achieve:
IMO the answer given by org.life.java was the prettiest and extremely easy to read. I also liked the order in which the conditions were written, for reasons of reading and performance.
Looking over all the comments on this subject, at the time of my writing, it appears that only org.life.java raised the issue of performance (and maybe mfloryan, too, stating something would be "longer"). Certainly in most situations, and given this example it shouldn't bear a noticeable slowdown however you write it.
However, by nesting your conditions and optimally ordering the conditions can improve performance [worthwhile, particularly if this were looped].
All that being said, nesting and ordering conditions (that are more complex than your example) brought on by determination to achieve as fast as possible execution will often produce less readable code, and code that's harder to change. I refer again to #3, pragmatism... balancing the needs.
The original code seems fine to me, but if you don't mind multiple returns you might prefer a more tabular approach:
if ( v > 145 ) return 1;
if ( v > 117 ) return 2;
if ( v > 68 ) return 3;
if ( v > 51 ) return 4;
if ( v > 22 ) return 5;
if ( v > 10 ) return 6;
return ...; // The <= 10 case isn't handled in the original code snippet.
See the multiple return or not discussion in org.life.java's answer.