Should instance variable have an underscore prefix?

[ColinEberhardt]

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?

[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.

[ghost]

@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.

[ghost]

@ColinEberhardt I think that's a sterling idea.

:+1: +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.

[ghost]

@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!

[ghost]

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...

[ghost]

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?"

[ghost]

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 notifications@github.com 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.

[ghost]

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

[ghost]

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 notifications@github.com 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.

[ghost]

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.

[ghost]

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.

[ghost]

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 notifications@github.com 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

[ghost]

You chose to open Pandora's box ;)

Sent from my iPhone

On 8 Nov 2013, at 18:09, ColinEberhardt notifications@github.com wrote:

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

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

[ghost]

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 notifications@github.com 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 notifications@github.com 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

[ghost]

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 notifications@github.com 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. :-)

[ghost]

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!

[ghost]

Sounds good to me.

Sent from my iPhone

On Nov 9, 2013, at 2:48 AM, ColinEberhardt notifications@github.com 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.

[ghost]

@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 (https://github.com/raywenderlich/objective-c-style-guide/issues/5#issuecomment-28122089) 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 notifications@github.com 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.

[ghost]

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.

[ghost]

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.