Software engineer. Human. From Brooklyn NY.


Choosing Expressiveness

During a recent pair-programming session, I peeked over my partner's shoulder to see something like the following code snippet:

func doStuff() {
    if !flag {

Somewhat jokingly, I suggested using guard...else instead. My partner responded with a giant eye-roll that all but said, “Dude, seriously? We have much more important things to worry about right now.” And on we went with our business.

And truth be told, we were in the middle of a debugging session during which trivial syntax and stylistic choices were not even close to the biggest concerns on our list. But for some reason that little interaction stuck with me over the last few days, and it begged the question, "What is the right way to use a guard statement?" And by "right" way, I mean the more expressive choice that is easier to understand at a glance. Turns out well-respected developers in the community have been pondering what it means to write expressive Swift. With respect to my case-in-point, developer Radek published a neat little treatise on the use of the guard statement in which he makes solid arguments for various use cases in which guard is - and is not - appropriate. Specifically:

When you have a trivial method that only contains a single, simple if..else expression, don’t use guard.

He elaborates: "For such simple cases, it’s much easier to understand and conceptualize a two-branch if..else expression rather than the flattened version — despite otherwise being a good candidate for a guard." Radek makes a good point here regarding the overall readability of using guard - it should not be necessarily taken as a one-size-fits-all way to handle an early exit.

This got me thinking about the topic of expressiveness in our code in general. A quote I came across recently came to mind:

The goal in writing code should not be to reduce the # of lines but to reduce the time needed to read it

An effective engineer prioritizes her work based on how much leverage is gained from any particular activity. But being an effective engineer is also about building leverage into the codebase - making our code testable, reusable and readily changeable. To which end, our code should easily be navigable. In order to write clean code that’s helpful to others and to ourselves, we should try to make our code expressive enough to easily navigate, both logically and at-a-glance. Earlier in my career, I used to take the concept of code style for granted until one of my mentors gently, half-jokingly (😜!) one day said he had to squint to make his way through my code due to my very sparse use of indentation and empty lines. I'd like to say my code style has improved a lot since then, but I've since been continously on the lookout for good examples and resources on the subject.


Some engineers use the classic tome on literary composition, Elements of Styleas an inspiration to writing expressive code. This makes perfect sense - writing code is still writing, after all. There are definitely things we can learn from the art of literary writing - putting words on a page - that we can transfer to the art of writing software - putting words into a text editor. Related lines of code can be thought of as paragraphs that encapsulate a certain theme, and effective use of negative space and indentation help guide the reader’s eye and make the material more approachable and visually pleasing. These ideas are translated into a set of principles readily-applicable to the domain of writing software called the Elements of Programming Style (which I just added to my Amazon reading-list, naturally!).

SWift Style

As far as language-specific conventions go, well - Swift, being still such a young language, is still in the process of figuring out what its conventions will be. But some patterns are starting to emerge as best- or recommended practices. Turns out the ever-prolific Erica Sadun has been spending some time exploring style within the Swift community and is compiling a forthcoming volume, titled Swift Style, due in the next couple of months. One of the reasons I enjoy Erica's writing is her emphasis on discussing the expressiveness of different patterns and writing readable code that doesn't get in the way of the reader's understanding. Highly looking forward to reading her newest book and will circle back once I've spent a little time with it.