Recursion in Java

So I'm working on some sorts here, merge and quick. My merge works lovely. I get a stack overflow error with my quicksort method, so I'm not... recursing properly or something. Never exits the recursion. Ignore showProcess, that's for something else. l is the length of the array minus one.

 Quicksort

Code:

public static void quickSort (boolean showProcess, int low, int toSort[], int length){
                int lo = low;
                int hi = length;
                if (lo >= 1)
                {
                        return;
                }
                else
                {
                int pivot = toSort[lo];
                while (lo < hi) {
                        while (toSort[lo] <= pivot && lo <= length && hi > lo)
                                lo++;                                    
                        while (toSort[hi] > pivot && hi >= low && hi >= lo)
                                hi--;  
                        if (lo < hi)
                        {
                                int temp = toSort[lo];
                                toSort[lo] = toSort[hi];
                                toSort[hi] = temp;
                        }
                }
                if (hi < lo)
                {
                        int temp = hi;
                        hi = lo;
                        lo = temp;
                }
                quickSort(showProcess, low, toSort, lo - 1);
                quickSort(showProcess, lo + 1, toSort, length);
                }
        }

Oh god, the white space burns....

Could you please add [code]?

I honestly forgot that tag existed. XD

Please don't use "l" as a variable. It's too hard to distinguish what is "l" and what is "1" in the code. Also, why don't you use "toSort.getLength() - 1;" instead?

I really don't know about how quicksort works, so I'll leave that alone.

Please change the variables as Fiel said, I'm getting confused with the 1 and l.

Oh. I massively overcomplicated that. I see now, I forgot the conditional statements. derp

Why do we have that boolean without ever using it? Nevermind, I can't read.

I think the first statement is rather redundant. We've just entered the while loop, there's no reason to check right now whether or not "hi" is truly larger than "lo", is there? I guess you could do it just to be consistent with the other while, it didn't really help clarify things for me when I read it though.

There is also no need to specify that "lo <= length", since hi is always less than or at most equal to length, and you've already forced lo < hi before even doing anything.

Code:

while (lo < hi) {
                        while (toSort[lo] <= pivot && lo <= length && hi > lo) // <--- right here
                                lo++;                                    
                        while (toSort[hi] > pivot && hi >= low && hi >= lo)
                                hi--;

Also, if it were me, I'd choose more distinguishable names,. leftIndex and low for example.
look in indexes on the left of the pivot point to find a value that doesn't belong there translates nicely into:

Code:

while (toSort[leftIndex] < pivotValue) {
   leftIndex++;
}

I haven't really done any collaborative coding, so I still don't have a good idea what criteria constitute readable codes. I do know, though, that I had trouble reading yours. Could just be my limited understanding regarding quickSort itself, so iunno.

Trust me, it used to be worse before. I used to name all my booleans derpington regardless of what they did. XD

Haven't started commenting yet because it didn't work at the time, so. Is the lack of comments the only confusing thing? Readability is something I've been working on, I'd like to know where I can improve on that.

Trust me, it used to be worse before. I used to name all my booleans derpington regardless of what they did. XD

Haven't started commenting yet because it didn't work at the time, so. Is the lack of comments the only confusing thing? Readability is something I've been working on, I'd like to know where I can improve on that.

Now THAT is something I would use...

At my level, I think it is easier to read cascading levels of conditions than combined ones. While they are essentially the same thing from a logical standpoint; from a programming standpoint, indentation helps you quickly (and accurately) grasp the scope of each conditional.

Another thing I find worth trying is commenting as you go through the logic, kinda like pseudocode. I've always started commenting AFTER everything works as well, it's always been more of a "documentation" for anyone reading my code. But I've come to realize that I could document it for myself as well, multi-tasking on both micro and macro levels is going to take a heavy toll on your head, unless you have a multi-core brain.

I write comments before, during, and after writing code. In order to develop code, I'm thinking about the problem, and I like a record of that, so a multitude of comments. I guess that applies a little less when you're given an algorithm and just have to implement it.

I write comments before, during, and after writing code. In order to develop code, I'm thinking about the problem, and I like a record of that, so a multitude of comments. I guess that applies a little less when you're given an algorithm and just have to implement it.

Same here.
Since we rarely do "flowcharts" and "pseudo-code" except in extreme cases, the comments I put in before the code serve that same purpose of keeping a general overview of the algorithm in my mind and view.
Then, every line or chunk of code that required more than a second's thought to write, gets documented as it is written. So I don't have to spend ten times as long, later, trying to understand what I did (or tried to do) there - and anyone else reading it doesn't mistake what it does, how, and why, either.
After the coding and debugging are done, there are usually very few comments that need adding. Mostly stuff like formal headers required by project documentation rules.