views:

90

answers:

3

How did it become convention that there is no whitespace in the declaration of a method?

-(UITableViewCell*)tableView:(UITableView*)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath

It seems like everyone does it, 90% of the examples I see, the generated templates, other people's code, etc., etc. I suspect it's just another vi/emacs ideological thing, but wondered if maybe there was a K&R kind of "root cause" to the behavior.

Me, I like lots of whitespace:

- (UITableViewCell*) tableView: (UITableView*) tableView
         cellForRowAtIndexPath: (NSIndexPath*) indexPath

This seems so much better to me.

+1  A: 

Most selectors are short enough that you don't need to put every argument on it's own line. It needs some getting used to, but without the spaces, the readability then becomes actually much better. Compare:

- (id) actionWithParam: (id) param object: (id) someObject andMore: (id) another

- (id)actionWithParam:(id)param object:(id)someObject andMore:(id)another

In the first line your brain will group stuff like

param object: (id)

which doesn't belong together, while in the second version you got the parameter groups nicely separated by whitespaces. The groups are pretty dense in themselves now, but the colon and parantheses actually are enough to separate name from the parameter and type.

w.m
Thanks for the comment w.m. I can see your point about short selector and type names. Cramming them together does group them unambiguously.Not sure if I agree with how my brain will group things, mine doesn't seem to do any coherent grouping, even with the no-whitespace version, I just spend a lot of time reading it. And it's particularly a problem with long type names, as you see in Cocoa in many classes, particularly the delegate protocols where the first param is an object context, repeated throughout the protocol.
jbm
+1  A: 

I know a lot of code styles take getting used to to be more understandable. In this case I think that Apple's syntax reflects a thought process more than a coding style, not just personal preference.

When I first started using Objective-C I had the same concern. It can be confusing to look at no whitespace in a long line of code. However, once you get a better feel for the syntax, you will notice that even in your example there is whitespace. It's used to separate the segments of the function names from the previous parameter. Once you're there it becomes easier to pick out each segment of the function and it's parameter. Function name segment on the left, param on the right, repeat.

At first I did what you have listed -- spaces after everything. However that ended up being almost as bad as no whitespace. Since there were spaces everywhere they became meaningless. I next tried putting spaces after the colon and after the param, but that didn't seem right either -- the function name and the parameters started to get confusing in some cases. I tried a few other whitespace styles and eventually came back to use apple's standard almost exactly. The only thing I differ on now is the return type -- I prefer to have a space after the + or - and a space after the return type. Even that isn't that big of a deal, being mostly personal preference rather than any specific difficulty. (Having a heavy C/C++ background I like to be able to see the return type at a glance.)

If you keep at it you'll suddenly find yourself liking apple's way over the other. =)

slycrel
A: 

Good practices in Objective-C say than each method should contain a predicate and a sort of description of its parameters (tableView:cellForRowAtIndexPath:) hence the parameters are usually tied up with the previous part of the method name. Hope this makes sense.

Paul Ardeleanu