Another good reason to code something all in one line is to learn why not to.

I often have the situation where a chunk of code "feels wrong" -- something seems a little clunky about it. I will attack those chunks by condensing them to the minimum possible amount of code. Often this will reveal a slightly more streamlined way of thinking about what the code is doing, and I will be able to recode it differently to more directly express that simpler mental understanding. (The new version may or may not be the maximally trimmed-down version; it may just be informed by it.)

And at least as often, I will be immediately revolted by the hypercondensed version, and it will make me realize why things need to be expanded out. Once again, I will probably rewrite the code, but this time targeting the extra verbosity at the portion where it is really needed. The result won't be much shorter or longer than the original, but it will "feel" better.

A typical example is when you have written a sequence of transformation steps using one or more temporary variables that don't really mean anything; they are merely intermediate data structures. If you eliminated all of them and just had one transformation feed directly into the next, then the result would be an opaque glob of scary code. But from that, you can choose what temporary values do mean something real, and break up the computation at those spots. (Good rule of thumb: if your temporary variable is named '@tmp' or '$x', there's a good chance you should get rid of it. If it has a meaningful name, it will probably help a reader figure out what is going on. If it has a meaningful name that doesn't match its meaning, you will need to avoid traveling to certain countries where you could be tried and hanged for Willful Codeslaughter.)