1

Is there a standard or accepted code style for whether public or private members / functions come first in a class?

I expected to find a lot on Google regarding this but have found nothing.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Kyle
  • 32,731
  • 39
  • 134
  • 184
  • 1
    There is no one style or pattern. It doesn't matter to the code, only to the readers. – John Saunders Jul 09 '13 at 17:11
  • @JohnSaunders This is interesting to me. I would have expected one to folllow the other so you would know when you have seen all of the public or all of the private members/functions. hmm. – Kyle Jul 09 '13 at 17:14
  • 1
    Why does it matter? Usually, your IDE will help you navigate. I suppose it would help if you were developing using Notepad, emacs, or vi. – John Saunders Jul 09 '13 at 17:16
  • @John Saunders: Well, first off, even within those tools there are ways to navigate very quickly that don't involve the cursor keys or page-up and page-down keys / commands. But secondly, I'd argue that even if one encountered an editor that didn't have power navigation, the best organization scheme would still be by functionality. That is almost surely the scheme that requires the least amount of movement when trying to read or maintain a code base. Any other scheme has you jumping all over the place. – jason Jul 09 '13 at 17:22
  • If you don't intend "best" to be subjective, then that must mean you have some numbers to back this up. Frankly, I use ReSharper, and never notice whether I'm "jumping all over the place" or not unless I look at the line numbers. – John Saunders Jul 09 '13 at 17:24
  • @John Saunders: Of *course* "best" is subjective. I'm not going to pretend otherwise. This is *clearly* opinion territory. – jason Jul 09 '13 at 17:27

6 Answers6

3

Take a look at this SO question. It has the StyleCop Rules Documentation's requirements.

Fairly well used standard.

ASIDE: There is a free plugin for C#. Makes following the rules much simpler when you know what you are doing wrong. It will tell you if you violate the rules and can be set to run during the build step.

Community
  • 1
  • 1
SH-
  • 1,642
  • 10
  • 13
2

There are ordering rules with StyleCop which are useful to follow as a point of standardisation.

devdigital
  • 34,151
  • 9
  • 98
  • 120
1

No this is simply a matter of personal preferences. Just follow your company one if that applies.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Rémi
  • 3,867
  • 5
  • 28
  • 44
1

There are rules enforced by StyleCop that I have seen many people use as a standard.

Frankly, they make sense1, but I don't think it's the best way.

I think things should be grouped by functionality, not by type, or accessibility, or static, etc. I would argue that a scheme that is organized by functionality requires the least amount of navigation when trying to read or maintain a code base. Any other ordering scheme (or *rules) would leave you navigating all over the class as you try to work with it. A conceptual ordering that places things together that make sense will minimize that jumping around. It's about making it easier to understand and work with it. It's a practical perspective, rather than forming rules for the sake of having rules that can be enforced.

1: They make sense in that they are a rule, they appeal to the OCD among us, and they can be enforced by a machine, but who cares if the machine can enforce them? But code is not for the machine, it is for the humans. When I need to understand the code, I don't think to myself "if only I could first understand all the constant fields, and then all the fields, etc." I take a very different approach. I want to see the big picture first, and one thing that is going to assist with that is seeing the code organized by functionality.

jason
  • 236,483
  • 35
  • 423
  • 525
1

As people are saying, the order generally doesn't matter. However, there is one important exception, and that's initializing static fields. You can initialize static fields based on the value of other static fields - it all ends up getting compiled into the static constructor, but in the order that it's written in the code.

For example:

class Program {
    private static int j = 4;
    private static int i = Program.j;

    static void Main(string[] args) {
        Console.WriteLine(Program.i); // 4
    }
}

But:

class Program {
    private static int i = Program.j;
    private static int j = 4;

    static void Main(string[] args) {
        Console.WriteLine(Program.i); // 0
    }
}

So keep this case in mind if you decide to re-shuffle your members around. To be totally safe, you can put the initializations in the static constructor, like:

class Program {
    private static int i;
    private static int j;

    static Program() {
        Program.j = 4;
        Program.i = Program.j;
    }
}
Joe Enos
  • 39,478
  • 11
  • 80
  • 136
0

Here is the Microsoft C# Coding Conventions (C# Programming Guide)

It makes no mention of ordering for public, protected or private functions or members in a class.

I know in my past experience that FxCop had "suggested" that I put my public functions before my private functions, but again not necessarily a standard.

Karl Anderson
  • 34,606
  • 12
  • 65
  • 80