Me, my future self and self

A colleague of mine complained, that I use self too much. In Objective-C, it was everywhere, but he sent me this blogpost and recommended me to use self in Swift sparingly and only when necessary for the compiler.

But back in 2012 I started to learn Objective-C. Until 2015 it was more or less a hobby, but in 2016, I moved to Berlin to start a job as an iOS developer. Pretty soon, I switched to Swift. Since June 2018 I've been part of the team, who develops the Lidl-app for iOS.

Earlier this day I fixed a bug and created a Pull Request. I had a discussion about self with the colleague. His argument was, that it's totally sufficient to use self only in those places, where the compiler really needs it. The consequence, according to him, is to have cleaner code. And so he made me think and I felt the urge to justify myself and self.

I strongly disagree with using self only in certain spots to make the compiler happy. It's much more important to use it, when it makes a developer's job easier. I'm not a fan of making the compiler happy in the first place. Making (future) developers happy is much more important to me.

And by "making happy" I mean writing code, that's easy to understand and easy to maintain for colleagues and my future self. And this includes being as explicit as possible. When I look at a piece of code, I don't want to spend a lot of time to understand the code, I want to understand the problem it solves and how.

self everywhere might add some kind of visual noise, but it also adds clarity. You get used to that visual noise. The aforementioned blogpost argues, that not using self helps you finding memory leaks in closures. I don't think, that this is an issue of having/not having self everywhere in the first place, but more of an issue of paying attention.

Just because you can write very short Swift-code doesn't mean that you should. Closures are another good example for this:

You can reduce the amount of code in a closure dramatically by using $0, removing return, not using the parameter-name and so on. At the same time you reduce the readability of this code even further and in the end, only the person who wrote this code knows what this closure actually does. But this person left the company two months ago, so yeah. But that's another issue.

One of my goals is to write maintainable code and not to make a compiler happy on the expense of this goal. A compiler doesn't need self, sure, but it will make my job easier, starting tomorrow.

I hope, that this explains, why me and my future self — pun intended — are fans of self. My (future) colleagues will be, too. Hopefully :-)