Determining if three numbers are consecutive This code will determine if three numbers are consecutive for any order they're supplied to the method (any permutation of [n, n+1, n+2] should be accepted). Is there any way to make this code easier for me to write, or make the code more efficient? Any feedback would be most welcome! 

I tried testing with 3! combinations of 2, 3, 4, and it seemed to work. I also tried 1, 2, 9, and 1, 0, 1. All cases seem to work.

public static boolean consecutive(int a, int b, int c) {
    if ( a == b || b == c || a == c) {
        return false;
    } else if (((a == b + 1 || a == b - 1) || (a == c + 1 || a == c - 1)) &amp;&amp; ((b == c + 1 || b == c - 1)) 
               || ((b == c + 1 || b == c - 1) || (a == b + 1 || a == b - 1)) &amp;&amp; (a == c + 1 || a == c - 1))  {
        return true;
    } 
    return false;
}
The problem that I have with writing something like the original code is that it is complicated to be sure that it does the right thing in every situation.  You've taken three values and perform whopping fifteen comparisons on them.  What if you'd missed one?  The code would almost work, except it would occasionally (in that one situation) return the wrong result.  

A conceptually simple way to handle this is 

public static boolean consecutive(int... numbers) {
    Arrays.sort(numbers);

    for (int i = 1; i &lt; numbers.length; i++) {
        if (numbers[i] != numbers[i-1] + 1) {
            return false;
        }
    }

    return true;
}


Sorting saves a lot of logic here.  Since we know the order, we can just check the differences directly.  If any adjacent numbers are not consecutive, we can return false.  If it makes it all the way through, they all must be consecutive.  

Note that this also handles other than three numbers.  For example, it always returns true if there's zero or one number passed.  This may or may not be what you want.  

Now we do five manual comparisons (including the comparison of i to numbers.length) to determine that three numbers are consecutive.  The sort does more comparisons, but we don't have to worry if we got those correctly.  The chances of there being an error in sort that made it through the Java compiler's testing is extremely low.  

I find this version much easier to read and verify correctness than the original code.  For most cases, the difference in runtime is going to be minimal and unimportant.  My ability to write code that looks like this quickly and be sure it works is usually going to be more important.  And if you really need blazing speed, there are always options like @200_success offers.