A colleague of mine asked me yesterday: what’s the difference between good code and bad ones? I gave my answer without a blink: “Reusability.” The answer struck me. I didn’t realise that before I said it out loud.

One good way to improve reusability, is to consciously refine one’s code with an eye for patterns. Repetitions are worth summing up–it’s just pure fun.

I remember answering a question on Quora about how programmers manage to write insanely abstract programs. I had said, abstraction is the best way to sum repetitive things up. E.g., instead of checking the mailbox ten times you “abstract” them into one. And instead of checking the mailbox, milk box, newspaper… each ten times everyday you “abstract” them into an even higher abstraction. Same thing could go on and on, so the process is really like building a concrete empire, “going up in abstraction”, layer by layer. Until at some point the code starts to seem so abstract to outliers it’s downright intimidating. But the programmers themselves don’t feel that way, because they’ve got their program constructed bottom-up. For them, it’s writing code with a whole new language–the one they build upon the original one. The syntax is similar, but they are no longer the same.

And that’s why it’s so damn hard to read others’ code: they’re constructing their empire of functions on a highland they built throughout their years of being a programmer–reusability to the extreme.

Reading code written by others–this is something I’m constantly struggling with since I plunged into this magical wonderland. I know my skills have improved since then, because I could glance at a file that was just a pile of numbers and letters back then and see what its creator is trying to achieve. However, not with everything. There are always going to be code beyond my current level of comprehension. My question is, how to understand those code?

Try refactoring them.

What is refactoring? It is to refine the existing code time and again so that it grows increasingly readable, concise, clean, and still does the same job.

I got an interesting example here:

From my experience with refactoring, LinesOfCode isn’t the big issue; clarity is. When I’ve got a complicated logical test embedded in a chunk of code, say

 if (customer.age < 65 and customer.yearlyAmortizationPayout > maxYearlyPayout) ...

I refactor it to something that expresses the intent of the test:

 if (overPaying(customer)) ...

Yes, I’ll have to jump elsewhere to find the definition of overPaying, but I’ve found that my code is easier to read because more of it expresses what it’s meant to do, rather than how it does it. Total code is longer, true, but more comprehensible.

And this discussion is interesting too: What Is Refactoring.

Readability matters. A lot. Sometimes I look at the code I wrote a while ago, and it stares back at me like an alien. So it’s not strange that one would find navigating through open-source code like trying to swim in jelly. The name of methods are alien, the places they’re placed are alien, even underscores and parentheses look alien. If there’re ways to make the same piece of code more readable, do it, and see it grow familiar.

I’m trying this and see how it goes.