Software artist. Writer aficionado. Open source enthusiast.
Runner. Father of two.
Currently: Senior Software Engineer at Google,
New York City.
That’s it! After two months worth of posts, it is time to part with the the readability series. We have covered a lot of ground with these 14 posts: from mundane things such as blank lines and spelling to deeper topics involving dictionaries and global state. Before some parting words, here comes the full list of posts on this series. This is your time to catch up with any posts you have not yet read!
Try/catch blocks (or try/except, or whatever they happen to be named in your favorite language) are the mechanism by which you capture exceptions raised by a chunk of code in a controlled manner. Within that chunk of code, it does not matter which line throws the exception: any exception specified in the catch statement will be captured, and it is “impossible” to know at that point where it originated. Consider this piece of code:
Over a year ago, I developed two command line utilities for NetBSD (sysbuild and sysupgrade) and a supporting library for the two tools (shtk). These were all introduced in their corresponding blog posts —Introducing sysbuild for NetBSD, Introducing sysupgrade for NetBSD and Introducing shtk— and since then I have heard good comments about them. About a couple of weeks ago, I started working on the much-needed rewrite of pkg_comp and a supporting standalone tool.
Single assignment says that a variable should only be assigned a value once; i.e. a variable should only be initialized and never modified later. This could be said to be a property of functional programming—never mind that it’s used in compiler optimization a damn lot—so it may sound a bit out of scope in a readability post. Not really. When you force yourself to avoid modifying already-defined variables, you will need to find other ways to express your intent.
Conceptually, there are two kinds of conditional statements: ones that compute—or affect the computation of—a value and others that guard the execution of optional code (e.g. functionality enabled by a command-line flag). In this article we will focus on the former kind. One way to think of those conditionals is as if they were to represent functions, just written inline. In other words: while it should be possible to move the conditional statement to a separate function, it has not been done because the algorithm is simple enough to not warrant it.
In the most basic form, a conditional has two branches and the conditional expression inspects a single variable on entry. For example: if balance >= 0: color = BLACK else: color = RED In this little code snippet, the condition balance >= 0 only depends on one variable, and the two branches of the conditional cover all possible values of the input variable. I.e. the first branch covers all cases where the balance is positive or zero, and the second branch covers all cases where the balance is negative.
A few months ago I bought an old PowerMac G5 off of Craigslist and since then I have been experimenting with various operating systems and configurations. Before I tell you more about these, let me briefly explain why I got such a machine. I had always wanted one of these beasts. They look gorgeous (to me) and, to convince myself to get it, I thought that I would play with the PPC64 architecture.