drawing of a carrier bag
The still life medium developed from a Dutch mercantile tradition of displaying goods in an idealised manner. Therefore, drawing the ephemera of modern life in the same way is subversively rewarding, in a gentle way. The green plastic ex-mushroom container inside the bag shines through nicely.

As Paul Hudson explains, Swift function parameters have external and internal names, the external coming first. Any functions utilising two or more parameters must reference all parameters after the first by their names, the external name if one provided, the internal name if not. So the following functions:

Would be called like this:

The fact that the first parameter does not need to be named is a hangover from Objective-C, which is a euphemistic way of saying: suboptimal. Obviously, Apple would like to attract Objective-C programmers over to Swift, and so they provide such similarities to Objective-C to ease the transition. However, those of us coming to Swift directly - like me - do not approve of these inconsistencies. Clarity is an essential element of "swiftiness," and therefore, if one is passing a parameter to a function, one should be made to state and therefore know what that parameter is:

Both external and internal parameter names are given lowercase names, so that there isn't a weird and ugly inconsistency of function names starting with a lowercase letter, but parameter names starting with an uppercase one.

But, when we start applying this style to certain types of function - the "do-something-by-something" type - this starts to look weird and ugly in a different way:

"Height" is unnecessarily repeated. This is better:

Essentially, part of the function name appears inside the brackets. It may seem counterintuitive, but it's actually an elegant way around the inconsistency brought across from Objective-C. It works well for setters too:

Once you're used to function names like this, you can take this further, and use them everywhere. For instance, here's an actual function in one of my projects:

This does not currently form part of Ray Wenderlich's otherwise excellent Swift Style Guide, but I'm sure only because it hasn't occurred to anyone on their team yet. I hope they include it at a later date.


The release of Swift 3.0 has seen many changes similar to that made to NSDictionary's objectForKey function:

Following my comment about Ray Wenderlich's style guide immediately above - and given that I initially wrote this blog post in February of 2016 - I feel wholly vindicated in my belief that split function names are best practice.

Getter and setters - less commonly known as mutator methods - are as essential a part of Swift as they are of any modern language. But I find the verbs chosen to label them either inconsistent, or inaccurate, or both. "Set" is obviously chosen as it rhymes with "get," which is sensible enough, except that "get" itself isn't ideal in the first place. "Getting" something suggests the object is close at hand. Within the confines of an app, "getting" makes sense, but stepping beyond that seems inappropriate. Instead, I would suggest that the following makes sense, for different contexts:

Getting and setting locally remains fine. When deleting properties locally, they are almost always set to null, so annul is more accurate than delete. Likewise add and remove are sensible when referencing collections, and like get, gather starts with a "g," and implies retrieving multiple items. retrieve and store are reminiscent of household chores, and one's device is one's digital home, and delete suggests that it's gone, but not forever, assuming the data exists elsewhere. fetch and save are appropriate for data stored in databases as they suggest a certain distance to the data, and destroy really does underline that once a property stored in a database is deleted, it is gone forever. resolve underlines that when querying an API etc., one can never really know what one is going to get back: useful data; a successful flag; a network error. It's just impossible to know. So call an API via a function named something like resolve( Username ), and send the callback to a function named something like onUsernameResolved, where it's payload can be assessed.

I imagine there will be readers who find this pedantic, or some other flavour of pointless, phrases like GET are already enshrined in, say, query language traditions, so why change something that isn't broken? Two reasons:

  1. Tradition is bullshit. It was once traditional to pour one's faeces out of the window, but once we learned that was suboptimal, we stopped it; and
  2. when one starts a function with one of these verbs, because they are all different it shows the programmer immediately what manipulation that function is going to perform: it will get, set, or delete data - sure - but it is also clear where and how the manipulation will take place. The expressive strength of each verb increases with increasingly serious actions:

And if the style of the three functions listed immediately above seems strange to you, please see my post on splitting function names.