Convention

• Properties should maintain state
• No mutable collections in properties
• Property accessor methods should have minimal, predictable side effects
• When overriding the getter, we almost certainly want to override the setter
• If overriding the setter, you need to override the getter unless the setter override calls super

Rationale

Different rationales per convention, but generally these are good patterns to follow to make your code more maintainable and match the way Apple use properties.

Example

TBD

What convention is being referenced?

Classes/Naming.md

How do you propose this convention could be improved? Please provide rationale and examples if possible.

Current code has a typo of @nd instead of @end, it should be fixed.

@interface XYZObject : NSObject // good: XYZ three letter prefix
@nd

Convention

• First letter should be lower case
• Use camel case
• No underscores
• BOOL properties have special names (e.g., setHidden & isHidden:)
• Getters don't begin with the word "get"
• Setters do begin with the word "set"
• Category Properties - point to the existing category naming section

Rationale

Matches Apple's recommendations and style

Example

TBD

I was asked if we had anything about blocks in here. We should probably add this?
No idea what the convention should be :D I always go here to remind myself how to use em

Convention

Rationale

Example

Convention

Use curly braces for single line scope statements, such as if and for statements

Rationale

Adding curly braces for single line logic statements prevents errors in maintenance and refactoring over time. These types of refactoring issues around single-line if statements being refactored for multiple lines have caused real-world regressions.

Example

https://www.imperialviolet.org/2014/02/22/applebug.html

Convention

When there is more than one way to init an object (e.g. initWithFrame, initWithCoder) and these perform common routines (such as setting ivars, sizing, etc.), consider using c-style function to perform to handle this vs. an Obj-C function.

Rationale

Particularly if the name is a common one (e.g. initCommon:, etc.), there is some risk that the function could be overridden without calling super.

Example

@implementation XYZView

void XYZCommonInit(XYZView *self) {
  // ...
}

- (instancetype)initWithFrame:(CGRect)frame {
    // ...
   XYZCommonInit(self);
   return self;
}
- (instancetype)initWithCoder:(NSCoder *)coder {
    // ...
   XYZCommonInit(self);
   return self;
}
@end

Note:
Could put a bit of discussion in the rationale about how this truly applies to any private selector but in practice we have hit the common initializer case more than anything else. We can even add that if shipping a framework, private functionality of anything publicly exposed for subclassing should potentially avoid private selectors and stick to C-style functions to prevent clients of your framework from unintentionally overriding private functionality.

Convention

• Don't make assumptions about a reverse-dependency's implementation. AKA, don't assume NSApp or NSApp's delegate conforms to a given protocol (even checking for conformance is wrong, because you shouldn't know about
• Provide a delegate property in this case, don't directly access the application delegate. The application delegate could be your delegate, but you shouldn't know or care, only the Application Delegate would know or care in that case.

Rationale

These types of reverse dependencies make it harder to refactor and reorganize code and make components inherently less reusable.

Example

TBD