Code organization: separation of private/public methods or step-down rule?

[rhgills]

The existing organization of source files seems to consists of heavy use of pragma marks as separators, dividing methods into categories such as: initialization/dealloc and private methods.

I'm used to following the step-down rule, wherein methods are arranged such that a method definition is found below, and as close to as possible, the first method that calls it. I might annotate individual methods with comments, if helpful. For example, if overriding -(BOOL)isEqual:, I might make a note that that method is originally defined in NSObject.

The main advantages I see when following the step down rule are less jumping around the methods in an individual class and increased understanding.

Naturally, both these approaches conflict. I've rearranged the code to follow the step down rule myself when trying to understand what a particular class does and have usually left it that way after any subsequent refactorings. I feel that we should decide on one of these approaches going forward and stick to it, for consistency.

I'm also going to try and do a better job going forward matching the style of the code as I'm writing it, so you don't have to go back and fix my out-of-place formatting. I don't think Xcode has anything like this, but does AppCode support project level code style settings? For indentation and code generation and the like? I know AppCode has extensive style settings, but I seem to recall that they are global.

[jasperblues]

AppCode does support a project level setting. . . Its possible to check these into the project as well, to save folks trying to match it.

I prefer to stick with the structured approach to laying out classes.

On Sep 1, 2013, at 4:31 AM, Robert Gilliam [email protected] wrote:

The existing organization of source files seems to consists of heavy use of pragma marks as separators, dividing methods into categories such as: initialization/dealloc and private methods.

I'm used to following the step-down rule, wherein methods are arranged such that a method definition is found below, and as close to as possible, the first method that calls it. I might annotate individual methods with comments, if helpful. For example, if overriding -(BOOL)isEqual:, I might make a note that that method is originally defined in NSObject.

The main advantage I see when following the step down rule is less jumping around the methods in an individual class, and I believe it helps comprehension.

Naturally, both these approaches conflict. I've rearranged the code to follow the step down rule myself when trying to understand what a particular class does, and have usually left it that way after any subsequent refactorings. I feel that we should decide on one of these approaches going forward and stick to it, for consistency.

I'm also going to try and do a better job going forward matching the style of the code as I'm writing it, so you don't have to go back and fix my out-of-place formatting. I don't think Xcode has anything like this, but does AppCode support project level code style settings? For indentation and code generation and the like? I know AppCode has extensive style settings, but I seem to recall that they are global.

—
Reply to this email directly or view it on GitHub.

[rhgills]

Got it, structure it is.

And a project level setting sounds fantastic, I'll have to look into that.