40

I'm reading a book - Big Nerd Ranch iOS Programming. It says that dot notation is not recommended as it obfuscates code. I am simultaneously watching a Stanford Course for iOS programming and in it he is using dot notation extensively there. What would you recommend? I personally lean to bracket notation more.

Could you please explain how to covert this code to bracket notation?

self.display.text = [self.display.text stringByAppendingString:digit];

As I understand it should be:

[[self display] setText]:[[[self display] text] stringByAppendingString:digit];

Is it correct?

DisplayName
  • 3,093
  • 5
  • 35
  • 42
Dvole
  • 5,725
  • 10
  • 54
  • 87

3 Answers3

65

This is a matter of personal choice. There are those that argue that dot notation makes it unclear that messages are being sent (methods are being called) since it looks just like C-style structure element access. The other side of argument is that dot notation is easier to type, easier to read, and more concise.

As someone who has been writing Objective-C since before dot notation was introduced (in Objective-C 2.0), I can understand the arguments on both sides, but prefer to use dot notation myself. That said, I do think it's important for people beginning with Objective-C to understand that dot notation syntax is converted to standard accessor method calls when compiled. I think the authors of the Big Nerd Ranch book probably have a similar attitude, and that's a big part of why they decided to use bracket notation in the book.

So in short, do what you like best. Both are valid, and the choice between the two is essentially a matter of style. No matter which you choose, make sure you understand that both styles produce equivalent compiled code.

EDIT: I forgot to answer the question about converting dot notation to bracket syntax. You're close, but what you've written is wrong and won't actually compile. It should be: [[self display] setText:[[[self display] text] stringByAppendingString:digit]] . If I were writing it I'd split it into two lines (well, really I'd use dot notation):

NSString *stringWithDigit = [[[self display] text] stringByAppendingString:digit];
[[self display] setText:stringWithDigit];

EDIT 2: It has been more than 3 years since I wrote this answer. I just wanted to note that these days, a great many more Apple framework classes have had things that were previously regular methods converted to @properties (e.g. -[NSArray count]) presumably for better Swift interop. This has led me to use dot notation even more liberally than I used to.

Andrew Madsen
  • 21,309
  • 5
  • 56
  • 97
  • 13
    +1, as a casual Obj-C user I had no idea I could replace 10 million brackets with a few dots. I assumed in most cases they were struct accesses. – user7116 Jul 13 '12 at 16:28
  • @Andrew Madsen is the code I quoted correct? The bracket one. – Dvole Jul 13 '12 at 16:39
  • Sorry I didn't actually answer that part of your question! I've edited my answer. – Andrew Madsen Jul 13 '12 at 17:18
  • 5
    +1 for the answer, but imo dot notation is slightly less expressive. At a split-second-glance, one cannot discern if a line is calling an object, setting a property, or fiddling in KVO/KVC. – isaac Jul 13 '12 at 17:18
  • @isaac, I sort of agree with you. I really don't like it when dot notation is used to call non-property-accessor methods, and never use it that way. When used in KVO/KVC, key paths are strings, and the surrounding @"" makes them easy enough to distinguish (esp. with syntax coloring). – Andrew Madsen Jul 13 '12 at 17:27
  • 2
    @AndrewMadsen +1 As someone thoroughly disgusted by the very idea of using square brackets to perform method invocations in a language based on C, I use dot notation whenever possible. – Sergey Kalinichenko Jul 13 '12 at 18:26
12

Here's my opinion:

You should always use dot notation whenever you're dealing with properties. Not only is it quicker to write (self.foo has less characters than [short foo]) but more importantly it makes chained messages easier to understand. For example:

self.myTextField.text.length

is easier to understand than

[[[self myTextField] text] length]

Additionally, it makes it less likely that you'll mess up the punctuation (Making sure that you have the correct number of brackets is oftentimes a pain).

But, as other people have stated above, ultimately it's personal opinion.

Nosrettap
  • 10,940
  • 23
  • 85
  • 140
6

I know this is an old post but I would like to add a more modern answer.

With the release of swift and the impending demise of our favorite language, the preference should lean towards dot notation. All iOS frameworks have updated their API to favor dot notation (preferring readonly properties in a header to getters). This makes the eventual translation towards swift more fluid.

To be clear, prefer properties for instances where you are exposing getters and/or setters. Luckily Xcode's modern objective-c migration tool will do most of this for you.

Daniel Galasko
  • 23,617
  • 8
  • 77
  • 97
  • One could easily argue exactly the opposite: that using brackets in Objective-C makes it easier to differentiate between the two languages. It's still largely a matter of personal choice, but I see no reason to prefer dot notation in Obj-C simply because it's used in Swift. Obj-C is a different language; it's not morphing into Swift, and there's no point in making your Obj-C code more Swift-y. – Caleb Sep 17 '15 at 17:46
  • 1
    @Caleb so you're suggesting we ignore swift and keep the old, bracket heavy objective C syntax? Despite the fact that all iOS frameworks are making the transition to dot properties? – Daniel Galasko Sep 17 '15 at 21:40
  • Don't see why you would want to go out of your way to "differentiate" your code – Daniel Galasko Sep 17 '15 at 21:41
  • 1
    I'm suggesting that Swift syntax doesn't need to be a consideration when you're choosing an Objective-C style -- there's no advantage to be gained by making your Obj-C code look like Swift. – Caleb Sep 17 '15 at 22:27
  • @Caleb other than building a better API for those who are using Swift? Perhaps what I should elaborate on is that we should start auditing our API to prefer properties vs getters. Any functions will still need to use brackets – Daniel Galasko Sep 18 '15 at 02:16
  • Luckily as of Xcode 6 the modern objective c refactor tool will do this for you http://useyourloaf.com/blog/xcode-6-objective-c-modernization.html – Daniel Galasko Sep 18 '15 at 02:16
  • Properties have been encouraged since 2006 and anyone who's not using them by now is a little behind. But a property is fundamentally just a promise to provide certain accessors. There's no difference between `foo.bar` and `[foo bar]`. The latter doesn't "use properties" less than the former does, and neither would appear in any API (application program *interface*). – Caleb Sep 18 '15 at 14:16
  • Exactly @Caleb, thats why [NSArray count] is now a property. So my argument still stands that it makes sense to "favor" dot notation – Daniel Galasko Sep 18 '15 at 14:19
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/90032/discussion-between-caleb-and-daniel-galasko). – Caleb Sep 18 '15 at 14:20