> On 30 May 2015, at 3:22 am, Alex Zavatone <z...@mac.com> wrote:
> 
> // We don't care if this gets long.


My take is that you’re rewriting a well-recognised idiom to solve a 
non-existent problem.

The well-recognised idiom makes it easy to verify it’s correct. Hiding a 
different construct inside a macro obscures that, making it harder to verify 
the code. It’s not “wrong” exactly, just harder to see at a glance that it’s 
right.

The non-existent problem you’re trying to solve is that the gap between a pair 
of braces could get large. So what? Early returns can be another source of 
bugs, so structural purists would tell you that you shouldn’t do that. 
Sometimes I think it’s justified, but not usually worthwhile. Another religious 
issue is whether matching braces should line up or not. Personally I prefer 
that they do, at the cost of an extra line. Because you aren’t doing that, your 
long distance between braces is bothering you, because you’re losing track of 
where it started (I assume that’s why it’s bothering you). If you line up the 
braces that is much less of an issue.

Source code is for humans, so it should be as readable as you can possibly make 
it. Macros often hinder that. Unaligned braces hinder that. Multiple statements 
per line hinder that.

Factoring code helps, so I’d suggest that’s the better way to solve this. (and 
it’s also beneficial when it comes to making sure that -initWithCoder: and 
other initializers that don’t correctly follow the designated initializer rule 
can get access to your common initialization. While this is rarely a problem, I 
did notice that the recent change to encourage the use of -initWithCoder: for 
unpacking NSViews from a nib breaks this long-standing rule and so a common 
init method that both can call is a simple workaround).

—Graham



_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to