Best practice: ordering of public/protected/private within the class definition?

Question

I am starting a new project from the ground up and want it to be clean / have good coding standards. In what order do the seasoned developers on here like to lay things out within a class?

A : 1) public methods 2) private methods 3) public vars 4) private vars

B : 1) public vars 2) private vars 3) public methods 4) private methods

C : 1) public vars 2) public methods 3) private methods 4)private vars

I generally like to put public static vars at the top, but then would a public static method be listed ahead of your constructor, or should the constructor always be listed first? That sort of thing...

I know it's finnicky but I just wondered: what are best practices for this?

PS: no I don't use Cc#. I know. I'm a luddite.

Solution 1

In Clean Code, Robert C. Martin advises coders to always put member variables at the top of the class (constants first, then private members) and methods should be ordered in such a way so that they read like a story that doesn't cause the reader to need to jump around the code too much. This is a more sensible way to organize code rather than by access modifier.

Solution 2

The best practice is to be consistent.

Personally, I prefer putting public methods first, followed by protected methods, following by private methods. Member data should in general always be private or protected, unless you have a good reason for it not to be so.

My rationale for putting public methods at the top is that it defines the interface for your class, so anyone perusing your header file should be able to see this information immediately.

In general, private and protected members are less important to most people looking at the header file, unless they are considering modifying the internals of the class. Keeping them "out of the way" ensures this information is maintained only on a need to know basis, one of the more important aspects of encapsulation.

Solution 3

Personally I like to have public at top, protected and then private. The reason for this is that when somebody cracks open the header he/she sees what he/she can access first, then more details as he/she scrolls down.

One should not have to look at the implementation details of a class in order to use it, then the class design is not done well.

Solution 4

I think I have a different philosophy on this than most. I prefer to group related items together. I can't stand having to jump around to work with a class. The code should flow and using a rather artificial ordering based on accessibility (public, private, protected etc. ) or instance versus static or member versus property versus function doesn't help keep a nice flow. So if I nave a public method Method that is implemented by private helper methods HelperMethodA, HelperMethodB etc. then rather than have these method far apart from each other in the file, I will keep them close to each other. Similarly, if i have an instance method that is implemented by a static method, I will group these together too.

So my classes often look like this:

class MyClass {
    public string Method(int a) {
        return HelperMethodA(a) + HelperMethodB(this.SomeStringMember);
    }

    string HelperMethodA(int a) { // returns some string }

    string HelperMethodB(string s) { // returns some string }

    public bool Equals(MyClass other) { return MyClass.Equals(this, other); }

    public static bool Equals(MyClass left, MyClass right) { // return some bool }

    public double SomeCalculation(double x, double y) {
        if(x < 0) throw new ArgumentOutOfRangeException("x");
        return DoSomeCalculation(x, y); 
    }

    const double aConstant;
    const double anotherConstant;
    double DoSomeCalculation(double x, double y) {
        return Math.Pow(aConstant, x) * Math.Sin(y) 
            + this.SomeDoubleMember * anotherConstant;
    }       
}

Solution 5

This would be my ordering

1. Static Variables
2. Static Methods
3. Public Variables
4. Protected Variables
5. Private Variables
6. Constructors
7. Public Methods
8. Protected Methods
9. Private Methods

I use the following rules:

• static before anything
• variables before constructors before methods (i consider constructors to be in the category of methods)
• public before protected before private

The idea is that you define the object (the data), before the behaviours (methods). Statics need to be separated because they aren't really part of the object, nor it's behaviour.

View more solutions

Comments

[Ether]

There's nothing wrong with not using C#. I've never written a stitch of C# in all my years as a professional developer. Use whatever language is appropriate to the task, and tell anyone who says anything different where they can go stick it!

[Michael Freidgeim]

Possible duplicate of stackoverflow.com/questions/150479/…

[tempname]

thank you barkmadley... that's interesting! that you would put 4 and 5 before constructor. I will definitely think about that

[tempname]

LeopardSkikPBH, I totally agree... that makes sense! I guess I have been confused as to whether within that, var or funcs take precedence. Thanks!

[jason]

I do not agree that the best practice is to be consistent. There are a lot of ways to consistently write unreadable, unmaintable code.

[tempname]

Hey - a 'tab-spacer' after my own heart! :-) I'm not obsessive compulsive. Honest I'm not!

[JonDrnek]

@Jason that's like saying it's not best practice to stay on your side of the road because you can still have accidents there.

[LeopardSkinPillBoxHat]

@Jason - Maybe I should have been more clear. In this particular, fairly subjective case (ordering of methods) I think the best practice is to be consistent. Everyone will have opinions about the best way to order things, but if you're consistent by nature it should be fairly maintainable. I agree that "be consistent" is not always the best practice for all areas of code, especially when you consider the poor code quality you often have to deal with.

[jason]

@Rex M: No, what I said is not akin to your interpretation at all. My point is that merely being consistent is not a strong argument in this case. For some cases consistency is fine (e.g., placement of braces). But the choices here actually affect the readability of code. Thus, an argument stronger than consistency is needed.

[Dean J]

I've had good luck also adding: getters/setters last. It helps the classes feel less bulky, to me.

[INF.TA]

I agree. My normal mode of navigating the members in a file is to use a tool built into whichever IDE or editor I am using. The actual grouping of the members becomes secondary. However, I agree that members should be grouped to avoid pure random ordering, and I use resharper do the grouping and ordering automatically.

[VitalyB]

What about constructors?

[Asaph]

Constructors at the top, right after the member variables. In OOP, execution begins with object instantiation.

[2xMax]

@Asaph, do you remember the chapter?

[VitalyB]

What if you initialize a field with a function? Does it mean that some functions should be above fields? Should you prefer consistency or story-like readability?

[Kenny Hung]

Causing the reader to jump around the code too much probably needs to be balanced with forcing the reader to read all the nitty-gritty detail of private methods. The newspaper metaphor is probably misunderstood in that your public methods should represent broadly what your class does, and your private methods supply the details (almost like a footnote that you can refer to if you need to).

[Carlton]

Like this order although having static methods near the top is interesting. I worked with a developer that put private variables at the bottom, I could see the idea but it didn't feel right

[mfaani]

I'm confused. You said: (constants first, then private members). OK. Where do the public members go then?

[Pierre Gillet]

@Honey They would go right after the constants and the private members. So that would be in the following order : Constants, private members, public members.

[Welcor]

No C. Martin doesnt strictly say it like that. he says put them at the top, but that may depend on the language. important is to put them where people expect them. Java: at the top (all his examples are in java), C+++ at the end. And he makes no assumption about const, public or private members. he just talks about "instance variables" when he talks about class wide variables in his book.

[Shai Alon]

What about finals? where are they in that order - with final and without?

[Seideun]

In my practice this method quickly fails. Usually a class is very coherent and multiple methods will be using the same set of variables.