Clean, Modern Objective-C

All of these things are something you use an automated formatter for, not regard as some kind of &#x27;modern objc&#x27;. I guess people like to focus on pointless stuff like this because it&#x27;s easier to worry about than whether you should use an eventbus or a delegate - you know, actual hard choices.<p>Stylistic stuff like this is not something you need to give rules for. Create an automated formatter, run it on your or others source files, and get back to solving real problems.

I&#x27;m surprised that he provides five versions of the method definition syntax and none of them are what Apple does and what I consider to be the standard:<p><pre><code> - (void)doSomethingWithParameter:(NSString *)parameter;</code></pre>

This and the linked guides claim there is no advantage to using instance variables (preferring properties), but I see at least one advantage: simplicity. When you&#x27;re reading code that uses an instance variable you know exactly what it&#x27;s doing, you don&#x27;t have to check the attributes of the property, or the getter&#x2F;setter implementation, or think about any KVO going on.<p>I&#x27;m not saying this makes instance variables preferable, but there is something to be said for minimising the number of places you need to look when trying to understand a snippet of implementation.

The ridiculous amount of effort that we have to go through to define private properties (just sheer amount of text around them) makes me miss the pre-property days... I still define iVars the old fashioned way. The whole language would do well to have some syntax sugar added akin to Java&#x27;s private, public, protected for properties so we could just go<p>@private NSString <i>dog;<p>@public NSString </i>cat;<p>... Oh Wait! We do, it&#x27;s just that nobody uses it anymore. <a href="http://stackoverflow.com/questions/4869935/objective-c-private-vs-protected-vs-public" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;4869935&#x2F;objective-c-priva...</a><p>Well we have syntax sugar for iVars... I think it&#x27;s so messy putting some properties in the header and some in the implementation file with a private category - come on we can&#x27;t have better syntax than that?

How about taking a look at the Google ObjC style guide? <a href="https://google-styleguide.googlecode.com/svn/trunk/objcguide.xml" rel="nofollow">https:&#x2F;&#x2F;google-styleguide.googlecode.com&#x2F;svn&#x2F;trunk&#x2F;objcguide...</a><p>I&#x27;m not convinced by private properties either. Use ARC and just define your ivars in the implementation.

I&#x27;m still learning Objective-C but it always bothers me a bit when a controller conforms to many protocols. Are there strategies to manage this (other than #pragma mark)?<p>I really like point #4. I&#x27;d take that further and say that most &quot;keyed access&quot; classes should be wrapped in a more domain-specific wrapper class (thinking of NSUserDefaults, and the like).<p>With regards to point #8, Apple actually recommends against naming functions starting with get... also, unless they are property getter overrides. (<a href="https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html#//apple_ref/doc/uid/20001282-BCIGIJJF" rel="nofollow">https:&#x2F;&#x2F;developer.apple.com&#x2F;library&#x2F;mac&#x2F;documentation&#x2F;Cocoa&#x2F;...</a>)<p>Thanks for the article.

My points on Modern Objective-C:<p><pre><code> - Use MVVM and some method of bindings (e.g. ReactiveCocoa) [0] - Split up ViewControllers and DataSources [1] - Split up classes using Categories (I&#x27;ve seen so many blown up AppDelegates) - Use CocoaPods (this should be a given by now) - probably much more I forgot about... </code></pre> oh, and btw: those `@directives` go by the name of `literals`<p>[0] - <a href="http://lmgtfy.com/?q=mvvm+objective-c" rel="nofollow">http:&#x2F;&#x2F;lmgtfy.com&#x2F;?q=mvvm+objective-c</a> [1] - <a href="http://www.objc.io/issue-1/" rel="nofollow">http:&#x2F;&#x2F;www.objc.io&#x2F;issue-1&#x2F;</a>

I&#x27;m guilty of #4, but I think it&#x27;s a judgement thing. If you&#x27;re just going to briefly use the dictionary, I personally think it&#x27;s a waste of time to go to the effort of creating a class. If it&#x27;s core to your program it makes more sense since you can then tap into things like KVO a bit better. And, prior to ARC and automatic synthesis of properties, it made for a ton of boilerplate code.

It&#x27;s a nice little list. My one nitpick is that he referred to to the class extension [1] as an anonymous category and while it also has been called this it&#x27;s generally documented as a class extension by Apple and so it makes sense to call that out so folks can go read about how it actually works.<p>[1] <a href="http://goo.gl/zTu3nA" rel="nofollow">http:&#x2F;&#x2F;goo.gl&#x2F;zTu3nA</a>

In response to point #3, my counter-example is that when you list a method&#x27;s arguments or return type, the parentheses include the star. In other words, the star does not &quot;belong&quot; to the variable in that particular case.<p><pre><code> -(NSData*) myMethod:(NSString*)string; </code></pre> It can really be argued both ways. We&#x27;ve hugged the type everywhere I worked.

Isn&#x27;t it a bad idea to define private&#x2F;protected properties in your implementation file? What if you want to subclass?

Just when the Heck will apple starting making or designing a replacement for Objective C?<p>Until Rust turns to 1.0?

Maybe you should give an obj-c seminar

I am a rookie Objective-C learner and all these are pretty known to me. I now think &quot;probably people are writing worse code than I do&quot;. These are pretty straightforward facts.

Unfortunately I disagree that this is cleaner.<p>Yes its true, you can hack your way to to some idealized notion of objective C.<p>Accessing everything through properties is lame, and it sucks, and it only seems like a good idea if you use ARC because you think it will make it easier to find the retention bugs, it actually makes it harder.<p>Also properties are not the same as private members, although obj C trendists want them to become the same.<p>No, I disagree it takes you further away from object programming not closer.<p>The current trends in objective C are to hack the file syntax to make it seem like its more encapsulated and use properties to make ARC happy.<p>Both are wrong, obj C is a leaky abstraction. Too bad. You will never make it better by making your code harder to read and debug.<p>Yes in obj C inheritance sucks, protocols suck, constants suck, encapsulation sucks, and in the end if you know how to make something, it really doesn&#x27;t matter. Stop obsessing on shit nobody cares about and build something.<p>Even with all your recommendations obj C is a bandaid. But falling off your skateboard can be fun. Live a little.