7 ms·

I see your Java, and raise you Objective-C: NSString *thing = [NSString stringWithFormat:@"Result: %@", [foo someoneCouldntComeUpWithAShorterNameWithZipcod

I see your Java, and raise you Objective-C: NSString *thing = [NSString stringWithFormat:@"Result: %@", [foo someoneCouldntComeUpWithAShorterNameWithZipcode:08205 name:@"larry" parcels:5]]; NSDictionary *request = [NSDictionary dictionaryWithObjectsAndKeys:@"iphoneapp/0.1", @"User-Agent", @"news.ycombinator.com", @"Host", nil]; This isn't to kick off pet language wars, by the way, just to point out that my OCD tic to wrap to 80 characters has absolutely zero place in Xcode. Or Java.

Groxx 16y ago
disclaimer: I have not tried these. Totally pulling these from a quick googled-refresher of macros. #define withZip someoneCouldntComeUpWithAShorterNameWithZipcode #define dictWith dictionaryWithObjectsAndKeys or #define dictWith NSDictionary dictionaryWithObjectsAndKeys so you can [dictWith: key, value, key, value] :) I forget, does XCode intelligently handle macros? Or does using a macro destroy its helpful features, like code completion? I actually have a "hashWith" utility function for my .NET code. Saves me a ton of ugh-induced headaches.
- Fargren 16y ago
  I haven't worked a lot with XCode, but I remember using macros without problem.
- jedsmith 16y ago
  Doing that is probably fine if you are working alone and nobody will ever read your code. Reading Objective-C is already enough of a challenge without having to context switch to a header just to mentally resolve symbols. Instead of using a macro for the selector: NSDictionary *frob = [NSDictionary macroHere:v1, k1, v0, k0, nil]; It would probably be far more efficient to macro the entire call using C99's variadics: NSDictionary *frob = DICT(v1, k1, v0, k0); Still wouldn't walk that road, personally.
  - leon_ 16y ago
    Yup, macros are a bad idea in that regard. Had to work on a codebase where the prior programmer had fancy defs like _dict k1, v1, k2, v2, k3, v3 dict_ I wasn't too happy about that :/
  - deleted 16y ago
    [deleted]
  - Groxx 16y ago
    The reason I went for the selector is because it makes the macro into essentially a function-typedef. I don't know any languages which allow typedefs to specify things like `Class.short = Class.super_long_name_here`, even though it's essentially the same concept, especially if looked at from a C standpoint. It's a minimally-intelligent text replacement. IMO, something like `[NSDictionary with:key,val,key,val,nil]` is far less brain-taxing than `DICT(key,val,key,val)`. It fits without modifying the language or the syntax, it merely makes something long shorter, and the usage implies it does nothing "shiny" - you even keep the class name you're calling, making it clearer what you should be expecting, and it still allows access to all other parameters without modification or even thinking differently. DICT(...) is ambiguous about what kind of dictionary it's returning.
extension 16y ago
While it can get a bit silly sometimes, I've come to really appreciate the verbosity of Obj-C method calls. Explicit parameter names make them very self-descriptive, and grouping the entire call within brackets makes structure obvious. Compare: canvas.drawImage(kittens.subImage(vec2(10,10),vec2(20,20)),vec2(30,30)) vs [canvas drawImage:[kittens subImageAt:vec2(10,10) withSize:vec2(20,20)] at:vec2(30,30)]
- rtaycher 16y ago
  Yes but some of the examples of obj-c I've seen look ridiculously wordy compared with the smalltalk equivalents (even if you ignore op overloading). (setObject: forKey:) vs (at: put:). for ex.
Stormbringer 16y ago
"just to point out that my OCD tic to wrap to 80 characters has absolutely zero place in Xcode. Or Java." Dude. Are you still using CGA? Unless for your IDE you're running emacs on your wristwatch or phone there's no place for that shit in the real world, and you have no excuse. Ditch that green cathode ray tube, here, have 50c and go buy yourself a real monitor. :D
- glenjamin 16y ago
  Lines longer than 80 chars are harder to scan, and sticking to this rule allows tiling of windows. Maximising code windows on a widescreen is a huge waste. Even with long lines the average line length will be far shorter. This is Guido's reasoning for keeping PEP8's rule to 80 chars.
- berntb 16y ago
  It is fascinating to see people having 24+" monitors -- and seeing ca 30 lines of code on their screen, because of the real estate eaten by their IDEs. To add maiming to injury, these guys write in modern Cobol (a.k.a Java). Not to mention that they can't print the code -- since it is 150+ chars wide(!) -- and browse it at a cafe. (I love my iPad, but It'll be iPad 3 before it is half as nice for browsing code [edit: as paper].) I have about 2 full pages of code on the same size of monitor. Of scripting language. I doubt that I have abnormally bad memory or write too complex code... I just like to be productive. Edit: oK, downvote if you want. But please also add a counter argument for wasting all that screen area?
  - gnosis 16y ago
    "Not to mention that they can't print the code -- since it is 150+ chars wide(!) -- and browse it at a cafe." You can't print code longer than 150 characters wide? Since when?
    - berntb 16y ago
      Sigh, are you trolling or new? OK, I'll answer. The point of printing and browsing code is that it is easier and nicer than to read it on a screen (you'll have a portable with you at the cafe anyway to search, annotate, etc.) If you get lots of broken lines, it isn't readable. Point was, you lose a capability with long lines -- a nice way to go over code. This is important for many of us. Edit: Point jedsmith, write it off as grumpy-old-man syndrome. Sigh, I just can't get that this isn't understood by everyone, anymore.

Groxx 16y ago

disclaimer: I have not tried these. Totally pulling these from a quick googled-refresher of macros. #define withZip someoneCouldntComeUpWithAShorterNameWithZipcode #define dictWith dictionaryWithObjectsAndKeys or #define dictWith NSDictionary dictionaryWithObjectsAndKeys so you can [dictWith: key, value, key, value] :) I forget, does XCode intelligently handle macros? Or does using a macro destroy its helpful features, like code completion? I actually have a "hashWith" utility function for my .NET code. Saves me a ton of ugh-induced headaches.

Fargren 16y ago
I haven't worked a lot with XCode, but I remember using macros without problem.
jedsmith 16y ago
Doing that is probably fine if you are working alone and nobody will ever read your code. Reading Objective-C is already enough of a challenge without having to context switch to a header just to mentally resolve symbols. Instead of using a macro for the selector: NSDictionary *frob = [NSDictionary macroHere:v1, k1, v0, k0, nil]; It would probably be far more efficient to macro the entire call using C99's variadics: NSDictionary *frob = DICT(v1, k1, v0, k0); Still wouldn't walk that road, personally.
- leon_ 16y ago
  Yup, macros are a bad idea in that regard. Had to work on a codebase where the prior programmer had fancy defs like _dict k1, v1, k2, v2, k3, v3 dict_ I wasn't too happy about that :/
- deleted 16y ago
  [deleted]
- Groxx 16y ago
  The reason I went for the selector is because it makes the macro into essentially a function-typedef. I don't know any languages which allow typedefs to specify things like `Class.short = Class.super_long_name_here`, even though it's essentially the same concept, especially if looked at from a C standpoint. It's a minimally-intelligent text replacement. IMO, something like `[NSDictionary with:key,val,key,val,nil]` is far less brain-taxing than `DICT(key,val,key,val)`. It fits without modifying the language or the syntax, it merely makes something long shorter, and the usage implies it does nothing "shiny" - you even keep the class name you're calling, making it clearer what you should be expecting, and it still allows access to all other parameters without modification or even thinking differently. DICT(...) is ambiguous about what kind of dictionary it's returning.

extension 16y ago

While it can get a bit silly sometimes, I've come to really appreciate the verbosity of Obj-C method calls. Explicit parameter names make them very self-descriptive, and grouping the entire call within brackets makes structure obvious. Compare: canvas.drawImage(kittens.subImage(vec2(10,10),vec2(20,20)),vec2(30,30)) vs [canvas drawImage:[kittens subImageAt:vec2(10,10) withSize:vec2(20,20)] at:vec2(30,30)]

rtaycher 16y ago
Yes but some of the examples of obj-c I've seen look ridiculously wordy compared with the smalltalk equivalents (even if you ignore op overloading). (setObject: forKey:) vs (at: put:). for ex.

Stormbringer 16y ago

"just to point out that my OCD tic to wrap to 80 characters has absolutely zero place in Xcode. Or Java." Dude. Are you still using CGA? Unless for your IDE you're running emacs on your wristwatch or phone there's no place for that shit in the real world, and you have no excuse. Ditch that green cathode ray tube, here, have 50c and go buy yourself a real monitor. :D

glenjamin 16y ago
Lines longer than 80 chars are harder to scan, and sticking to this rule allows tiling of windows. Maximising code windows on a widescreen is a huge waste. Even with long lines the average line length will be far shorter. This is Guido's reasoning for keeping PEP8's rule to 80 chars.
berntb 16y ago
It is fascinating to see people having 24+" monitors -- and seeing ca 30 lines of code on their screen, because of the real estate eaten by their IDEs. To add maiming to injury, these guys write in modern Cobol (a.k.a Java). Not to mention that they can't print the code -- since it is 150+ chars wide(!) -- and browse it at a cafe. (I love my iPad, but It'll be iPad 3 before it is half as nice for browsing code [edit: as paper].) I have about 2 full pages of code on the same size of monitor. Of scripting language. I doubt that I have abnormally bad memory or write too complex code... I just like to be productive. Edit: oK, downvote if you want. But please also add a counter argument for wasting all that screen area?
- gnosis 16y ago
  "Not to mention that they can't print the code -- since it is 150+ chars wide(!) -- and browse it at a cafe." You can't print code longer than 150 characters wide? Since when?
  - berntb 16y ago
    Sigh, are you trolling or new? OK, I'll answer. The point of printing and browsing code is that it is easier and nicer than to read it on a screen (you'll have a portable with you at the cafe anyway to search, annotate, etc.) If you get lots of broken lines, it isn't readable. Point was, you lose a capability with long lines -- a nice way to go over code. This is important for many of us. Edit: Point jedsmith, write it off as grumpy-old-man syndrome. Sigh, I just can't get that this isn't understood by everyone, anymore.