How do you normally layout a class's regions?

Question

I was wondering if there was a standard for laying out a class's regions.

I currently use

Fields
Constructor
Properties
Public Methods
Private Methods

Fields being Private Properties and Properties being the public ones. I'll normally use subregions within that if needed, or will occasionally add other regions below (such as interface or baseClass members).

Answer 1

Class-Related Enums or occasionally structs/pure-data classes (above actual class definition)

---Class definition---

Private members

CTORs/DTORs if the language has DTORs

Public properties

Utility methods (private or protected methods with small-scope)

Class functionality (May be divided into multiple regions depending on scope of class).

Answer 2

Sub Regions? Does your class have a Single Responsibility? (implicit in that ... my answer is "Rarely any regions, except maybe to group properties, constructors and methods"... but even then, I don't use it that much)

Answer 3

I just wanted to confirm that you meant "#regions" and not class layout in general.

I am surprised no one has mentioned to avoid using regions. I understand the OP wants to take a poll on laying out regions, but I'd like to raise an alternative view point.

I avoid regions. I like to see the code I am working with. If you find it difficult to find what you are looking for then use code folding and group similar class constructs together.

Why do I hate regions? CTRL+M,L and CTRL+M,O will toggle code folding. However, when collapsing it hides the entire region. I only need to collapse methods/properties/comments.

If there are too many regions maybe its a code smell and your class is doing too much work. Jeff Atwood provides a good post on regions which is worth a read.

My favourite quote on #regions:

No, I will not use #regions. And no, I DO NOT NEGOTIATE WITH TERRORISTS. Shut up.

-Jeff Atwood

That being said, I know many programmers insist on using them. This question is a subjective. I'd just thought I would offer an alternative.

Answer 4

It varies from language to language. Since I'm a Delphi coder, I tend to follow the Delphi standard convention, which looks like this:

type
  TMyClass = class(TBaseClass)
  private
    private fields
    private methods
  protected
    protected fields
    protected methods
    protected properties
  public
    constructor(s)
    destructor
    public methods
    public properties
  end;

I find it a good way to organize information that's easy to read and understand.

Answer 5

I tend to lay them out the following way:

Public fields (usually static constants)
Constructors
Public methods
Private methods
Private fields

Haven't used a language which uses Properties so that's why those are not laid out. I put private methods and fields at the bottom because if someone else is using this file in their code, they should only need to concern themselves with the API, which is the public stuff. And all text editors I know of, and even IDEs, sets the cursor at the top when opening files.

Answer 6

It's a judgement call for me. I use regions when they are needed for readability.

I also use a different color in my Visual Studio color scheme (currently a dark red) to make them stand out from the rest of the code.

---

An example of where I might use a #region: If I write a test method for a unit test that requires a multi-line snippet of XML, the XML string will break the usual indentation (since it starts along the left-hand margin of the code window. To hide the ugliness, I will wrap it in a #region, so that I can collapse it.

Answer 7

Bob Martin's Clean Code book dedicates the entire 5th chapter to formatting. There are a couple of key points that I feel summarize it nicely.

• Most attempts to group variables and methods by visibility and cleanliness Not make a lot of sense, and cause you to navigate around the code a lot.
• Keeping methods which call each other vertically close reduces the amount of navigation you need to do, and makes it easier to find things.
• Your train of thought isn't going to be broken if you have to stop and think "which region does this bit of code belong in?" every few minutes.
• Instance variables should usually be few, and likely to be used everywhere, therefore they belong at the top of the class where they will be easiest to locate. Variables and declarations that will only be used by one method need to exist inside that method. If used by only a couple of methods, then they should be vertically close but above the few methods that are using them.

Keeping your code arranged with commonly interacting elements vertically close together effectively removes any need to create specific regions. If your code is so long that it requires regions to hide a lot of code, then perhaps that is a code smell indicating that the class is trying to do too much. Perhaps some of the functionality can be moved out to a utility class, or pushed up to an ancestor.

If you need to "hide" the code because it's too long or too "ugly", then you've probably got bigger problems to worry about than whether or not to use regions. Personally I never need to use them, and when working on someone else's code, I find I always need to open them all up anyway, so why bother?

Answer 8

I currently layout classes like this:

class types
constructors
destructor
accessors
methods
properties (where properties are present in the language)
member variables

and then prefix the access level to each declaration (sort of, sometimes group by access). I used to do top level grouping by access, but at somepoint, I don't know when, it didn't work quite as well as the above. For example in C++/CLI (which I'm forced to use at the moment :-( ) you can do this, which messes up the grouping-by-access:

public: property int SomeProperty
{
private: void set (int value) { ... }
public: int get () { ... }
}

Answer 9

Lunatic fringe answer: I don't, at least when it comes to C#. Between Visual Studio and R# I can magically navigate to any member or implementation so there isn't any point in obsessing about this stuff; just start typing where the cursor is.

Answer 10

Like Wyatt and a couple other answers, I also generally avoid the use of regions. Regions have one purpose; to hide code you don't want to have to look at. If you have a lot of code in a class you don't want to have to look at, and thus you need a lot of regions to allow you to collapse said code, then you probably have too much code in the class. ReSharper doesn't respect regions when deciding where to place new code, unless it created the region (which it does for interface implementations).

The one use of regions that I find acceptable is to hide "unavoidably ugly" code; code which deals with specific implementation details that can't be well-architected internally to current standards. This is usually advanced, esoteric code that should generally not be messed with by the average junior programmer once written. These are things like:

• Certain built-in interface implementations (IDisposable, IConvertible, sometimes IEnumerable or IComparable as they require generic and non-generic implementations)
• Embedded P/Invoke externs and related structures.
• Finalizers/destructors (usually goes with IDisposable)
• Hooks to unmanaged memory/pointers/"unsafe" code.