Science is about revealing objective truth, for example the orbit of Earth around the Sun or the ultimate interchangeability of matter and energy. Kurt Krebsbach has argued that “computer science”, despite having the word “science” in its name, is not a science. If Krebsbach is right, what is software development, which I define, for the purposes of this post, as the practical application of computer science? I view software development as a form of creative expression, often fun, that sometimes has the side-effect of creating a useful artifact, a piece of software. This post posits that norms and style are important in software development, as in English-prose composition, another form of creative expression.

Norms and Style in English-Prose Composition

The importance of norms and style in creative expression is evident in English-prose composition, which has certain norms and a widely agreed-upon style, documented in The Chicago Manual of Style, The AP Stylebook, The Elements of Style, and elsewhere.

As in software development, wherein, for example, the tabs-versus-spaces debate rages eternally, there are a few disagreements about English-prose composition, for example involving the Oxford comma. The Chicago Manual of Style recommends its use, whereas the AP Stylebook forbids it. But these disagreements pale in comparison to the areas of consensus exemplified below.

One norm of English prose composition is avoidance of non-standard spellings. In a vacuum, I would use the non-standard spellings “nevermind” and “alright”, not the standard spellings “never mind” and “all right”, because of the atomicity, in my mind, of those concepts. I would spell the past-tense forms of “quit” and “commit” as “quat” and “commat”, respectively, by analogy with “sat” and to avoid (with respect to “quit”) the ambiguity of what tense the word “quit” conveys.¹ I am unaware of any English-prose style guides that sanction these non-standard spellings.

Another norm of English-prose composition is to start sentences with a capital letter and end them with punctuation. I do so, and I am unaware of any English-prose style guides that sanction not doing so. I respect this norm notwithstanding the example of poet e e cummings. Here is the last verse of his poem “i carry your heart with me(i carry it in”, reproduced under the doctrine of fair use:

i carry your heart(i carry it in my heart)

Another norm of English-prose composition is to surround dialog sentences with quotation marks and to use apostrophes in contractions. I do so, and I am unaware of any English-prose style guides that sanction not doing so. I respect this norm notwithstanding the example of novelist Cormac McCarthy. Here is an excerpt, reproduced under the doctrine of fair use, from his book The Road:

He screwed down the plastic cap and wiped the bottle off with a rag and hefted it in his hand. Oil for their little slutlamp to light the long gray dusks, the long gray dawns. You can read me a story, the boy said. Cant you, Papa? Yes, he said. I can.

I respect the norms of English-prose composition, at least outside the context of iMessage, where I often write “ur” instead of “your”, because readers are aware of them and expect competent writers not named cummings or McCarthy to follow them. My prose has goals, often including, but not limited to, creative expression, and I have concluded that violating the norms would not help achieve them.

Norms and Style in Software Development

Norms and style play an important rôle in software development as well. Here are two stylistic norms of Swift development, one involving brace placement and the other involving use of implicitly unwrapped optionals (IUOs).

This is the Allman style of brace placement:

if true
{
  // Statements go here.
}

I adopted this style when I was writing C, C++, and Java from the mid-90s to the early aughts. I like this style for two reasons. First, the opening brace serves as a clear visual separator between the control statement and the statements inside its scope. Second, I find the equal indentation of the opening and closing braces esthetically pleasing.

Here is the K&R style of brace placement:

if true {
  // Statements go here.
}

As the reader is likely aware, the K&R style predominates in Swift development, at least for control statements. Indeed, the Ray Wenderlich and LinkedIn Swift style guides recommend it.

But I dislike the K&R style because I find that the opening brace sometimes gets lost, visually speaking, at the end of a long control statement. Moreover, I find the lack of indentation symmetry between the opening and closing braces jarring. Notwithstanding my preference for the Allman style, however, I honor the overwhelming preference of the Swift-development community and use the K&R style in code I write.

Aside from one context, described shortly, IUOs are widely disfavored in the Swift-development community. The following question and answer from Bart Jacobs illustrates this disfavor:

When should you use implicitly unwrapped optionals? The short answer to this question is “Never.”

Nick Griffith expresses a similar sentiment:

Outside of [the exceptions of IBOutlets and interoperating with Objective-C code], we should avoid implicitly unwrapped optionals.

In my experience, Griffith is correct that IBOutlets represent an exception to IUOs’ disfavored status. They are ubiquitous in projects that use Interface Builder, perhaps because Xcode inserts the ! after a control-drag from UI elements in XIBs and storyboards to source files.²

Because of IUOs’ disfavored status, I have, for the past several years, avoided them entirely in side-project code I write, even in cases where I know that a value will never be nil, for example when I initialize a URL using a String that represents a valid URL. Here is an example from Conjugar where I initialize the URL for the app’s rate-and-review screen in the App Store app:

guard let url = URL(string: "https://itunes.apple.com/lookup?id=\(iTunesID)") else {
  fatalError("iTunes URL could not be initialized.")
}

The guard statement is admittedly unnecessary. I have initialized this URL many times, verifying the String’s correctness, and an IUO would be entirely safe to use. But because many code readers disfavor the IUO, I don’t use it.

Importance of Norms and Style in Software Development

Though I have given two examples of the norms and style of Swift development, the mere existence of these norms and a widely agreed-upon style is already well-settled. But are they important? Merriam-Webster defines “important” as “marked by or indicative of significant worth or consequence : valuable in content or relationship”. Like natural language in general, this definition is inherently imprecise. That is, the definition does not allow anything to be described, with a mathematical level of precision, as “important” or “unimportant”. But the Merriam-Webster definition, which I cite here because it accords with my own understanding of the concept of importance, suggests two questions that help answer the ultimate question of whether norms and style are important in Swift development.

First, do Swift developers, as a community, assign significant worth or consequence to norms and style? Second, do Swift developers consider norms and style valuable?

There is evidence that they do. SwiftLint is “[a] tool to enforce Swift style and conventions”. SwiftLint’s GitHub repo has 12,974 stars, 1,449 closed pull requests, and 1,258 closed issues. This level of engagement by the Swift-development community with SwiftLint is evidence that Swift developers assign “significant worth [and] consequence” to “Swift style and conventions”. They would not otherwise engage in such numbers with SwiftLint. Similarly, SwiftFormat, “[a] code library and command-line formatting tool for reformatting Swift code”, has 3,569 stars, 102 closed pull requests, and 380 closed issues.

That Swift developers assign “significant worth [and] consequence” to norms and style and consider them valuable is also evident from the lengthy discussion of SE-0250, “Swift Code Style Guidelines and Formatter”. This thread has 221 replies, which is a lot for Swift Evolution. Roy Hsu’s reply is typical of many commenters.

It’s so important to have a consistent code [style] when cooperating with others on the same project. An official guidelines can solve lots of problems we have to deal with everyday. Besides, I think it will also help beginners to catch up much quicker based on my [teaching] experience in Swift.

Consequences

The importance of norms and style has consequences for how I create software and how I approach that process.

I use SwiftLint in my personal projects and would advocate its use in the work setting. Verily, I feel glee every time SwiftLint catches, for example, an extraneous space or newline in one of my apps.

When I disagree with a coworker about a stylistic matter, I don’t dismiss the disagreement as silly. Rather, I seek to build consensus for one approach, whether that be my own or my coworker’s. I always seek to improve my own personal style, and the coworker’s preference sometimes becomes my own. For example, a coworker suggested to me, several years ago, the following convention for formatting if let and guard let statements with multiple conditions:

if
    let foo = bar,
    answer == 42,
    qux != nil
{
  // Do some stuff.
}

Note that the if keyword has its own line. I concluded that the aggregation of conditions using identical indentation makes those conditions easier to consider as a conceptually related group. This practice has become part of my personal style.

When I dive into a new codebase, the consistent application of a particular style imparts some degree of confidence in the quality of that codebase. Conversely, the fact that PHP symbols only haphazardly use snake case (strpos versus str_rot13) causes me to doubt the soundness of that language.

Caveats

I acknowledge that there are objective truths in computer science. Quick sort is faster than insertion sort for large input sizes. The set-splitting problem is NP-complete.

Creative expression is not the only, or even, sometimes, the most important goal of software development. I do not continue to maintain my app Immigration for the sake of creative expression. That was a primary sake in 2013, when I created the app, but today I maintain the app as a courtesy to immigration practitioners who find the app useful and, secondarily, to cover the cost of my developer account. I created and enhance my app Conjugar not for the sake of creative expression but rather to demonstrate programmatic layout and dependency injection.

Endnotes