Luke Skywalker wasn't ready to face Lord Voldemort after his first week at Camp Half-Blood. It takes him an entire school year instead. He had to train and practice and sweat (and bleed a little too) before getting ready for that final, climactic fight.

But enough about our crossover fan fiction epic. Becoming a recursion master doesn't take a blood sacrifice—or even an entire year of Care of Magical Demigods homework. In fact, we have a slew of tips and tricks in order to make the process even easier.

(And be sure to be on the look out for Star Wars Episode 4.5: The Lightning Thief's Stone: coming soon, to an online fan fiction archive near you.)

Base Cases: Spotting 'em Like a Pro

Base cases in recursive formulas and functions are generally pretty easy to spot. Just look for the return call that doesn't include a call to the function. Maybe the first value is concretely defined, acting as kind of a starting place to build the rest of the function. For example, if the function you need to program looks like this:

f(0) = 3
f(x) = f(x - 1)² + 3

The f(0) rule would be considered your base case because of the lack of a function call back to itself. Base cases are, generally, some hard and fast rule. They don't contain internal references to the function because that's the recursive step's job. Base cases in recursive sets don't always show up first in the set rules, but they kind of "happen" first: you need the base case in order to get any further.

In functions, base cases are a little trickier to tease out because they usually happen last. When you reach the base case, you're usually done—or almost done. Let's say we were given a couple rules to help save electricity in our house at night:

• If there are lights on in the current room, turn them off, move to the next room, and repeat.
• If all the lights in the house are off, stop turning lights off.

The words might sound intimidating but don't be fooled. The base case is that all the lights are off. That's a pretty sound rule in general: stop turning lights off if they're all already off. Like in the case of a math formula, this base case is simple and clear, but this time it's ending the function instead of starting it.

As far as programming goes, just figure out when the recursion should stop running (when the loop should be done doing whatever it needs to). That's going to be your base case. If you wanted to save money for the latest Star Wars movie, for instance, you could put a money in your Yoda-themed piggy bank one penny at a time until you hit that savings goal.

And in the meantime, listen to Yoda's sweet, sweet voice saying, "A penny earned, a penny saved is, mhm."

Recursive Loops

Once you've picked out the base case in your function, you can find the recursive loop pretty easily, too. Unlike the base case, the recursive loop references the function itself in its definition, meaning that any time you see something self-referential, it's at least a piece of the recursive pie.

In functions or sets, the recursive loop allows you to step from one value to another, like stones across a river (or chairs, couch cushions, and unsuspecting end tables in the floor is lava game).

f(5) = 10
f(x) = f(x + 3) × 2

Here's something new: we have a shifted base case to be 5, not 0. This kind of function is still recursive (since it calls itself and all), but it clearly isn't defined for all the integers that could be x. That makes the stepping stones/couch cushions not as close together as they were before. Some numbers thrown in just won't get solved.

Not good.

We can figure out f(2), sure, but what about f(3) or f(4)? To solve for those, we'll jump up to f(6) and f(7). Reaching those numbers means calling f(9) and f(10). Boom. Infinite recursion. There's no way to solve some numbers in the function, and you can figure it out at a glance.

We know we can solve for f(5). Since f(x) is dependent on f(x + 3), we can solve for any f(x) here:

x +3y = 5

where y is however many iterations it takes x to reach five after having 3 added to it. We can solve the equation when x is 2, -1, and -4, but we can't solve for 8 because it'll just keep adding on 3 until the end of time without ever figuring out a value. In math, that makes f(8) undefined. In computer science? That's infinite recursion.

Spotting the infinite recursion means figuring out the range of numbers where your recursion works. If there are holes, that's where the code's going to jump towards infinity. In general, though, recursive loops need to be geared toward eventually reaching the base case in some way or another.

If you wanted to catch all the Pokémon in Pokémon Red and Blue (base case alert), your recursive loop shouldn't be washing your cat or building a pillow fort. Are those both noble endeavors? Yes. Are they related to catching 'em all? Not even a little. Instead, you should be glued to the Game Boy simulator on your computer.

At the heart of it all, base cases and recursive loops need to work together in harmony in order to complete the task at hand. Be prepared to rework one or both of them when writing a program. That base case you thought absolutely, positively watertight might have some holes (probably cat-shaped, if you're still trying to do that). It's okay. Just adjust your base case, change your loop, or add in an early-exit condition and try again.

To summarize:

• Run the code.
• If code has errors, fix them and run again.
• If code runs successfully (and correctly), end the coding marathon.