I’ve been struggling to come up with a coherent response ever since I read Radek’s article on naming methods in Swift. While he makes a number of good points, I keep coming back to a deep-seated anxiety about moving toward shorter, less descriptive method names in Swift. The crux of my discomfort comes from this section of his post (emphasis mine):
Code is not made equal. It would be a mistake to apply the same naming convention to everything. Some methods are generic and broadly used. Some are rare or domain-specific.
Consider these functions and methods: map, reduce, stride, splice. These are very short and easy to remember. They’re not exactly self-explanatory, but that’s okay, because they are standard library methods that you’re going to use many, many times so the benefit of a short name is greater than the price of having to learn it first.
On the other side of the spectrum, there’s your application code. You probably don’t want to give methods in your view controllers obscure single-word names. After all, they’re probably going to get called once or twice in your entire codebase, they’re very specific for the job, and once you start working on another class, you’ll totally forget what the thing was.
I hope you see where I’m going with this. If you’re writing library/framework-like code, or some base class that’s going to be used throughout the app, it’s okay to use short and sweet names. But the more application-specific it is, the more you want clearer, more descriptive, intention-revealing methods.
I don’t think this logic pays enough attention to the fact that someone else will very likely be working with your code after you write it. Even if you’re a single developer, you might eventually pass that code off to someone else – maybe because you got a new job, or added a partner, or sold your app to another developer. Best practices are important because they help us make our code accessible to the next person who works on it.
I also think developers should take care to make a language accessible to people who are new to it. That’s especially true right now with Swift – we’re all new to it! Keeping the language accessible might mean trading off some conciseness in favor of descriptiveness. Consider the examples above of concise standard library methods: map, reduce, stride, etc. You have to learn what they do before you use them. That’s a barrier that you have to overcome before you can start working in the language. The more of those there are, the higher the barrier becomes. As a developer community, we’re best off keeping those barriers as low as possible.
Radek rightly points out that there’s a spectrum, and the more narrowly tailored your use case is, the more appropriate a concise method name might be. But I disagree with the idea that short method names are appropriate in a base class used across your app, or even in framework code. Even methods that get used all the time should be readable. Doing so reduces the amount of time that a new developer has to spend digging through your source code in order to figure out what’s going on. (I shudder to imagine all the command-clicking to figure out what things like funnel or fetch or grab might do.)
I propose that the only real place where very short, concise names make sense is in the language itself. Essentially, this refers to things like map that are already built into Swift. We’ve got autocomplete to help us with the rest, and Swift already reduces some of the extra typing from Objective-C.
Why does this all matter, and why have I been ruminating on it for the past couple of weeks? Because Swift is new, we have a unique opportunity to shape its conventions. I’ve done some Ruby programming in the past, and although it’s a nice language, I don’t want to develop iOS apps in it. I think the iOS and Mac developer communities will do themselves a favor by sticking to longer, more descriptive method names in all but the rarest of circumstances.