

Clean, Modern Objective-C - lyinsteve
http://harlanhaskins.com/2014/02/20/clean-modern-objective-c.html

======
RyanZAG
All of these things are something you use an automated formatter for, not
regard as some kind of 'modern objc'. I guess people like to focus on
pointless stuff like this because it's easier to worry about than whether you
should use an eventbus or a delegate - you know, actual hard choices.

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.

~~~
lyinsteve
You're right to an extent, but I don't think "Run your code through a
formatter when you're done hacking it together" is a viable, maintainable, or
scalable policy. Especially not for enterprise or team based workflows.

Also, #'s 1, 2, 4, and to a certain extent 8 are more questions of design
pattern than 'style'.

~~~
RyanZAG
_> 2\. Use consistent spacing and use whitespace liberally._

The very definition of a formatting bikeshed.

 _> 1\. No instance variables._

I'm not convinced here - he certainly doesn't explain why you shouldn't use
them. I guess he likes to use _self.var_ rather than _var_ \- but it's
important to note that this does have some performance implications.

 _> 4\. Modularize and model._

I'll give you 4 though - using compiler recognizable types is always a boon.
I'm not sure if anybody really needs to be told to modularize and model, most
people would understand that without being told. It does lock-in your public
API though, making changes to a library require updating all apps that use the
library. Meanwhile, adding a new field into a dict means existing apps can
upgrade the library easily. Still, I'd definitely agree that types are always
a better bet in the long run.

~~~
lyinsteve
Whoops, sorry, I meant 1, 4, 5, and 8. You're right about 2.

------
zefhous
I'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:

    
    
        - (void)doSomethingWithParameter:(NSString *)parameter;

~~~
rbritton
That's what I use as well. In Apple's frameworks I've found them to be very
inconsistent between different areas though.

~~~
mpweiher
Maybe because these things simply don't matter.

Worse than that, they distract from things that do.

Bike shed?

------
jsankey
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're reading code that uses an instance variable you know
exactly what it's doing, you don't have to check the attributes of the
property, or the getter/setter implementation, or think about any KVO going
on.

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

~~~
overcyn
Exactly!!!! So much of objc programming is about maintaining internal state.
Dot syntax and automatically synthesized properties just obfuscates whats
actually going on.

IMO you should always be accessing the ivar directly unless you have a
specific reason not to.

------
WoodenChair
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's private,
public, protected for properties so we could just go

@private NSString _dog;

@public NSString _cat;

... Oh Wait! We do, it's just that nobody uses it anymore.
[http://stackoverflow.com/questions/4869935/objective-c-
priva...](http://stackoverflow.com/questions/4869935/objective-c-private-vs-
protected-vs-public)

Well we have syntax sugar for iVars... I think it's so messy putting some
properties in the header and some in the implementation file with a private
category - come on we can't have better syntax than that?

~~~
dilap
Having public things be in the header and private things in the .m seems
exactly right! The header should only expose the public interface, not the
implementation details, no?

(On the other hand, defining _properties_ in an anon category, instead of just
plain old instance variables in the .m, seems pointless to me -- why have a
layer of indirection for the class to access _itself_?)

~~~
bitserf
I'm a heavy user of properties in other languages like C#, but in Objective C,
to define the anonymous category with all the property ceremony and verbiage,
feels...excessive...if all you need is some private state, and you don't care
about generated accessors or KVO.

Why are ivars bad, exactly? They're a lot more succinct if you don't actually
need what properties give you.

~~~
dilap
Right, exactly.

------
oesmith
How about taking a look at the Google ObjC style guide? [https://google-
styleguide.googlecode.com/svn/trunk/objcguide...](https://google-
styleguide.googlecode.com/svn/trunk/objcguide.xml)

I'm not convinced by private properties either. Use ARC and just define your
ivars in the implementation.

------
jeremy_wiebe
I'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)?

I really like point #4. I'd take that further and say that most "keyed access"
classes should be wrapped in a more domain-specific wrapper class (thinking of
NSUserDefaults, and the like).

With regards to point #8, Apple actually recommends against naming functions
starting with get... also, unless they are property getter overrides.
([https://developer.apple.com/library/mac/documentation/Cocoa/...](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html#//apple_ref/doc/uid/20001282-BCIGIJJF))

Thanks for the article.

~~~
weaksauce
the only other strategy I have seen is to instantiate handlers for the sub
concerns. so set self.tv.delegate = myTVDelegate; or something like that.

Apple warns against it because it goes against key value coding I think. I am
kinda on the I wish they had a consistent prefix for stuff. maybe it's just my
feeble mind, but I like to have the code completion remind me of what's
available. the sometimes inconsistent naming conventions in different classes
makes it tough to remember all the nuances when you don't use them every day.

------
stigi
My points on Modern Objective-C:

    
    
      - Use MVVM and some method of bindings (e.g. ReactiveCocoa) [0]  
      - Split up ViewControllers and DataSources [1]  
      - Split up classes using Categories (I've seen so many blown up AppDelegates)
      - Use CocoaPods (this should be a given by now)
      - probably much more I forgot about...
    

oh, and btw: those `@directives` go by the name of `literals`

[0] -
[http://lmgtfy.com/?q=mvvm+objective-c](http://lmgtfy.com/?q=mvvm+objective-c)
[1] - [http://www.objc.io/issue-1/](http://www.objc.io/issue-1/)

~~~
lyinsteve
-I've heard a lot about ReactiveCocoa recently, but I haven't had a chance to try it. Maybe I should. And maybe I will!

\- I'm super guilty of just handling everything in AppDelegate (notifications,
URI schemes, etc.) I need to work on this.

\- CocoaPods are the greatest

~~~
greatsuccess
Build some stuff with Reactive Cocoa before you jump on that bandwagon. It
pollutes the stack of everything it touches and its not very useful unless you
use it pervasively...

~~~
chromejs10
I agree completely. Its use case is highly specialized and all it does is make
a bunch of code nicely split up into methods and crams it into fewer methods
with a ton of blocks. Even the example of "before" and "after" on the github
page shows that how complicated it makes things look.

------
rbritton
I'm guilty of #4, but I think it's a judgement thing. If you're just going to
briefly use the dictionary, I personally think it's a waste of time to go to
the effort of creating a class. If it'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.

------
andymoe
It'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'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.

[1] [http://goo.gl/zTu3nA](http://goo.gl/zTu3nA)

~~~
lyinsteve
You're right. I'll update it to include both definitions in the morning.

------
archagon
In response to point #3, my counter-example is that when you list a method's
arguments or return type, the parentheses include the star. In other words,
the star does not "belong" to the variable in that particular case.

    
    
      -(NSData*) myMethod:(NSString*)string;
    

It can really be argued both ways. We've hugged the type everywhere I worked.

~~~
greatsuccess
I agreed with you for about ten years, and then I stopped doing that because
of the OPs example but also because idiomatic c and c++ are written this way
and I just decided to stop swimming upstream after reading enough of it.

But it can be very confusing when dealing with dereferences. So I feel you
there. Doing C for 15 years you just get used to it.

~~~
informatimago
The OPs example only shows that you should never declare two variables on the
same line! This is a rule that's as old as programming, even.

    
    
      int* a;
      int  b;

------
archagon
Isn't it a bad idea to define private/protected properties in your
implementation file? What if you want to subclass?

~~~
chromejs10
You'll have to redefine the properties in the subclass's class and specify
@dynamic so that it knows the properties were synthesized in the parent class

~~~
archagon
I've experimented with putting the category in a private, implementors-only
header file and it seemed to work fine. But I'm not sure if that's canonical.

------
ksec
Just when the Heck will apple starting making or designing a replacement for
Objective C?

Until Rust turns to 1.0?

------
gambogi
Maybe you should give an obj-c seminar

~~~
lyinsteve
I'm working on it!

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

------
greatsuccess
Unfortunately I disagree that this is cleaner.

Yes its true, you can hack your way to to some idealized notion of objective
C.

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.

Also properties are not the same as private members, although obj C trendists
want them to become the same.

No, I disagree it takes you further away from object programming not closer.

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.

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.

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't
matter. Stop obsessing on shit nobody cares about and build something.

Even with all your recommendations obj C is a bandaid. But falling off your
skateboard can be fun. Live a little.

