Swift-style-guide: Using self

I agree, and I also agree it will be a bit hard at the beginning :)

I agree with both of those agreements.

So, down with self unless the compiler whines about it!

Sent from my iPhone

On Jun 10, 2014, at 5:48 AM, Cesare [email protected] wrote:

I agree, and I also agree it will be a bit hard at the beginning :)

—
Reply to this email directly or view it on GitHub.

What bothers me about ditching self is that there's no easy way to
immediately know whether a var is instance var or a local one.

Don't u guys agree?

On Tuesday, June 10, 2014, elephantronic [email protected] wrote:

I agree with both of those agreements.

So, down with self unless the compiler whines about it!

Sent from my iPhone

On Jun 10, 2014, at 5:48 AM, Cesare <[email protected]

I agree, and I also agree it will be a bit hard at the beginning :)

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment-45607945
.

What bothers me about ditching self is that there's no easy way to
immediately know whether a var is instance var or a local one.

Many editors that I have used highlight the two differently. Hopefully Xcode will follow with this feature.

I'd only use self to disambiguate.

Isn't the guide targeting our books and tutorials? I still think using self
is more readable (but i know apple aren't using it so we will in the end
not use it either)...

On Tuesday, June 10, 2014, ColinEberhardt [email protected] wrote:

What bothers me about ditching self is that there's no easy way to
immediately know whether a var is instance var or a local one.

Many editors that I have used highlight the two differently. Hopefully
Xcode will follow with this feature.

I'd only use self to disambiguate.

—
Reply to this email directly or view it on GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment-45625271
.

Agreed that we should ditch self

Apple doesn't use it, so I don't think we should either. I'm not really happy with that decision on Apple's side, but I do think we should follow their conventions.

I know I said down with self, and I think I still think that, but I just looked at the code in the Swift Sprite Kit game template. It's GameViewController uses self.view and self.classForKeyedUnarchiver. So that's an example of a property and a standard method, both using self.

In the same class, I also found two instances of var that compiled fine as let. Hopefully their templates just aren't ready for prime time, but it does give me pause. I'd like to see how some of these things progress across the betas.

I wouldn't put too much faith in Apple's templates or sample code. It's usually not the best example of how to do things... That same template also ends lines with a semicolon, for example. :-)

Good point. We should probably add semicolons everywhere, too. ;)

--------- Original Message --------- Subject: Re: [swift-style-guide] Using self (#7)
From: "Matthijs Hollemans" [email protected]
Date: 6/11/14 3:19 am
To: "raywenderlich/swift-style-guide" [email protected]
Cc: "elephantronic" [email protected]

I wouldn't put too much faith in Apple's templates or sample code. It's usually not the best example of how to do things... That same template also ends lines with a semicolon, for example. :-)
-
Reply to this email directly or view it on GitHub.

I believe self makes code much more clear. It makes it very easy to know whether it's a property or instance variable. Same reason I vote to always use self in objc for properties rather than using their instance variable _propertyName.

self definitely makes it more clear while reading a code snippet. The real question is whether or not that extra clarity is worth it.

If you type code that compiles, it compiles. Swift doesn't let you compile code that implicitly hides another variable/func from a different scope, so we don't need to say self because if the method is the only one in scope, it will compile. If it is on another object _and_ this object, it will fail to compile until you specify which one you want (by using self, if necessary)

Obj-C is the only language I've ever seen that asks people to specify that they own what they clearly own, so it's nice that Swift has done away with it.

If you are writing a method, it shouldn't be hard to see which variables are local to that method. Outside of that method, scope only matters to the compiler.

--------- Original Message --------- Subject: Re: [swift-style-guide] Using self (#7)
From: "ecerney" [email protected]
Date: 6/12/14 1:17 pm
To: "raywenderlich/swift-style-guide" [email protected]
Cc: "elephantronic" [email protected]

I believe self makes code much more clear. It makes it very easy to know whether it's a property or instance variable. Same reason I vote to always use self in objc for properties rather than using their instance variable _propertyName.
-
Reply to this email directly or view it on GitHub.

I keep not agreeing with this thread.

This style is supposed to be for the tutorial and book authors not a
general style guide about Swift.

In the context of books and tuts where you can be adding few lines of code
from a method at a time I do think it's crucial to use self to make sure
the reader knows the context of the variable.

On Thursday, June 12, 2014, elephantronic [email protected] wrote:

self definitely makes it more clear while reading a code snippet. The real
question is whether or not that extra clarity is worth it.

If you type code that compiles, it compiles. Swift doesn't let you compile
code that implicitly hides another variable/func from a different scope, so
we don't need to say self because if the method is the only one in scope,
it will compile. If it is on another object _and_ this object, it will fail
to compile until you specify which one you want (by using self, if
necessary)

Obj-C is the only language I've ever seen that asks people to specify that
they own what they clearly own, so it's nice that Swift has done away with
it.

If you are writing a method, it shouldn't be hard to see which variables
are local to that method. Outside of that method, scope only matters to the
compiler.

--------- Original Message --------- Subject: Re: [swift-style-guide]
Using self (#7)
From: "ecerney" <[email protected]
Date: 6/12/14 1:17 pm
To: "raywenderlich/swift-style-guide" <
[email protected]
Cc: "elephantronic" <[email protected]

I believe self makes code much more clear. It makes it very easy to know
whether it's a property or instance variable. Same reason I vote to always
use self in objc for properties rather than using their instance variable

_propertyName.

Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment-45927747
.

I've written a pretty popular Unity tutorial. It uses C# and no selfs. I haven't heard complaints that people didn't understand where the variables were coming from.

--------- Original Message --------- Subject: Re: [swift-style-guide] Using self (#7)
From: "Marin Todorov" [email protected]
Date: 6/12/14 2:16 pm
To: "raywenderlich/swift-style-guide" [email protected]
Cc: "elephantronic" [email protected]

I keep not agreeing with this thread.

This style is supposed to be for the tutorial and book authors not a
general style guide about Swift.

In the context of books and tuts where you can be adding few lines of code
from a method at a time I do think it's crucial to use self to make sure
the reader knows the context of the variable.

On Thursday, June 12, 2014, elephantronic [email protected] wrote:

self definitely makes it more clear while reading a code snippet. The real
question is whether or not that extra clarity is worth it.

If you type code that compiles, it compiles. Swift doesn't let you compile
code that implicitly hides another variable/func from a different scope, so
we don't need to say self because if the method is the only one in scope,
it will compile. If it is on another object _and_ this object, it will fail
to compile until you specify which one you want (by using self, if
necessary)

Obj-C is the only language I've ever seen that asks people to specify that
they own what they clearly own, so it's nice that Swift has done away with
it.

If you are writing a method, it shouldn't be hard to see which variables
are local to that method. Outside of that method, scope only matters to the
compiler.

--------- Original Message --------- Subject: Re: [swift-style-guide]
Using self (#7)
From: "ecerney" <[email protected]
Date: 6/12/14 1:17 pm
To: "raywenderlich/swift-style-guide" <
[email protected]
Cc: "elephantronic" <[email protected]

I believe self makes code much more clear. It makes it very easy to know
whether it's a property or instance variable. Same reason I vote to always
use self in objc for properties rather than using their instance variable

_propertyName.

Reply to this email directly or view it on GitHub.

• 
  Reply to this email directly or view it on GitHub
  https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment-45927747
  .
  -
  Reply to this email directly or view it on GitHub.

The argument "it compiles then it's ok" is weak. I think we should find our style and stick to it. It's not a secret that I favor readability over a few more keys to type when it comes to tutorials. I vote for using self.

Yes !!! Cesare is on readability side! We can do it!

4 more years! 4 more years!

I mean - using self for class variables!

On Thursday, June 12, 2014, Cesare [email protected] wrote:

The argument "it compiles then it's ok" is weak. I think we should find
our style and stick to it. It's not a secret that I favor readability over
a few more keys to type when it comes to tutorials. I vote for using self.

—
Reply to this email directly or view it on GitHub
https://github.com/raywenderlich/swift-style-guide/issues/7#issuecomment-45931720
.

Ok, how about this argument?

The forced use of self is one of the things Apple removed when creating Swift because they saw how stupid it is and noticed every other language in the world doesn't need it and everyone seems to be ok with those, right? If Apple wanted to, they easily could have included self as a mandatory part of the language. They chose not to for the very good reason that it is completely unnecessary, and writing unnecessary extras in code generally makes things less readable in the long run.

Obj-C was a language built on top of another language. Things like self were used to aid the bracket syntax to indicate an Obj-C function versus a C function. The compiler didn't understand true classes and such, so they had to build special syntax to trick it.

It is no longer necessary, and holding onto it isn't going to help you or our readers. It will actually make things more difficult when you try to read other people's code because you will be so conditioned to seeing self that you won't interpret things correctly when you don't see it.

Let go of the shackles of the past and embrace the future. You'll feel better.

--------- Original Message --------- Subject: Re: [swift-style-guide] Using self (#7)
From: "Cesare" [email protected]
Date: 6/12/14 2:44 pm
To: "raywenderlich/swift-style-guide" [email protected]
Cc: "elephantronic" [email protected]

The argument "it compiles then it's ok" is weak. I think we should find our style and stick to it. It's not a secret that I favor readability over a few more keys to type when it comes to tutorials. I vote for using self.
-
Reply to this email directly or view it on GitHub.

I see your point @elephantronic and I might agree with you but in 1-2 years. The only reason I propose to use self is that it's hard to me (and I suspect to many other people) to completely forget about the past. If you are an Objc dev you are used to self, if you are not you will NEED to be able to read (if not write) Objc code. Either way, self pops up. So I vote for using self "at the moment" and I propose to review this issue in a year or so when everybody is more acquainted with the language.

I vote for not using self. I agree with @funkyboy that it is hard at the beginning. But I am also thinking why would I use the same name for both instance var and local var, and then try to resolve the ambiguity? My understanding from what @hollance has mentioned (self.propertyName) is not about resolving the ambiguity or readability; it is about the habit we have from ObjC and apparently it is not necessary anymore in Swift. I see self in Swift as the last resort: i.e. the compiler complains.

Does it make sense to put this one to a vote? I think there have been some well thought-out arguments from each side.

I'm a +1 for not using self where it isn't required.

I'm also a +1 for not using self when not required. While I understand Martin's concerns, I also do a fair bit of Android development, and I _very_ rarely see a this in code, although occasionally it's broken out in order to make something more clear or resolve a conflict, it's a lot more obvious than you'd think when you're using a "property" vs a local variable.

I saw Go when I first looked at Swift, but the longer and harder I look, the more Java I see.

+1 selfless

Fair enough I accept the democratic verdict :)
Let me point out an inconsistency. By not using self I might deduct that one of the principles that the guideline is based on is "don't write it if not needed". I might not like it but as long as it's consistent throughout the guideline I accept it. I still think it impacts negatively on the readability.
The same principle goes along with our decision on type inference, don't write the type "because it's not needed".
If we apply the same principle to initializers then we should suppress external names for initializers. Guess why? Because "they are not needed". If we "go minimal" let's do it, but totally.

We agreed to not write the type because it is not needed.

We agreed to use Swift's defaults on param names, because it's the default and it doesn't make sense to go out of the way to do something different from what Swift wants you to do in those cases. To eliminate the param names, you have to write _extra_ code and then explain it.

--------- Original Message --------- Subject: Re: [swift-style-guide] Using self (#7)
From: "Cesare" [email protected]
Date: 6/12/14 6:30 pm
To: "raywenderlich/swift-style-guide" [email protected]
Cc: "elephantronic" [email protected]

Fair enough I accept the democratic verdict :)
Let me point out an inconsistency. By not using self I might deduct that one of the principles that the guideline is based on is "don't write it if not needed". I might not like it but as long as it's consistent throughout the guideline I accept it. I still think it impacts negatively on the readability.
The same principle goes along with our decision on type inference, don't write the type "because it's not needed".
If we apply the same principle to initializers then we should suppress external names for initializers. Guess why? Because "they are not needed". If we "go minimal" let's do it, but totally.
-
Reply to this email directly or view it on GitHub.

self is just noise in Swift, kill it. We'll adapt.

Hi, sorry to reanimate the dead thread.

I'd like to know how are you guys now feeling after ditching self? Are you okay now? Were there any particular readability problems?

I've ditched it and never looked back. :)

The raywenderlich.com books and tutorials have been selfless for 4 years now and nobody has had any specific complaints.