Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clean, Modern Objective-C

harlanhaskins.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: Clean, Modern Objective-C

#41

Post by adamnemecek »

lyinsteve wrote: post #13
RyanZAG wrote: post #12

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 s…

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

Why isn't it a viable, maintainable or scalable policy? Can't you setup a git hook to do it?

Re: Clean, Modern Objective-C

#42

Post by frou_dh »

dilap wrote: post #27
WoodenChair wrote: post #17

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…

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 ?)

If we take "should" and run with it then there should be no archaic header files at all and instead a.. gasp.. real module system :-)

Re: Clean, Modern Objective-C

#43

Post by RyanZAG »

lyinsteve wrote: post #13
RyanZAG wrote: post #12

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 s…

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

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

Re: Clean, Modern Objective-C

#44

Post by informatimago »

greatsuccess wrote: post #31
archagon wrote: post #28

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.

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.

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;

Re: Clean, Modern Objective-C

#45

Post by letzjuc »

lyinsteve wrote: post #13
RyanZAG wrote: post #12

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 s…

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

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

Just hook clang-format or clang-tidy with your build system. A lot of projects do it.

You will be surprised how inconsistent people actually are, even in project where almost everyone is sticking to these practices at 100%. And the larger the project, the worse it gets (most people are inconsistent in different ways).

The only way to get this right is to either produce hard errors when they are violated (e.g. your code won't compile, or won't be committed) or do it automatically. clang-tidy is just the way to go.

Re: Clean, Modern Objective-C

#46

Post by mpweiher »

rbritton wrote: post #4
zefhous wrote: post #2

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;

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

Maybe because these things simply don't matter.

Worse than that, they distract from things that do.

Bike shed?

Re: Clean, Modern Objective-C

#47

Post by lyinsteve »

RyanZAG wrote: post #43
lyinsteve wrote: post #13

Earlier quoted context omitted.

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

> 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 recognizab…

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

Re: Clean, Modern Objective-C

#48

Post by dilap »

bitserf wrote: post #33
dilap wrote: post #27

Earlier quoted context omitted.

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 ?)

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.

Right, exactly.
Post reply on HN