Proper organization of public/protected/private functions in classes

Question

Resharper (paired with StyleCop) has made me a bit of a neat freak when it comes to obeying most of its rules. One of the rulesets (I believe from StyleCop) enforces putting public functions first, then protected static, then protected, then private static, and finally private.

The private functions are typically the ones backing up the functionality of the public functions as helpers. Let's say I have the StyleCop-enforced order of functions below:

public FunctionA
public FunctionB

private FunctionAHelper1
private FunctionAHelper2
private FunctionBHelper1
private FunctionBHelper2

...though that's not so bad, I find myself wanting to keep the supporting private methods close to the function that's calling them, so it looks more like this:

public FunctionA
private FunctionAHelper1
private FunctionAHelper2

public FunctionB
private FunctionBHelper1
private FunctionBHelper2

What have you learned that guided the organization of methods in a class? What is StyleCop's reasoning for wanting the public/protected/private ordering? Does it really come down to a matter of preference, or are there benefits I'm not seeing?

Answer 1

It really comes down to what you prefer, and how you like to navigate your code.

You can order your methods:

• Alphabetically (GetEntityA, GetEntityB, StoreEntityA, ...)
• By functional area (EntityA methods, EntityB methods, ...)
• By classification (Validation methods, Conversion methods, Helper methods, ...)
• By visibility (Public methods, Internal methods, Protected methods, ...)

You could of course combine alphabetically with visibility or whatever you like. I prefer a combination of alphabetically with visibility and for large classes with classification. For DAO classes sometimes functional area).

Answer 2

If you use anything IDE-like, it basically does not matter. You will navigate via the code through the GUI, ordering list of properties, members etc. as you actually need it.

(I believe Code formatting shouldn't be a matter when programming. Of course it must be sane and adhere to company standards, but there are tools doing the formatting automatically.)

Answer 3

It is definitely a style preference, much like the style arguments around where to put the brace, whether there's a space before/after parentheses, empty lines, etc.

Like you, I prefer to keep private functions near the public functions that use them. More specifically, I prefer to group functions by their usage or functionality, rather than alphabetically or visibility.

The latter two feels like they are merely for aesthetic reasons rather than any real organisational benefit considering the prevalent use of IDEs these days, making function navigation a very simple thing.

Yet when you're working or reading up on a certain feature, it's even easier to just use page up and page down as you work, rather than having to function lookup all the time when you want to navigate from a public function to its helper function.

Answer 4

I found the default StyleCop rules to be a horrible pain in the ass. Even after three weeks of using them, I found I could not predict in which order it wanted the various fields, properties and methods.