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?

[ghost]

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

[ghost]

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

[ghost]

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.

[ghost]

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

[ghost]

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.

[ghost]

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

[ghost]

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

[ghost]

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

[ghost]

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

[ghost]

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.

[ghost]

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

[ghost]

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

[ghost]

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

[ghost]

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

[ghost]

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.

[ghost]

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

[ghost]

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.

[ghost]

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

[ghost]

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

[ghost]

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:

https://github.com/raywenderlich/objective-c-style-guide/issues/14#issuecomment-28043939

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

[ghost]

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

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/raywenderlich/objective-c-style-guide/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.)

[ghost]

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