Swift allows optional prefixing of method calls and property references to the current object instance via self. Removing these prefixes can declutter code but, depending on the length of the method and number of parameters and local variables, it can also make variable scope ambiguous.
Perhaps the answer is to refactor into smaller classes and methods, but sometimes that isn’t always practical. Common examples are things like UIViewController subclasses and custom viewDidLoad() implementations or complex action handlers for UIGestureRecognizer subclasses. I’ve thought about this a bit since diving into developing an iOS app in Swift but am still on the fence. My ideal answer(s) would touch on:
-
If not referencing
selfhas an practical downsides. -
Whether mixing implicit and explicit references to
selfis worse that sticking to one or the other (I’m leaning towards yes). -
Overall stylistic concerns with a focus on readability.
-
Instance variable naming styles versus local variable naming styles to mitigate ambiguity.
-
References to similar issues in other languages.
I believe this is nothing but a matter of style – no “measure of readability” (which is always personal) can help you here.
So before I go any further, let me say this: Whatever the style choice, if you’re working in a team, define a clear standard that the whole team must comply with, because if there is one thing that everyone can agree on that makes code less readable, is having to keep up with different style choices as you read it.
But now to the main subject: self, this or me, as present in many OO languages, are featured roughly for the following reasons:
- Being able to pass an instance of the current object to others;
- Accessing special properties that are otherwise unavailable, such as reflective property
this.classin Java; - To allow otherwise conflicting names to be used in local scopes.
As with many other details that are abstracted away from us when we use OO languages (vtables, etc…), self could also be hidden, if it weren’t for the reasons above.
So my opinion is that you should only use it when necessary, as above.
Of course, this idea only works well along with the practice of making small classes and methods; otherwise, both your local and global scopes are going to be so big that it will always be confusing, forcing the reader to jump up and down in the code, looking for the definitions. But I’m tempted to say, in these cases, that it is not the consistency of style that is going to save you.
2
Specifically in the case of Swift, I believe there are a few benefits to leaving out self unless explicitly required by the compiler:
-
Using
selfonly where required (i.e. in closures where self is captured) makes it much easier to spot situations where references to self may be improperly retained. -
I ran into an interesting issue where the use of self appears to prevent warning messages from being shown:
class MyObject {
var myRange: Range‹Int›? {
willSet {
// This line has a warning that you are operating on a property that is about to change
myRange?.startIndex = 2
// This line does not show any warning
self.myRange?.endIndex = 3
}
}
}
You might argue that this is a bug, but I think it’s important that self changes the way some expressions are treated, if only for warnings.
1
Not using self will make you think twice any time you use a variable. IMHO writing clean code is a matter of style. The style in Objective-C is to use self with properties. Since the vast majority of Swift programmers come from Obj-C, this style should be kept.
2