Should instance variable have an underscore prefix?

[kodecocodes]

Should instance variable have an underscore prefix?

I would say not. Things will look really messy if local variables aren't prefixed but instance variables are.

Sent from my iPhone

On 7 Nov 2013, at 17:41, ColinEberhardt [email protected] wrote:

The guide states the following:

(https://github.com/raywenderlich/objective-c-style-guide#underscores)

When using properties, instance variables should always be accessed and mutated using self.. This means that all properties will be visually distinct, as they will all be prefaced with self.. Local variables should not contain underscores.

What about instance variables that do not 'back' properties? should they have a leading underscore?

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

[ColinEberhardt]

I guess this is a bit of a moot point as the guide elsewhere states:

Property definitions should be used in place of naked instance variables whenever possible.

[ricardo-rendoncepeda]

I usually prefix non-property ivars with an underscore. I actually think this makes an easy distinction between local variables, properties, and non-property ivars.

As for the follow-up, I agree with the guide statement but sometimes think it's overkill to have a property for a simple int counter or bool flag.

[ColinEberhardt]

@ricardo-rendoncepeda - I agree on both counts.

I underscore prefix all instance variables (for consistency and simplicity - i.e. the same rule for all instance variables).

I also only add a property for an instance variable when I want to 'elevate' it to the public API.

The only time I've used instance variables in the past 18 months is when I've been editing a tutorial or chapter that's used them.

I use properties religiously. Either publicly, or privately in class extensions, in place of instance variables.

Sent from my iPhone

On 7 Nov 2013, at 17:52, ColinEberhardt [email protected] wrote:

@ricardo-rendoncepeda - I agree on both counts.

I underscore prefix all instance variables (for consistency and simplicity - i.e. the same rule for all instance variables).

I also only add a property for an instance variable when I want to 'elevate' it to the public API.

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

[hollance]

Definitely with underscore.

[funkyboy]

I am on the same page.
Properties whenever possible, even for BOOLs.

Cesare Rocchi
studiomagnolia.com

On Nov 7, 2013, at 6:57 PM, Mic Pringle [email protected] wrote:

The only time I've used instance variables in the past 18 months is when I've been editing a tutorial or chapter that's used them.

I use properties religiously. Either publicly, or privately in class extensions, in place of instance variables.

Sent from my iPhone

On 7 Nov 2013, at 17:52, ColinEberhardt [email protected] wrote:

@ricardo-rendoncepeda - I agree on both counts.

I underscore prefix all instance variables (for consistency and simplicity - i.e. the same rule for all instance variables).

I also only add a property for an instance variable when I want to 'elevate' it to the public API.

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

[funkyboy]

Always with underscore :)

On Nov 7, 2013, at 7:08 PM, Matthijs Hollemans [email protected] wrote:

Definitely with underscore.

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

[ColinEberhardt]

@funkyboy @micpringle - out of interest, why use private properties in place of instance variables? (I am not saying you are wrong, just interested!)

I always use underscores for instance variables and rather than make things "messy," I think it makes it easier to know when I'm dealing with a local variable versus an instance variable.

I'm fine with saying to always use properties in private extensions, but in real life, I tend to only use properties when they are public or there is something special about the variable that I don't want to deal with, like if it uses copy semantics or some such. But I suppose if you love accessing variables via self.variable instead of _variable, you will want properties in all cases.

[ColinEberhardt]

Hmm... this could be a tricky one, sounds like we are split 50/50 between instance variable vs. always using properties.

There are many reasons, but the two that spring to mind are the contract (assign, copy, strong etc) and that properties are observable.

Sent from my iPhone

On 7 Nov 2013, at 18:20, ColinEberhardt [email protected] wrote:

@funkyboy @micpringle - out of interest, why use private properties in place of instance variables? (I am not saying you are wrong, just interested!)

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

[ColinEberhardt]

Those are fair points, but when I need those features I use properties. When I don't, I use instance variables!

Yeah, Colin. That's why I said I was fine with saying we should always use properties, but knowing that I probably won't ever completely comply with that. Again, this is only talking about the case of private data, right? Because in the public interface, I would never use an instance variable directly.

[gregheo]

I still use plain ivars a lot for convenience and because I'm used to them.

But for a tutorial site, I feel like we should be consistent. And if we have to pick one, we should go with properties. Public properties in the .h and "private" properties in the class continuation.

[hollance]

I think saying you should always use properties exceeds the "jurisdiction" of coding style guidelines. There is no right or wrong answer there. A coding styleguide should have advice to prevent bad coding practices, not to enforce one good practice over another.

That's not my understanding. I thought this was being set out for consistency across all articles and chapters, and therefore should be adhered to by all authors and editors.

Sent from my iPhone

On 7 Nov 2013, at 18:34, Matthijs Hollemans [email protected] wrote:

I think saying you should always use properties exceeds the "jurisdiction" of coding style guidelines. There is no right or wrong answer there. A coding styleguide should have advice to prevent bad coding practices, not to enforce one good practice over another.

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

I'll see you all in hell before I indent with 4 spaces. In hell, I say!

[ColinEberhardt]

@elephantronic - that's the spirit!

anyhow, back to the debate, @micpringle is right, the coding style goes beyond preventing bad coding practice, it is about consistency. Otherwise it wouldn't include details such as indentation settings, and where to place opening braces.

I'd prefer consistency over my own personal preferences.

[funkyboy]

Mostly because I am used to that and because properties are observable.
I used to use ivars for private stuff and properties for public.
I feel it's easier to type self. instead of _
The only down side is refactoring: when you rename a property, the _ counterparts in the init methods (you use them right? :) are not renamed, and that's a grrrrr moment.

On Nov 7, 2013, at 7:20 PM, ColinEberhardt [email protected] wrote:

@funkyboy @micpringle - out of interest, why use private properties in place of instance variables? (I am not saying you are wrong, just interested!)

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

Well, I'd prefer we are consistent with my own personal preferences, but that's just me. :D

Something else to bare in mind is that once this is "set in stone" it will (as far as I'm aware) be enforced by the editing team. Therefore anyone taking a lackadaisical approach to the guidelines will see it reflected in their tutorial/chapter score and feedback.

Sent from my iPhone

On 7 Nov 2013, at 18:59, ColinEberhardt [email protected] wrote:

@elephantronic - that's the spirit!

anyhow, back to the debate, @micpringle is right, the coding style goes beyond bad coding practice, it is about consistency. Otherwise it wouldn't include details such as indentation settings, and where to place opening braces.

I'd prefer consistency over my own personal preferences.

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

Hmm. Is that true, micpringle? Because as a tech editor myself, I would not reduce someone's score if they used a readable, consistent style, whether or not it followed a guideline we set here. And like we said, we'll be running a lot of this through a tool to enforce a certain style, so it wouldn't make sense to complain to the users about some things anyway.

Now, in the case of the property v. ivars, a tool won't be changing those, so we should decide on something consistent. And I think we have all agreed that the easiest way to be consistent is to recumbent properties. I just don't think it's necessarily the "best" way to code.

For me, you accept the overhead of using a property (and there is overhead, however minimal) as a trade off for a benefit the property gives you. But in the case of private properties, these benefits come into play less often, so I only use them when I need them.

As far as I'm aware, it is. If a guideline is set out and agreed, then if I have to spend a lot time editing code to match the guidelines, any score I give will take that into account, just as with anything else on the tutorial writing guidelines.

I first championed a coding guidelines doc with Ray to make the lives of editors easier, and to provide a more consistent experience for the reader. If it's not adhered to, or enforced, then there's zero benefit, so one would have to ask as to what's the point.

Sent from my iPhone

On 7 Nov 2013, at 19:12, elephantronic [email protected] wrote:

Hmm. Is that true, micpringle? Because as a tech editor myself, I would not reduce someone's score if they used a readable, consistent style, whether or not it followed a guideline we set here. And like we said, we'll be running a lot of this through a tool to enforce a certain style, so it wouldn't make sense to complain to the users about some things anyway.

Now, in the case of the property v. ivars, a tool won't be changing those, so we should decide on something consistent. And I think we have all agreed that the easiest way to be consistent is to recumbent properties. I just don't think it's necessarily the "best" way to code.

For me, you accept the overhead of using a property (and there is overhead, however minimal) as a trade off for a benefit the property gives you. But in the case of private properties, these benefits come into play less often, so I only use them when I need them.

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

[hollance]

There are two things that the style guide covers:

1. Formatting issues
2. Best practices

I'm OK with any formatting rules (2 vs 4 spaces vs tabs whatever) as long as they are reasonable. And if we use a tool to pretty print the code then this is a complete non-issue. We just have to make decisions, which is a matter of weighing limitations of the medium (web, books) versus general readability.

As far as best practices go, there are things that are obviously good practice, things that are obviously bad practice, and things that can be debated until the cows come home. Instance variables vs properties goes in the latter category. Trying to enforce a rule on that is going to do no one any good. (I'd never follow a rule on that anyway. If you want to know my personal preference: I always do the simplest thing possible. Instance variables are simpler than properties.)

So I think we should focus on the things we see done over and over that are bad practice and put those in the styleguide with some examples on how to do it better. And for issues that split our opinions 50/50 we should make a note in the document that both are acceptable practices.

[ricardo-rendoncepeda]

@hollance I agree with your last statement, specially on adding a note that validates both methods. Now we just need to decide which one actually goes into the guideline!

A large chunk of any style guide will represent visual style, most of which would fall into 'until the cows come home' category. By recommending any way for each suggested way is fine, for each area, kind of defeats the whole point of having a style guide in the first place.

Sent from my iPhone

On 7 Nov 2013, at 19:28, Matthijs Hollemans [email protected] wrote:

There are two things that the style guide covers:

Formatting issues
Best practices
I'm OK with any formatting rules (2 vs 4 spaces vs tabs whatever) as long as they are reasonable. And if we use a tool to pretty print the code then this is a complete non-issue. We just have to make decisions, which is a matter of weighing limitations of the medium (web, books) versus general readability.

As far as best practices go, there are things that are obviously good practice, things that are obviously bad practice, and things that can be debated until the cows come home. Instance variables vs properties goes in the latter category. Trying to enforce a rule on that is going to do no one any good. (I'd never follow a rule on that anyway. If you want to know my personal preference: I always do the simplest thing possible. Instance variables are simpler than properties.)

So I think we should focus on the things we see done over and over that are bad practice and put those in the styleguide with some examples on how to do it better. And for issues that split our opinions 50/50 we should make a note in the document that both are acceptable practices.

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

Yeah, I guess I misunderstood the point. For the book, I spent time editing the style of people's code for two reasons: 1) to fit as much as possible in as small a space as possible while being as readable as possible, and 2) to make the code consistent, because the iGT book had a read-from-beginning-to-end kind of layout, and we had some mini games where multiple authors contributed to the same code base.

When editing tutorials, I haven't found myself spending time changing people's code for things other than correctness. I'll fix bugs, but I'm not going to change your properties to ivars or vice versa.

[ColinEberhardt]

@hollance good call. I agree that the coding style should be rigidly adhered to, but that also on certain points it should allow a small amount of flexibility. That would then remove the need to further debate this rather small detail.

[funkyboy]

So far I thought the goal of guidelines was to have code that looks as if were written/formatted by the same guy.
Am I wrong?
If we introduce flexibility I am afraid many things might be subject to discussion.
We will probably improve the current situation, but not in a significant way.

On Nov 7, 2013, at 8:40 PM, ColinEberhardt [email protected] wrote:

@hollance good call. I agree that the coding style should be adhered, but that also on certain points it should allow a small amount of flexibility. That would then remove the need to further debate this rather small detail.

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

Agree with Cesare. This also seems to echo Ray's pull request regarding consistency across all mediums regardless of the number of different authors.

Sent from my iPhone

On 7 Nov 2013, at 19:56, Cesare [email protected] wrote:

So far I thought the goal of guidelines was to have code that looks as if were written/formatted by the same guy.
Am I wrong?
If we introduce flexibility I am afraid many things might be subject to discussion.
We will probably improve the current situation, but not in a significant way.

On Nov 7, 2013, at 8:40 PM, ColinEberhardt [email protected] wrote:

@hollance good call. I agree that the coding style should be adhered, but that also on certain points it should allow a small amount of flexibility. That would then remove the need to further debate this rather small detail.

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

I thought this guideline was for something to post on the site for new iOS devs, so that people who use the site could get an explanation on good Obj-c style as they learned to code. And obviously, the tutorials would want to adhere to these guidelines. But I didn't think it was supposed to be a list of mandates that had to be followed no matter what.

If we are just trying to come up with rules for the site that everything has to follow no matter the situation, then you may as well choose arbitrarily and just say "this is so" because you won't ever get everyone to agree on them.

See Ray's pull request for the best explanation on why this is being pulled together.

Sent from my iPhone

On 7 Nov 2013, at 20:05, elephantronic [email protected] wrote:

I thought this guideline was for something to post on the site for new iOS devs, so that people who use the site could get an explanation on good Obj-c style as they learned to code. And obviously, the tutorials would want to adhere to these guidelines. But I didn't think it was supposed to be a list of mandates that had to be followed no matter what.

If we are just trying to come up with rules for the site that everything has to follow no matter the situation, then you may as well choose arbitrarily and just say "this is so" because you won't ever get everyone to agree on them.

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

I just saw that.

In that case, you use 2-space indentation and ivars whenever possible. Takes up less space. :)

[rwenderlich]

Good discussion here.

One thing to keep in mind - whatever we come to an agreement here, we should all use (and editors should edit if the author doesn't confirm to this). This guide shouldn't be a "recommendation" for our site, it's mandatory to keep everyone consistent.

This is especially important for the question of ivars versus properties, because I've received several complaints from readers that some of us are doing one way and some the other :] Readers like consistency!

I personally would be happy with either decision here, because I can see both sides:

• Properties: A little more consistent, maybe less confusing for beginners because of that. And KVO, keywords, easier to switch if you decide it's now public.
• iVars: Saves space, avoids (the very small) overhead.

I guess if you have to put me down for a vote I'd pick always properties for consistency.

Nick how do you propose we make a final decision on the matter, seems some strong feelings in both camps!

[hollance]

You cannot decide on this issue because there is no correct answer. The aim of rw.com is to teach programming and by deciding one approach over the other you're saying that you won't teach a particular approach even though it is perfectly valid and common in practice.

As far as I see it, it's not about choosing the "correct answer", it's about choosing a particular style and then sticking to it for the sake of providing a consistent experience for the readers.

Sent from my iPhone

On 7 Nov 2013, at 21:38, Matthijs Hollemans [email protected] wrote:

You cannot decide on this issue because there is no correct answer. The aim of rw.com is to teach programming and by deciding one approach over the other you're saying that you won't teach a particular approach even though it is perfectly valid and common in practice.

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

[rwenderlich]

I agree with Mic - if we sometimes do it one way and sometimes do it another way, it causes confusion for readers. They wonder to themselves, "Hm I wonder why they used properties last time and instance variables this time. Is there some reason they're not telling me? Or are they just sloppy?"

We could always make a separate article explaining our discussion here, and how there's no "one true way", but we chose way X for consistency. Maybe we should even add a note about this to the guidelines themselves.

[hollance]

If that is your argument then the only answer is to always use properties.

I personally don't think that mixing ivars and properties confuses people that much -- not more than any other thing that can potentially confuse them, and there's lots -- and in addition, a little confusion is what actually makes you learn. :-)

[ColinEberhardt]

If that is your argument then the only answer is to always use properties.

I disagree with that! Ray's argument doesn't support one approach or the other. It simply means that we do need to make a decision and stick to it.

My personal preference is to use instance variables where appropriate, and private properties where appropriate (when you need KVO or some other feature). However, my preference is a very mild one, and I'd be happy to go with any decision. It is a very minor point.

[ColinEberhardt]

Personally I think that unless anyone has further arguments for or against, we should just go with a majority vote on this one.

To go along with something @hollance mentioned, if the purpose of this site is to educate, than we should not be showing only a single way to do things. It's important for readers to see different ways to do things and ask themselves, "Why is this different from that?" If they are only ever exposed to a single style, they will be less prepared for understanding other code they come across in their lives/careers.

This issue actually came up with iGT. We have had a question on the forums where someone wondered if Sprite Kit didn't work with properties because we had used ivars. While an experience developer might think that was a silly question, it was actually a good thing that it happened because most readers probably weren't confused, and the ones who were got to learn something when they read the answer. And learning is the whole point, right?

Sure, you can pick a single way to do it, but I think it would be better to make sure each tutorial is internally consistent. I'm probably in the minority, but I think it's better for people to understand how to follow any code they come across, not just code that follows some notion of "good style."

Be honest: if one tutorial defines all of its methods like this:

-(void)method
{
// stuff
}

and another tutorial defines them all like this:

• (void)method {
  // stuff
  }

Does it really matter? Does the lack of a space after the - offend anyone? Is that extra line for the opening brace going to use up too much space?

If a reader is actually confused because they did a tutorial like the first one and then did one like the second and it was different, that's something they need to learn about ASAP. We're really doing readers a disservice by assuming they are so stupid that they can't handle those minor differences, or by pretending that only one of those methods is somehow "correct."

Ok, somehow github changed what I wrote for the second. That's weird. It was supposed to be a hyphen, space, opening parenthesis, along with an opening brace on the first line.

[hollance]

If your aim is consistency above all else, and you have the following options:

• Always use properties
• sometimes use properties, sometimes use ivars

Then the second option is less consistent, even if in your usage of ivars and properties you are consistent.

@elephantronic My thoughts exactly!

[hollance]

I think the reason why I take exception to this sort of decision is that you end up dumbing down the language we use to teach. That is the complete opposite of what we should be doing, in my opinion.

[ColinEberhardt]

@hollance - I am inclined to agree. Especially in light of your comment here:

#14 (comment)

Let's not dumb down the language by avoiding the use of perfectly good techniques for the sake of simplicity.

Okay, after having some time to reflect on this, here are my thoughts:

Apple first gave us the dot syntax for properties, but we had to write our own setters and getters which required iVars. They then introduced synthesis, shortly followed by auto-synthesis, and then finally class extensions for declaring private properties or redeclaring read-only properties. It appears Apple's intentions are to move us away from iVars and towards solely using properties.

Apart from the (very!) small performance gain and (potential) brevity, no one has actually provided any examples of why iVars should be used over properties. Here are a few of the benefits of using properties:

• They're observable
• They automatically work with KVC
• They provide protection against your data changing when declared with the appropriate contract for immutable classes that have mutable counterparts (we all use copy when declaring properties of classes with mutable counterparts, right?)

@property (nonatomic, copy) NSString *myString;

NSString *anotherString = @"Mic";

self.myString = anotherString;  // self.myString = "Mic"
anotherString = @"Michael";     // self.myString = "Mic"

// assume myString is an iVar and not a property

myString = anotherString;      // myString = "Mic"
anotherString = @"Michael"     // myString = "Michael"

To protect against this using iVars, an author must always remember to use myString = [anotherString copy] when ever setting the iVar, which widens the scope for bugs to be introduced.

• They provide scope at a glance self.someProperty is a property, anything else must be a local variable. Using iVars requires a third rule for their naming convention to provide that scope. So basically iVars require yet another styling rule to be adhered to and enforced so that scope is obvious.

If you're concerned about teaching the different options, I'd question why you're only bringing this up now? Not every reader will read every tutorial, therefore some readers will have only been exposed to properties, and others a mix of both. I'd also question why you'd be concerned about teaching an option that is very much Objective-C 1.0 and if you read my point above, one that appears to be very much on it's way out.

Since the site's audience tend to be people who are looking to learn, it's probably safe to assume most are relatively new to the language (or even programming in general) and therefore isn't it our responsibility to follow Apple's lead and push Objective C 2.0?

Finally, Ray has stated he's had feedback from readers complaining about the inconsistencies between tutorials. At the end of the day we're here to serve them, and if they have an issue with the way it's done now then we need to put our differences aside, pick an option and stick with it. And for the sake of simplicity as well as all the reasons I've pointed out above, I would recommend going all in with properties.

Note: simplicity != dumbing down the language, especially when there seems to be no obvious benefit of using iVars over properties, but yet there are plenty of benefits when using properties over iVars.

[funkyboy]

Who's our target? Beginners?
If yes, I suggest we teach in ONE way (I'd say properties are more
suitable) to avoid confusion.
At the beginning you are probably concerned about grasping the essence of a
language rather than learning
the different ways in which you can implement something.

On Fri, Nov 8, 2013 at 9:47 AM, Mic Pringle [email protected]:

Okay, after having some time to reflect on this, here are my thoughts:

Apple first gave us the dot syntax for properties, but we had to write our
own setters and getters which required iVars. They then introduced
synthesis, shortly followed by auto-synthesis, and then finally class
extensions for declaring private properties or redeclaring read-only
properties. It appears Apple's intentions are to move us away from iVars
and towards solely using properties.

Apart from the (very!) small performance gain and (potential)
brevity, no one has actually provided any examples of why iVars should be
used over properties. Here are a few of the benefits of using properties:

• They're observable
• They provide protection against your data changing when declared
  with the appropriate contract for immutable classes that have mutable
  counterparts (we all use copy when declaring properties of classes
  with mutable counterparts, right?)

@Property (nonatomic, copy) NSString *myString;
NSString *anotherString = @"Mic";
self.myString = anotherString; // self.myString = "Mic"anotherString = @"Michael"; // self.myString = "Mic"
// assume myString is an iVar and not a property
myString = anotherString; // myString = "Mic"anotherString = @"Michael" // myString = "Michael"

To protect against this using iVars, an author must always remember to use myString
= [anotherString copy] when ever setting the iVar, which widens the scope
for bugs to be introduced.

• They provide scope at a glance self.someProperty is a property,
  anything else must be a local variable. Using iVars requires a third rule
  for their naming convention to provide that scope. So basically iVars
  require yet another styling rule to be adhered to and enforced so that
  scope is obvious.

If you're concerned about teaching the different options, I'd question why
you're only bringing this up now? Not every reader will read every
tutorial, therefore some readers will have only been exposed to properties,
and others a mix of both. I'd also question why you'd be concerned about
teaching an option that is very much Objective-C 1.0 and if you read my
point above, one that appears to be very much on it's way out.

Since the sites audience tend to be people who are looking to learn, it's
probably safe to assume most are relatively new to the language (or even
programming in general) and therefore isn't it our responsibility to
follow Apple's lead and push Objective C 2.0?

Finally, Ray has stated he's had feedback from readers complaining about
the inconsistencies between tutorials. At the end of the day we're here to
serve them, and if they have an issue with the way it's done now then we
need to put our differences aside, pick an option and stick with it. And
for the sake of simplicity as well as all the reasons I've pointed out
above, I would recommend going all in with properties.

Note: simplicity != dumbing down the language, especially when there
seems to be no obvious benefit of using iVars over properties, but yet
there are plenty when using properties over iVars.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-28047397
.

Cesare Rocchi
http://studiomagnolia.com

[hollance]

I did state my reason for using instance variables over properties: I always do the simplest thing possible and instance variables are simpler than properties. Properties are often not necessary, so using them goes against that philosophy.

(By the way, dot syntax and properties are two different things. The fact that you're using properties with dot syntax is merely a convention.)

(By the by the way, if readers complain then that doesn't mean we should cater to their every whim. I don't see inconsistencies between tutorials as a bad thing. Only bad programming practice is bad.)

@hollance Okay, I'm confused. Above it's argued that simplicity == dumbing down the language, and yet your argument for using iVars is one of simplicity?

I'm not suggesting we cater to their every whim, but the site is there to teach and inconsistencies between tutorials (or even worse, chapters in the same book) IS bad when someone is trying to learn, hence the feedback.

[hollance]

@micpringle Where do you read that simplicity equals dumbing down the language? I can't really counter this argument if I don't know where it comes from.

@hollance

I think the reason why I take exception to this sort of decision is that you end up dumbing down the language we use to teach. That is the complete opposite of what we should be doing, in my opinion.

@ColinEberhardt

Let's not dumb down the language by avoiding the use of perfectly good techniques for the sake of simplicity.

[ColinEberhardt]

A quick suggestion, I think both approaches are perfectly valid and which is used is simply down to personal preference.

However, we should pick one, so shall we just go with the majority vote?

I don;t think further discussion will result in a consensus opinion on this point.

@ColinEberhardt I think that's a sterling idea.

👍 +1 for properties only

[hollance]

@micpringle Those two things you quoted do not claim that dumbing down the language and simplicity are the same thing.

@ColinEberhardt I'm not arguing that properties are better than ivars or the other way around, but that "we should pick one" is incorrect.

@hollance I'm not sure how you're reading it otherwise, but

Let's not dumb down the language by avoiding the use of perfectly good techniques for the sake of simplicity.

infers that by chasing simplicity, you are in fact dumbing down the language

We're looking to choose one to provide a consistent experience for the audience of both the site and the books. I can't see how that can be deemed "incorrect". And you could apply your argument to any of the issues you've opened (or anyone else).

[rwenderlich]

It appears we're getting on to a fundamental debate about whether code style guides are useful in general!

Correct me if I'm wrong, but here's what I see as the main arguments for both sides:

• All agree to use a certain style: "consistency makes the tutorial content easier to understand because you're not having to think about why something is different between tutorials", "it makes our tutorials/books look coordinated, polished and written by a communicative team"
• Don't enforce a certain style: "do readers really care about consistency between tutorials?", "even if they do, exposing readers to different styles/forcing learning experiences is good", and (maybe some people think this, maybe not) "my style is the 100% one true best style, I like my freedom and don't want to conform to some guide!"

I thought this code style project was worthwhile (with the goal to agree to use a certain style) because I've gotten a bunch of requests from readers (and the team!) that this would be a good idea. However, this will never work if the rest of the team doesn't think it's beneficial in general.

Seems like we have people on both camps here, here's some ways I can think to resolve this:

• For multi-author books, have the style guide enforced so the book is internally consistent. For single-author books or tutorials on the site, have the guide be a recommendation but not enforced (since the author will have their own internally consistent style).
• Take a vote and go with majority rules.
• Put a post up on the blog about this subject and get reader input directly from readers, go with what they want.

What do you think would be best?

[hollance]

@micpringle That statement says "avoiding the use of perfectly good techniques for the sake of simplicity" is equivalent to dumbing down the language. It doesn't say that the principle of simplicity itself is a bad thing, only when you try to achieve it by throwing out perfectly good techniques.

[hollance]

@rwenderlich I think for a multi-author book having an internally consistent style is more important than for tutorials on the website.

[ColinEberhardt]

@rwenderlich good call, we should remember the purpose of the style; to aid the readers of the books and tutorials, giving the same kind of consistency you would expect were they all written by a single author.

I'd vote for the style guide being enforced everywhere, otherwise its value is greatly reduced.

And I'd be more than happy to use a coding style that doesn't match my personal preferences. It is all for the greater good!

I second Colin's sentiment. I'd rather have a style guide that is enforced across all mediums (site, book, starter kits etc.) at the cost of my own preferences. I'll happily adhere to (as an author) or enforce (as an editor) a style guide, even if it differs from my own preferences, if it becomes a requirement of contributing and creates a more consistent experience for the readers.

[icanzilb]

+1 on enforcing style guide .. especially on the site with so many authors the code varies a lot from post to post ...

[moayes]

This has been probably the longest discussion I've ever read! Very good points and I can't argue against either approach. I personally prefer properties. I usually use iVars if I'm in rush and want to check something out. But for a final, bullet proof product I switch to properties.

One more benefit that I didn't see here about properties (and I very often use it) is lazy instantiation and some fail-safe checks upon assignment.

[moayes]

Oops! I didn't mean to close it.

[icanzilb]

phew ... and I thought the end of this has come ...

[hollance]

I think pretty much everyone agrees that any style guide that we decide upon should be enforced. What we apparently can't agree on is how far the style guide should go...

My vote is to not enforce a style guide across all tutorials on the site if that style guide tries to say "you must always do X even if Y is perfectly valid." For books, I like the idea of the consistent style (I suggested and wrote the style guide for iGT, after all).

I think any tutorial should be internally consistent. Don't use different brace techniques throughout, or don't use a bunch of ivars and then add a private property unless the reason for doing so is explained in the tutorial. In that case, I applaud the teaching moment.

A bunch of comments back, @micpringle mentioned how Apple is obviously moving toward properties. I just want to point out that the class extensions were not added specifically in an attempt to promote the use of properties, they were added to correct a defect in Obj-C, that being a truly private interface.

Also, and this will be the last comment I make on this, but it will be a long one, so sorry:

I've been developing for a long time. In those years, I've seen many languages and many features in languages, as well as all sorts of middleware, libraries, etc. The goal of all of these things is almost always to make things easier for the developer. (You may argue they make things less error prone, but that is simply a form of ease by taking the responsibility of writing error-free software away from the developer.)

That's all well and good. But taking advantage of each new thing, while convenient and often preferable, has also had a clear and undeniable result on the computer science landscape: there are more developers now then ever, with access to more powerful tools than ever, and those developers are currently less skilled than ever.

Not to pick on anyone, but we had a conversation in IRC one day where hash maps and other data structures came up. Felipe, who is certainly a good developer, admitted he had no idea how a hash map worked. You might think that's ok because he can still do his job with NSDictionary and who cares how it works, but that's a sign of a problem in the industry. People need to understand the guts of things if they are ever to solve real problems that don't already have an answer on stackoverflow.

When I worked writing software for the military, there were many processes we were supposed to follow. Various fads have come and gone, but all of these processes have been put in place throughout the industry for one reason: to allow C and D level developers to produce shippable software, even if it takes a long time. The idea is that a company cannot function with just A level people, people who everyone admits are hindered rather than helped by these processes. But the goal is to allow less talented people to contribute because you can't guarantee you'll always have some hot shot around to fix everything.

What's my point? Well, doing things like only showing people one way to do something because you've decided it would look nice if all of your tutorials matched each other--which seems to be the only real argument for enforcing not only internal consistency but site-wide consistency--contributes to the dumbing down of not just the language, but of the entire computer science industry. Many of the people who read this site go on to get jobs in the iOS field, and do you really want to interview someone who doesn't know what an instance variable is because "Obj-C uses properties, right?"???

I have a tattoo running the length of one of my forearms that reads, "How come you say it like you're right?" It has a lot of meaning to me on various levels, but one of them is as a reminder to myself to keep an open mind and always ask why I think what I think. In this case, I ask you guys, if this site is supposed to teach people, do you truly think readers will learn more if you enforce one particular rule to the exclusion of all others? You may say they'll learn more easily if each tutorial looks the same, but I disagree. They will learn each new thing once. The first time they see a property, they learn about properties. So what if that's in the first or second tutorial that they read?

As an example, declaring an array by using @[@"hi"] is awesome and I try to do it whenever I can, but it's really only awesome because it lets you type fewer characters, and programmers are lazy so hey, why not? It's not a magical "correct" way to populate an array, and it adds no tangible benefit (that I'm aware of) other than less typing. Please correct me if I'm wrong, because I like to learn new things. :) You might claim it's more readable, but I think 2-spaces is more readable than 4, while @hollance thinks the reverse, so maybe readability isn't as quantifiable as we'd like to think. (I'm not arguing that we shouldn't use the literal syntax, because it does save space, but what happens when a reader needs to make an array in their own lives and they don't have all the elements on hand when typing the file? Oh crap, sure would have been nice if they knew there were ways to make arrays in Obj-C other than that one.)

Ok, this has been fun. I've been crunching against a deadline and these little chats have been a nice way to break up the grind. But now you'll probably go say Obj-C uses properties and I'll accept it, because I pretend to care more than I really do.

P.S. If you're curious about the tattoo, it's part of a line in a Bright Eyes song that goes
"If you swear
that there
is no truth
and who cares,
how come you say it
like you're right?"

That's all well and good Chris, but the issue with that is I haven't seem a single tutorial that's explains the "why" behind the choice of the author to use properties or iVars (as an example). So the reader isn't really learning about the alternative, only that one exists, and that's where confusion stems from.

Sent from my iPhone

On 8 Nov 2013, at 16:41, elephantronic [email protected] wrote:

My vote is to not enforce a style guide across all tutorials on the site if that style guide tries to say "you must always do X even if Y is perfectly valid." For books, I like the idea of the consistent style (I suggested and wrote the style guide for iGT, after all).

I think any tutorial should be internally consistent. Don't use different brace techniques throughout, or don't use a bunch of ivars and then add a private property unless the reason for doing so is explained in the tutorial. In that case, I applaud the teaching moment.

A bunch of comments back, @micpringle mentioned how Apple is obviously moving toward properties. I just want to point out that the class extensions were not added specifically in an attempt to promote the use of properties, they were added to correct a defect in Obj-C, that being a truly private interface.

Also, and this will be the last comment I make on this, but it will be a long one, so sorry:

I've been developing for a long time. In those years, I've seen many languages and many features in languages, as well as all sorts of middleware, libraries, etc. The goal of all of these things is almost always to make things easier for the developer. (You may argue they make things less error prone, but that is simply a form of ease by taking the responsibility of writing error-free software away from the developer.)

That's all well and good. But taking advantage of each new thing, while convenient and often preferable, has also had a clear and undeniable result on the computer science landscape: there are more developers now then ever, with access to more powerful tools than ever, and those developers are currently less skilled than ever.

Not to pick on anyone, but we had a conversation in IRC one day where hash maps and other data structures came up. Felipe, who is certainly a good developer, admitted he had no idea how a hash map worked. You might think that's ok because he can still do his job with NSDictionary and who cares how it works, but that's a sign of a problem in the industry. People need to understand the guts of things if they are ever to solve real problems that don't already have an answer on stackoverflow.

When I worked writing software for the military, there were many processes we were supposed to follow. Various fads have come and gone, but all of these processes have been put in place throughout the industry for one reason: to allow C and D level developers to produce shippable software, even if it takes a long time. The idea is that a company cannot function with just A level people, people who everyone admits are hindered rather than helped by these processes. But the goal is to allow less talented people to contribute because you can't guarantee you'll always have some hot shot around to fix everything.

What's my point? Well, doing things like only showing people one way to do something because you've decided it would look nice if all of your tutorials matched each other--which seems to be the only real argument for enforcing not only internal consistency but site-wide consistency--contributes to the dumbing down of not just the language, but of the entire computer science industry. Many of the people who read this site go on to get jobs in the iOS field, and do you really want to interview someone who doesn't know what an instance variable is because "Obj-C uses properties, right?"???

I have a tattoo running the length of one of my forearms that reads, "How come you say it like you're right?" It has a lot of meaning to me on various levels, but one of them is as a reminder to myself to keep an open mind and always ask why I think what I think. In this case, I ask you guys, if this site is supposed to teach people, do you truly think readers will learn more if you enforce one particular rule to the exclusion of all others? You may say they'll learn more easily if each tutorial looks the same, but I disagree. They will learn each new thing once. The first time they see a property, they learn about properties. So what if that's in the first or second tutorial that they read?

As an example, declaring an array by using @[@"hi"] is awesome and I try to do it whenever I can, but it's really only awesome because it lets you type fewer characters, and programmers are lazy so hey, why not? It's not a magical "correct" way to populate an array, and it adds no tangible benefit (that I'm aware of) other than less typing. Please correct me if I'm wrong, because I like to learn new things. :) You might claim it's more readable, but I think 2-spaces is more readable than 4, while @hollance thinks the reverse, so maybe readability isn't as quantifiable as we'd like to think. (I'm not arguing that we shouldn't use the literal syntax, because it does save space, but what happens when a reader needs to make an array in their own lives and they don't have all the elements on hand when typing the file? Oh crap, sure would have been nice if they knew there were ways to make arrays in Obj-C other than that one .)

Ok, this has been fun. I've been crunching against a deadline and these little chats have been a nice way to break up the grind. But now you'll probably go say Obj-C uses properties and I'll accept it, because I pretend to care more than I really do.

P.S. If you're curious about the tattoo, it's part of a line in a Bright Eyes song that goes
"If you swear
that there
is no truth
and who cares,
how come you say it
like you're right?"

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

You say the word "confusion" like it's a bad thing. Confusion leads to questions, which lead to answers, which lead to learning.

Confusion also leads to frustration, ignorance and bad programming (as-in writing code you don't understand)

A site like RW.com should strive to leave it's readers enlightened, fulfilled and with a sense of achievement. Not confusion, or leaving them with unanswered questions.

Sent from my iPhone

On 8 Nov 2013, at 16:55, elephantronic [email protected] wrote:

You say the word "confusion" like it's a bad thing. Confusion leads to questions, which lead to answers, which lead to learning.

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

[ricardo-rendoncepeda]

Could not agree more with @micpringle . We have a duty to our readers and the community - creating confusion would be a disservice to all.

Back to ivars vs. properties...
+1 on enforcing a style and therefore my vote is +1 for properties.
In previous projects (of the graphics-intensive kind), ivars have increased my performance significantly when using C primitives (granted, this was about 2 years ago). I say properties be the norm and ivars be introduced with an explanation if they cause a significant performance change.

Have we been creating confusion in the community? Really? Has rw.com up to this point been a "disservice to all?"

This discussion has turned ridiculous. Is the goal to give readers the "sense of achievement," or to actually help them achieve something? Don't bother answering, because it doesn't matter: people will type in whatever you tell them to type and they will feel good when it compiles. That's the nature of tutorials. The few people that are actually going to learn something are the ones that would have had no problem seeking out additional help if they found something confusing.

Back to ivars vs. properties:

@Property (nonatomic, assign) int count;
or
int _count;

You're right, the first is clearly less confusing for a new developer. +1 for being less confusing and giving everyone a sense that we've achieved something here--namely, that we finally fixed rw.com, which has been so clearly broken up until this thread that all of our readers have been turned away in a state of blind confusion and have never learned anything. Today, sirs, we are all winners.

PS. It may not seem like it, but I'm more amused than anything about all of this. I really do like properties.

[ricardo-rendoncepeda]

EDIT: @elephantronic quote:
"You say the word "confusion" like it's a bad thing. Confusion leads to questions, which lead to answers, which lead to learning."

@elephantronic

Clearly we have not been a disservice to all, far from it. But we would be if we deliberately create confusion.

RW is the first port of call for most iOS developers, not just new ones. Even experienced developers turn to our tutorials because they are light-hearted, easy-to-understand, and have a great reputation. This is not speculation either; here in SF I've been thanked, in person, for our tutorials from engineers/developers who are far more experienced than myself, in both OpenGL ES and iOS.

Furthermore, there is a lot of personal pride, responsibility and achievement in being a tutorial team member. Therefore being sloppy could not only be bad for our readers, but for ourselves as well.

At what point did I suggest being sloppy or deliberately confusing? I simply said choosing one valid approach over another for no reason other than so it is always the same is bad for readers. If any single tutorial uses a single approach within itself, it shouldn't matter if two different tutorials use different approaches. Mind you, I'm talking about correct approaches--I'm not saying we should do things that are actually bad code in hopes of getting the reader to ask questions and learn on their own.

I'm yet to hear a valid argument as to why choosing a single approach for the sake of consistency is "bad for readers".

Especially given you seem in favour of adopting that approach for books, which at their core are nothing more than a series of tutorials, and therefore differ very little from the site.

Sent from my iPhone

On 8 Nov 2013, at 17:58, elephantronic [email protected] wrote:

At what point did I suggest being sloppy or deliberately confusing? I simply said choosing one valid approach over another for no reason other than so it is always the same is bad for readers. If any single tutorial uses a single approach within itself, it shouldn't matter if two different tutorials use different approaches. Mind you, I'm talking about correct approaches--I'm not saying we should do things that are actually bad code in hopes of getting the reader to ask questions and learn on their own.

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

[ColinEberhardt]

Sorry all, how do I put these worms back into the can? :-P

You chose to open Pandora's box ;)

Sent from my iPhone

On 8 Nov 2013, at 18:09, ColinEberhardt [email protected] wrote:

Sorry all, how do I put these worms back into the can? :-P

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

When we wrote iGT, I suggested a style guide for several reasons, all of which are because it is nothing like the site:

Each app was spread across multiple chapters, as many as six in some cases.

Not all if those chapters were written by the same person. We had multiple authors writing a single app, so in that case it could be confusing if one chapter added some properties and the next chapter added some ivars to the same class.

The book was meant to be read from beginning to end. We don't explain each thing in detail if it was already explained in an earlier chapter. Therefore, as editors, we had to adjust a lot of content to make sure it all flowed well as basically one big tutorial.

We were trying to conserve page space because we had a hard page count target. Because if that, the style choices I made were almost always for conserving space above all else, as long as it was still readable.

I specifically made the rule that in iGT, we should only use ivars for private data because properties served no purpose whatsoever other than to take up new space in the book.

Everyone keeps telling me about all the cool things you can do with properties, but in over 800 pages of iGT, those things didn't come up once. So maybe the argument should be, instead of using ivars only when they improve performance significantly, we should only use properties when they provide a tangible benefit in the specific tutorial?

Mind you, I'm not actually arguing that. I'm not actually arguing at all. As soon as this thread was created I assumed that you'd go with properties. I'm just saying that saying the site can only use properties is basically denying the existence of part of Obj-C, which doesn't seem educational at all to me.

Sent from my iPhone

On Nov 8, 2013, at 1:05 PM, Mic Pringle [email protected] wrote:

I'm yet to hear a valid argument as to why choosing a single approach for the sake of consistency is "bad for readers".

Especially given you seem in favour of adopting that approach for books, which at their core are nothing more than a series of tutorials, and therefore differ very little from the site.

Sent from my iPhone

On 8 Nov 2013, at 17:58, elephantronic [email protected] wrote:

At what point did I suggest being sloppy or deliberately confusing? I simply said choosing one valid approach over another for no reason other than so it is always the same is bad for readers. If any single tutorial uses a single approach within itself, it shouldn't matter if two different tutorials use different approaches. Mind you, I'm talking about correct approaches--I'm not saying we should do things that are actually bad code in hopes of getting the reader to ask questions and learn on their own.

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

[hollance]

If a book presents a certain API from beginning to end, such as Sprite Kit, it makes sense that all source code is consistent. The reader is taken on a journey through the book and it can be quite confusing if the next chapter breaks from the expectations that were established in the previous chapters.

If a book consists of many separate topics, such as i7T, then in my opinion this is less of an issue. The website is even more loosely organized than a book (i.e. not at all). I agree with @elephantronic that it's more important that a tutorial is internally consistent than that it is consistent with all other tutorials out there.

I do not believe that having some tutorials use properties exclusively and some tutorials using a mix of properties and ivars will make readers' brains explode. I do believe that limiting ourselves to just one approach will do our readers a disservice. That's like saying, "On this site we only teach half of Objective-C."

There are some topics where choosing a single approach for the sake of consistency is good. For example:

• formatting: spaces, braces, whatnot
• naming things
• being explicit, not making assumptions
• basic architecture (not stuffing things into the AppDelegate etc)

You'll hear no argument from me there, even if I personally prefer to indent with tabs and put my braces elsewhere. That's just a matter of taste and familiarity.

But when you say we should always use X and never use Y even though Y is just as good as X (whatever it is), just because you want things to be consistent, then I see hobgoblins start to appear.

I'm all for making a better experience for the reader. I'm just not convinced that consistency at all costs makes a better experience.

[icanzilb]

@elephantronic

I just want to point out that the class extensions were not added specifically in an attempt to promote the use of properties, they were added to correct a defect in Obj-C, that being a truly private interface.

If you believe that you should also provide a definition what do you understand under "private". Since other classes can use normally properties defined in class categories, I don't think they have to do anything with private interfaces

See, @hollance said what I said, but he always sounds more rational. Someone should listen to that guy.

Sent from my iPhone

On Nov 8, 2013, at 1:36 PM, Matthijs Hollemans [email protected] wrote:

If a book presents a certain API from beginning to end, such as Sprite Kit, it makes sense that all source code is consistent. The reader is taken on a journey through the book and it can be quite confusing if the next chapter breaks from the expectations that were established in the previous chapters.

If a book consists of many separate topics, such as i7T, then in my opinion this is less of an issue. The website is even more loosely organized than a book (i.e. not at all). I agree with @elephantronic that it's more important that a tutorial is internally consistent than that it is consistent with all other tutorials out there.

I do not believe that having some tutorials use properties exclusively and some tutorials using a mix of properties and ivars will make readers' brains explode. I do believe that limiting ourselves to just one approach will do our readers a disservice. That's like saying, "On this site we only teach half of Objective-C."

There are some topics where choosing a single approach for the sake of consistency is good. For example:

formatting: spaces, braces, whatnot
naming things
being explicit, not making assumptions
basic architecture (not stuffing things into the AppDelegate etc)
You'll hear no argument from me there, even if I personally prefer to indent with tabs and put my braces elsewhere. That's just a matter of taste and familiarity.

But when you say we should always use X and never use Y even though Y is just as good as X (whatever it is), just because you want things to be consistent, then I see hobgoblins start to appear.

I'm all for making a better experience for the reader. I'm just not convinced that consistency at all costs makes a better experience.

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

[hollance]

LOL, that's the same thing I was thinking about you, @elephantronic. :-)

I'll just leave this here...

It’s best practice to use a property on an object any time you need to keep track of a value or another object.

https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html

[hollance]

@micpringle Well, that certainly speaks in favor of properties. Not that Apple is always right... and I still think it's a mistake to enforce them. But I am in favor of following Apple's recommendations as much as possible when it comes to putting together a guide such as this.

[ColinEberhardt]

Can I suggest a compromise?

I think there are a number of us (myself included) who would be unhappy to have a style guide that is optional. However, there are some points, such as this, where I don't think we will be able to come to a decision that everyone is happy to adopt. I know I previously tried to steer us towards a vote, but I don't think this is a going to work.

My suggested compromise is this:

1. We make the code style mandatory
2. In a few areas we allow flexibility and a degree of choice.

Regarding point (2) in the context of the style point we are debating in this thread, the guide would state that instance variable require an underscore prefix, but that it is perfectly permissible to use private properties in place of instance variables based on the writer / editors discretion.

How does that sound? This suggested compromise could also help resolve some of the other (less fiery) debated!

Sounds good to me.

Sent from my iPhone

On Nov 9, 2013, at 2:48 AM, ColinEberhardt [email protected] wrote:

Can I suggest a compromise?

I think there are a number of us (myself included) who would be unhappy to have a style guide that is optional. However, there are some points, such as this, where I don't think we will be able to come to a decision that everyone is happy to adopt. I know I previously tried to steer us towards a vote, but I don't think this is a going to work.

My suggested compromise is this:

We make the code style mandatory
In a few areas we allow flexibility and a degree of choice.
Regarding point (2) in the context of the style point we are debating in this thread, the guide would state that instance variable require an underscore prefix, but that it is perfectly permissible to use private properties in place of instance variables based on the writer / editors discretion.

How does that sound? This suggested compromise could also help resolve some of the other (less fiery) debated!

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

[rwenderlich]

@ColinEberhardt That sounds good to me as well. Would it make sense to organize the guide like this:

1. Split the style guide into two sections: mandatory and "suggested but optional". For the "suggested but optional" section, we'll suggest what to use (i.e. properties in this case) but authors can use ivars if they prefer. The benefit of having a "suggestion" rather than just saying "use either way" is so that authors who don't care so strongly and just want to keep things consistent know which one they should choose to fit in with the majority of tutorials.
2. For tutorials on the site or single-author books, only the mandatory section will be enforced. For multi-author books that read "in a sequence" like iGT, the "suggested but optional" will be enforced too.

@rwenderlich RE: your second point, I'm not sure how we can enforce something that is optional. In this case for example, an author could use properties, iVars, or a mix of the two, all of which would be perfectly acceptable under the "suggested but optional" part.

[ndubbs]

Ray makes two good points for how to organize the style guide. If this turns out to be one or two points then it should just be noted in-line for that section.

I would like to hear from everyone their opinion on which sections should fall under the "suggested but optional" section. :]

[ColinEberhardt]

OK, sorry for closing / re-opening etc ... but I don't think this issue is fully resolved! I am writing an article at the moment, so am testing the style guide.

In my comment above (#5 (comment)) I suggested that we do not enforce the use of properties, allowing authors to use instance variable for private state.

The style guide states that:

Property definitions should be used in place of naked instance variables whenever possible.

Which is fine, and the related code sample illustrates that instance variable should not be on the public API.

However, this still doesn't cover the use of 'private' instance variables.

[gregheo]

I thought instance variables had been killed dead and the "Private Properties" section was the new law.

What if we renamed that section to "Private Data" and added a little hedge like "Use properties in the anonymous category for private data. If you have a good reason, you can also declare instance variables."

As Ray said, that'll create a "default" for people to use. For the advanced folks, they can get a justifiable out and say "I don't need KVC!" or whatever. That's probably kicking the can down the road for picking the One True Style for books, but I think "properties by default" is reasonable for the site.

Here's the style question: if private ivars are allowed, where should they be declared in the .m file?

@interface FusionGenerator () {
  NSInteger _hydrogenTankLevel; // here?
}
@end

@implementation FusionGenerator {
  NSInteger _hydrogenTankLevel; // or here?
}

For the record, I use private ivars in the first style. Something about mixing in declarations with the @implementation bothers me.

[ColinEberhardt]

Ah, I guess the issue here is the term 'naked instance variable', which is pretty unclear.

If instance variables have been 'killed dead', this needs to be started quite clearly.

and yes, I can live with that!

[ColinEberhardt]

@gregheo for what it's worth, this is my preference:

@implementation FusionGenerator {
  NSInteger _hydrogenTankLevel; // or here?
}

To your point:

Something about mixing in declarations with the @implementation bothers me.

It doesn't bother me at all! private state is implementation!

Anyhow, this is moot. I have made a few minor tweaks to the style guide which should make it more obvious that instance variables are a no-go.

[ColinEberhardt]

So I've just updated my current project to use this style, and it is now littered with extra self. references due to replacing instance variables with private properties. Horrible!

Good job I am writing about ReactiveCocoa, so my goal is to remove all this extra state!

Anyhow, I'll shut up now. This is the consensus and I am duty bound to follow it.

grumbles

[hollance]

If it's any consolation, I'm with you on this one, Colin. ;-)

Sent from my iPhone

On 23 dec. 2013, at 22:36, ColinEberhardt [email protected] wrote:

So I've just updated my current project to use this style, and it is now littered with extra self. references due to replacing instance variables with private properties. Horrible!

Good job I am writing about ReactiveCocoa, so my goal is to remove all this extra state!

Anyhow, I'll shut up now. This is the consensus and I am duty bound to follow it.

grumbles

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

[ColinEberhardt]

@hollance - how strongly do you feel about this one? is it worth pushing for a re-think and opting for a code style that do not ban instance variables?

For reference this is what my code looked like before:

https://gist.github.com/ColinEberhardt/8109483

And this is how it looks after:

https://gist.github.com/ColinEberhardt/8109474

[icanzilb]

I'm up for a revolution ... I never leaned towards properties only but didn't have too much time on my hands to be more active in this thread.

I think, given Ray has already made the call on this, and that it will always be a contentious issue leaving at least one party unhappy, pushing for a change at this late stage (it's going to be published in January) isn't that good of an idea.

Also, since the parties on either side of this argument will never agree, why not opt to follow Apple's lead (see the link I posted above) rather than pursuing a personal preference?

[icanzilb]

I'd say now is the perfect time since Ray and Apple are in vacation :P

It's a good point to think about this rule once more - as Mic says it will always upset half the people, and we better have rock solid argumentation for whatever we try to push for.