3 ms·

The idea is that code is written once but read many times. Objective-C's verbose naming make you work a little more when writing it (though a good programmer's

by donmcc 15y ago

The idea is that code is written once but read many times. Objective-C's verbose naming make you work a little more when writing it (though a good programmer's editor or IDE like Xcode or AppCode greatly eases this) but it pays off each time you need to read the code, especially code you're not familiar with. With it's C-based syntax, Objective-C isn't as clean as Python or Ruby, but due to the explicit naming conventions, I think it's more readable than Java or JavaScript.

bunderbunder 15y ago
I've found it pays off at write time too. Having to say something about each parameter when naming a method really helps me to stop and think about what I'm doing every time I add to an object's interface. I'd like to think it ultimately leads to less bloat.
ctide 15y ago
I actually find it much harder to read as a result of it's verbosity. For example, just yesterday I ran into a bug with these 2 lines: if ([[data objectForKey:@"released"] isKindOfClass:[NSNull class]]) { if ([[data objectForKey:@"posterUrl"] isKindOfClass:[NSString class]]) { They weren't right next to each other, and at a glance, I misread to assume they were doing the same thing. There's too much shit in the way of the actual differences (NSNull vs. NSString in this case) that I have a bad tendency to gloss over the details. Coming from ruby, the closest syntactical equivalent: if (data['released'].class == NilClass) { if (data['posterUrl'].class == String) { Is so much clearer to me when glancing through code. That doesn't even touch on how you'd actually write that sort of thing (data['released'].nil?) which is infinitely more concise than either example. I know this is a bit of a contrived example, and I certainly could find better ones. I just find the 120 character long method evocations to consistently blur the details for me, and this just happens to be the freshest instance. To be fair, I've only been doing iOS stuff for about a month. Does this trend reverse after you've been writing obj-c for a while?
- AshFurrow 15y ago
  I've found after a while you get really used to the verbosity. I miss it when I return to other languages. For instance, I look at the first example you posted and I know exactly what it does. It's very natural for me to read.
  - chc 15y ago
    Is it really easier than `data['poster_url'].is_a? String`? I wouldn't call the Objective-C example unreadable, but it's certainly a lot more line noise for not a lot more meaning.
- donmcc 15y ago
  You do get used to it. Because it's a superset of C, Objective-C has all the syntactic noise of C and some of its own. Ruby is certainly more compact, though with its Perl influence, you can write very cryptic Ruby code. You do pay a price in Objective-C in order to have C directly and immediately available. FWIW, extracting nested expressions into local variables helps a lot with nested method calls.
- wvs 15y ago
  Key-value accessors aren't exactly the shining moment of verbose method names (It's even been leaked that 10.8 has dict[key] sugar), but for methods with more parameters, it's much nicer than positional. e.g.: connection:didReceiveResponse: addObserverForName:object:queue:usingBlock: drawAtPoint:forWidth:withFont:minFontSize:actualFontSize:lineBreakMode:baselineAdjustment:
scott_s 15y ago
I don't agree with your reasoning, but part of that is my operating definition of "verbose" is "more words than needed." That is, if you're being verbose, then by definition you're using too many words, which is a stance I find difficult to defend. Personally, once you have more than two humps in your camel case, my eyes have trouble scanning.
- donmcc 15y ago
  True, "verbose" isn't really the correct term, "explicit" better describes Objective-C. Here's an example where I think Objective-C's explicitness is helpful. The Windows API CreateWindow() function call in C: HWND hwnd = CreateWindow("MainWClass", "Sample", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, (HWND) NULL, (HMENU) NULL, hinstance, (LPVOID) NULL); And here's a long method call in Objective-C: NSString *filtered = [unfiltered stringByReplacingOccurrencesOfString:@"verbose" withString:@"explicit" options:NSCaseInsensitiveSearch range:NSMakeRange(0, [unfiltered length])]; Admittedly not equivalent examples, but I couldn't quickly find a Cocoa method call with eleven parameters. My argument is that if you're not intimately familiar with these two calls, CreateWindow() is pretty cryptic. You only get the most general sense of what it's doing without consulting a reference. Objective-C's strange method naming scheme (taken from Smalltalk) makes complex method calls much easier to understand in situ.
  - scott_s 15y ago
    I agree the second example is more understandable, but I think most of that benefit comes from named parameters (a language feature), not the naming convention itself. That is, were the naming up to me, I would prefer: NSString *filtered = [unfiltered replace:@"verbose" with:@"explicit" options:CaseInsensitive range:Range(0, [unfiltered length])]; Of course, I'm making assumptions about what those parameters mean. But I find this much more clear, assuming the intentions are what I think they are.

by donmcc 15y ago

bunderbunder 15y ago

I've found it pays off at write time too. Having to say something about each parameter when naming a method really helps me to stop and think about what I'm doing every time I add to an object's interface. I'd like to think it ultimately leads to less bloat.

ctide 15y ago

I actually find it much harder to read as a result of it's verbosity. For example, just yesterday I ran into a bug with these 2 lines: if ([[data objectForKey:@"released"] isKindOfClass:[NSNull class]]) { if ([[data objectForKey:@"posterUrl"] isKindOfClass:[NSString class]]) { They weren't right next to each other, and at a glance, I misread to assume they were doing the same thing. There's too much shit in the way of the actual differences (NSNull vs. NSString in this case) that I have a bad tendency to gloss over the details. Coming from ruby, the closest syntactical equivalent: if (data['released'].class == NilClass) { if (data['posterUrl'].class == String) { Is so much clearer to me when glancing through code. That doesn't even touch on how you'd actually write that sort of thing (data['released'].nil?) which is infinitely more concise than either example. I know this is a bit of a contrived example, and I certainly could find better ones. I just find the 120 character long method evocations to consistently blur the details for me, and this just happens to be the freshest instance. To be fair, I've only been doing iOS stuff for about a month. Does this trend reverse after you've been writing obj-c for a while?

AshFurrow 15y ago
I've found after a while you get really used to the verbosity. I miss it when I return to other languages. For instance, I look at the first example you posted and I know exactly what it does. It's very natural for me to read.
- chc 15y ago
  Is it really easier than `data['poster_url'].is_a? String`? I wouldn't call the Objective-C example unreadable, but it's certainly a lot more line noise for not a lot more meaning.
donmcc 15y ago
You do get used to it. Because it's a superset of C, Objective-C has all the syntactic noise of C and some of its own. Ruby is certainly more compact, though with its Perl influence, you can write very cryptic Ruby code. You do pay a price in Objective-C in order to have C directly and immediately available. FWIW, extracting nested expressions into local variables helps a lot with nested method calls.
wvs 15y ago
Key-value accessors aren't exactly the shining moment of verbose method names (It's even been leaked that 10.8 has dict[key] sugar), but for methods with more parameters, it's much nicer than positional. e.g.: connection:didReceiveResponse: addObserverForName:object:queue:usingBlock: drawAtPoint:forWidth:withFont:minFontSize:actualFontSize:lineBreakMode:baselineAdjustment:

scott_s 15y ago

I don't agree with your reasoning, but part of that is my operating definition of "verbose" is "more words than needed." That is, if you're being verbose, then by definition you're using too many words, which is a stance I find difficult to defend. Personally, once you have more than two humps in your camel case, my eyes have trouble scanning.

donmcc 15y ago
True, "verbose" isn't really the correct term, "explicit" better describes Objective-C. Here's an example where I think Objective-C's explicitness is helpful. The Windows API CreateWindow() function call in C: HWND hwnd = CreateWindow("MainWClass", "Sample", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, (HWND) NULL, (HMENU) NULL, hinstance, (LPVOID) NULL); And here's a long method call in Objective-C: NSString *filtered = [unfiltered stringByReplacingOccurrencesOfString:@"verbose" withString:@"explicit" options:NSCaseInsensitiveSearch range:NSMakeRange(0, [unfiltered length])]; Admittedly not equivalent examples, but I couldn't quickly find a Cocoa method call with eleven parameters. My argument is that if you're not intimately familiar with these two calls, CreateWindow() is pretty cryptic. You only get the most general sense of what it's doing without consulting a reference. Objective-C's strange method naming scheme (taken from Smalltalk) makes complex method calls much easier to understand in situ.
- scott_s 15y ago
  I agree the second example is more understandable, but I think most of that benefit comes from named parameters (a language feature), not the naming convention itself. That is, were the naming up to me, I would prefer: NSString *filtered = [unfiltered replace:@"verbose" with:@"explicit" options:CaseInsensitive range:Range(0, [unfiltered length])]; Of course, I'm making assumptions about what those parameters mean. But I find this much more clear, assuming the intentions are what I think they are.