kodecocodes / objective-c-style-guide Goto Github PK

The style guide as written says that properties should be used with dot notation, which I think is a fine rule. However, many people write:

x = self.array.count

There's nothing particularly wrong with that, except that count is not declared as a property. It might be worth putting this specific example in the guide.

The Cocoa Guidelines are ambiguous when it comes to symbol prefixes. For example, the Coding Guidelines for Cocoa say (emphasis mine):

A prefix has a prescribed format. It consists of two or three uppercase letters and does not use underscores or “sub prefixes.”

However, the Programming with Objective-C: Conventions page states

Your own classes should use three letter prefixes. These might relate to a combination of your company name and your app name, or even a specific component within your app. As an example, if your company were called Whispering Oak, and you were developing a game called Zebra Surprise, you might choose WZS or WOZ as your class prefix.

What are your thoughts on this? I know the guide says to use RW, but since the three-letter prefix appears to be preferred, that wouldn't follow the convention. I know it's nitpicky, but that's what we're here for, right? :]

On the guide you state "Private properties should be used in place of instance variables whenever possible. Although using instance variables is a valid way of doing things, by agreeing to prefer properties our code will be more consistent."

Property accessors are MUCH slower than instance variable access. So why do not allow direct declaration of variables for private use in a class?. What do you mean by "consistent"

I think the guidelines in this section to beyond the scope of what we're trying to do with this style guide and is overly onerous. I propose we remove the entire section.

What do you all think?

This may be a bit nit picky, but I think it would be an improvement if the principles in the document would be used in other principles examples.

For example, it is recommended that any property that has a mutable subclass (like NSString*), be declared with attributes nonatomic and copy. However, in most (if not all) of the other examples on the page, NSString is declared with nonatomic and strong.

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?

I just started writing objective c recently. This indentation is crazy.

How do I deal with something like this?

Note that this "alert" variable is already nested under 3 levels. So xocd automatically tries to wrap text if too long.

Where do i start a new line? where should the message:@"" start?

                UIAlertController* alert = [UIAlertController alertControllerWithTitle:@"Broadcast Invite"
                                                                               message:@"Do you want to join??."
                                                                        preferredStyle:UIAlertControllerStyleAlert];

This one is just for fun!

In my first tutorial series I had my smiley face emoticons changed from :) to :].
I did not think the editors would actually change that - Lolz.

They're a very prominent style feature of the RW site, so I think we should dedicate a tiny section to them :]

I just finished writing a tutorial when I noticed right near the end an issue with the starter project. Most annoying!

I am just thinking out loud here, I wonder how much of this style guide you can enforce using static analysis tools. I haven't tried any Objective-C linting tools yet, has anyone tried OCLint or similar?

By skimming through our rules, I think it should be possible to enforce around 70% using a linking tool. And if such a tool doesn't exist - it's time to build one!

The current style guide does not detail whether we should or should not, but the 'f' suffix is lacking in one of the examples.

static const CGFloat RWImageThumbnailHeight = 50.0;

I am on the fence about this one.

I see a lot of people do this:

whateverWithWidth:andHeight:

It will be good to mention that it is better to do:

whateverWithWidth:height:

Usage of "and" is reserved for when more than one thing happens:

doSomething:andSomethingElse:

In the preffered box you show:
static NSTimeInterval const RWTutorialViewControllerNavigationFadeAnimationDuration = 0.3;

where you previously state to use 3 letter RWT prefix, so it should be:
RWTTutorial(...)

Does anyone know how to make Xcode auto-indent blocks correctly?

What I mean is that, according to this guide and to what I think is a much cleaner and readable code, blocks should be indented like the following:

Preferred:

// blocks are easily readable
[UIView animateWithDuration:1.0 animations:^{
  // something
} completion:^(BOOL finished) {
  // something
}];

Not Preferred:

// colon-aligning makes the block indentation hard to read
[UIView animateWithDuration:1.0
                 animations:^{
                     // something
                 }
                 completion:^(BOOL finished) {
                     // something
                 }];

But Xcode keeps wrongly indenting the inside-block code every semi-colon I type!

Your link to the Google Objective C style guide is broken:
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml

Here is a working link to the Google Objective C style guide:
https://google.github.io/styleguide/objcguide.xml

Pull request #70 would fix this.

(I only discovered the Pull Request as i finished this issue, but as it has been open since October 2016 perhaps this issue is still worth writing down).

I get the point on using (a particular sort of) English. Of course on a guide something must be agreed, but I want to point out that using English is a big a source of problems. This is because Apple uses it. Try to add an instance variable named _alpha to an UIView subclass and you will see. Crashes and odd things are guaranteed to happen without any previous warning. I avoid English in my code for that reason but other than using a different language, is there a consistent way to prevent this kind of issue?. What do English coders to prevent it? a custom prefix or suffix on each instance var?

I didn't see any rule about IBAction methods in the guide.

I think there are 2 parts to this:

1. How to name such methods - "didPressButtonA" or "buttonAPressed", or something else. I myself, always prefix IBAction methods with "action" and that liberates me of coming up with a proper verb, subject, etc. so I always go for

-(IBAction)actionButtonA 

so there's no binding to what exactly the method will do (because this also might change along the way), but it says exactly "the method that is the action of buttonA"

2. I always add the "sender" parameter, but I end up using it in maybe less than 1% of the cases ... I'm not sure about it ... if you won't use the sender param to me it feels stylewise the same if you gonna have

-(IBAction)actionButtonA;

or

-(IBAction)actionButtonA:(id)sender;

opinions?

I have this open as a pull request but it's a bit hidden, so I'm opening up a new issue for this as well.

In the guide it currently says this is how you check for nil:

if (someObject) ...
if (!someObject)...

I strongly suggest we are always explicit about this sort of thing:

if (someObject != nil) ...
if (someObject == nil)...

That makes it immediately clear what you're comparing.

I'd like the syntax if (a) and if (!a) to be limited to booleans only.

So not this either:

if (someInt) { ... }

The only exception I make for this in my own code is init methods:

if ((self = [super init]))

because that is idiomatic.

I saw seems all places the properties was inited by the keyword self which wasn't recommended by Apple.

For example:

- (id)init {
    self = [super init];
    if (self) {
        self.walletService = [[Xxx alloc] initWithPresenter:nil];
    }
    return self;
}

https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html
http://qualitycoding.org/objective-c-init/
https://stackoverflow.com/a/8056260/291240

I don't know if this is the right place to discuss this.
If not let me know.

When writing a tutorial/chapter it is likely you need to provide instructions for common tasks like "link against framework x" or "create a mobile provisioning profile". These require a sequence of tasks that is repeated over and over in many tutorials.

I propose to have a section in the site that describes these common tasks, so that in the tutorial we can simply say "link against framework x and y (here are instructions if you don't know how to link against a framework)" and that's all.

What do you think?

What are good warning flags to enable by default?

I prefer -Wall -Wextra -Wno-unused-parameter. It might be good to have these as suggested settings.

The Golden Path section advocates earlying out on errors.

Yet, the recommended style for Init Methods is the opposite.

Why is that?

Is it possible to change this line:
NSInteger arrayCount = [self.array count];

to either
NSInteger names = self.names.count, or NSInteger names = [self.names count]

This is because I've seen a lot of inexperienced developers use array when naming an array, even though they should name using as high level of abstraction as possible (i.e. instead of nameArray, they should use names). And I think your style guide has a big influence within the Objective-C community.

Thanks

I know that 4-space is generally more popular than 2-space, however, I think this code style should reflect the fact that the code we are writing will be reproduced in blog posts, tutorials and books where there are significant restrictions on page-width.

When writing iOS 7 by tutorials there were significant wrapping issues (due in part to Apple's verbose naming conventions!).

I would like to propose the use of 2-space indentation in order to reduce the need to wrap lines when reproducing code within articles.

Is there a clear license for reproducing and modifying this guide?

@ndubbs

In Conditionals the guide says:

Not preferred:
if (!error) return success;

In Golden Path the guide says:

Preferred:
if (![someOther boolValue]) return;

These look essentially the same to me, I think in this case we are contradicting ourselves.

Three arguments FOR this inclusion:

1) Consistency

UI elements linked as IBOutlets from Interface Builder are automatically generated with this convention:

@property (weak, nonatomic) IBOutlet UIView *exampleViewOne;

Yet many times I've encountered instances where properties are declared like so:

@property (nonatomic, strong) UIView *exampleViewTwo;

I think we should standardize this pattern to:

@property (storage, atomicity) ...

2) Default values

In the current style guide there is already a conflicting style regarding properties.
In Variables:

@property (nonatomic) NSString *tutorialName;

In Private Properties:

@property (nonatomic, strong) GADBannerView *googleAdView;

strong is the default state, but this may not be clear to new programmers.

3) Lack of Official Documentation

Property attributes and their correct usage is one of the least documented topics in Objective-C. They are hard to grasp and are a very common question in our community. I think we'd be doing a massive service to everyone by dedicating a section to them in our Style Guide :]

http://stackoverflow.com/questions/588866/atomic-vs-nonatomic-properties

While tech editing i7t I realised we have an inconsistency with some people using compound literal syntax:

self.imageView.frame = (CGRect){ .origin = CGPointZero, .size = self.photo.size };

Should we use this less-often used, yet highly useful syntax? Or use the CGRectMake macro for simplicity / familiarity?

My gut feeling is that we should use this feature, but ensure that the code style guidelines are easily discovered by reader (i.e. linked to by every tutorial), and that we make one goal of the style guideline to be educating the reader.

This is less relevant for the web, but important for book authors. I think it would be great to provide some guidance about how to break long lines of code over multiple lines.

Hello I'm canapio. iOS developer.
This is very useful for me!
I'm Korean, and I want pull request Korean ver. (Not make yet)
If contributor permits this, I will pull request after make new localization folder and localized "objective-c-style-guide".
Thank you :-)

You should link to Apple. They do a pretty good job on most of the topics.

https://developer.apple.com/library/mac/documentation/cocoa/conceptual/codingguidelines/codingguidelines.html

I don't like the labels Good and Bad. That gives these choices a value judgment while they are not. Most of these choices -- such as where you put the braces -- are simply that: choices.

With people getting emotional over coding style guides, using labels such as Good and Bad isn't helping any.

枚举的想法,关于两种枚举的写法
个人建议,还是采用文中提到的旧方法
建议理由:
1.旧方法简单快捷,而且在不特定设置快捷代码块的情况下,系统自带,一般情况,敲出来enum就会提示
typedef enum : NSUInteger {
<#MyEnumValueA#>,
<#MyEnumValueB#>,
<#MyEnumValueC#>,
} <#MyEnum#>;

2.在OC与Swift混编的情况下,新的枚举不能使用,应为目前涉及到#define

在快捷和混编的情况下,我更倾向于枚举的旧写法

How to format a switch statement?

How to point out that a case falls through?

I suggest we write it as such:

result = (a > b) ? x : y;

In other words, place parentheses around the condition. There are two reasons for this:

1. It is easier to read
2. You don't have to worry about operator precedence.

I couldn't find any mention of what language we should use. I know it's slightly pedantic, but I think it should be explicit that methods, variable names etc use a standard choice of language. Presumably we'd pick US English.

It only really matters in things like color vs colour, recogniser vs recognizer, etc.

Thoughts?

So this was the primary question which I was trying to answer when I found this guide. Strangely enough, neither in Apple's official documentation nor here it is not indicated. Google, on the other hand, in its style guide recommends 100 columns. Objective-C is quite a verbose language, so may be even 120 is still good.

"Some of Apple’s APIs write garbage values to the error parameter (if non-NULL) in successful cases, so switching on the error can cause false negatives (and subsequently crash)."

Hello,

Do you have some examples of Apple API that do that ? That fill the NSError in success cases ?

Golden path states we should avoid putting code in if statements when possible. But in the Init section it says we should do:

if (self) {
...
}

while if we follow the Golden Path section this code should be:

if (!self) return nil;
...

Not sure which section is better, but it's confusing to get contradicting directions

The guide states:

"Direct access to instance variables that 'back' properties should be avoided except in initializer methods (init, initWithCoder:, etc…), dealloc methods and within custom setters and getters. For more information on using Accessor Methods in Initializer Methods and dealloc, see here"

Since ARC there is no longer a reason to do so. With ARC you can safely access instance variables without any issues and doing it is MUCH faster. The linked Apple doc that recommends using always property accessors is outdated. Notice that according to said document the main reason to use properties is to help on manual memory management. This is the main reason the document points to:

"Sometimes it might seem tedious or pedantic, but if you use accessor methods consistently, the chances of having problems with memory management decrease considerably. If you are using retain and release on instance variables throughout your code, you are almost certainly doing the wrong thing"

This is no longer the case. Not using instance variables is just a prejudice based on earlier assumptions. We should start using them normally in the private scope of a class, that's completely fine now.

Properties should still be used for external object access but as said there is no longer any justification for using them in the private scope of a class, including accessing instance variables of the class own properties.

How does everyone write their init methods?

I use:

- (id)init
{
  if ((self = [super init])) {
    . . .
  }
  return self;
}

The variations on this are endless. Apple seems to prefer this now:

- (id)init
{
  self = [super init];
  if (self) {
    . . .
  }
  return self;
}

But I also see people do this:

- (id)init
{
  self = [super init];
  if (self == nil) return nil;

  return self;
}

I like the first one because it just looks aesthetically pleasing to me.