Take the 2-minute tour ×

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

I currently use

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).

share|improve this question
Are you talking about layout in general or using "#regions"? –  snmcdonald Mar 3 '11 at 13:20
@snmcdonald I use #region tags to define a section –  Rachel Mar 3 '11 at 13:30
Shouldn't this be a community wiki question ? I don't believe there is one standard, and the answer could change depending on the languages. –  Raveline Mar 3 '11 at 13:37
I start by deleting all #regions –  Ed S. Mar 5 '11 at 6:39
@Ed S. +1 because regions are the devil. All they allow you to do is obscure the fact that your code file is too big and needs to be refactored. –  MattDavey Oct 13 '11 at 10:24
add comment

10 Answers

up vote 3 down vote accepted

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).

share|improve this answer
add comment

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)

share|improve this answer
I'm programming in WPF right now and an example of some subregions I would use is a ViewModel which has its public properties split up into UI-Related properties, Commands, Data, etc. This makes it much easier to find what I'm looking for quickly –  Rachel Sep 24 '10 at 18:55
Why not use big comment banners instead of regions? // ----------ViewModel Properties---------- That way you can still see the code (or collapse it with outlining and see the members). Regions are for hiding things. Code shouldn't be hidden, unless it's autogenerated or something. –  Kyralessa Mar 5 '11 at 5:20
@Rachel favour composition. –  MattDavey Oct 13 '11 at 10:26
add comment

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.

share|improve this answer
Here's a macro to collapse-to-definitions but expand regions, in case you're stuck working with people enamored of regions: stackoverflow.com/questions/523220/awesome-visual-studio-macros/… It works well unless you're working with really sick people who put regions inside methods. –  Kyralessa Mar 5 '11 at 5:22
A very useful macro! I am not sure why they did not build it into visual studio, none the less, thank you. –  snmcdonald Mar 5 '11 at 16:12
My boss loves regions, looooves them. He also loves private inner classes and huge methods. Our code has one class with about a dozen regions dividing it up, 3 inner classes, and some methods so long they have a dozen top-level regions inside them, with sub-regions inside those. –  CodexArcanum Mar 29 '11 at 14:08
add comment

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

  TMyClass = class(TBaseClass)
    private fields
    private methods
    protected fields
    protected methods
    protected properties
    public methods
    public properties

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

share|improve this answer
I find it quite amazing that private, protected, public and published are both ordered alphabetically and encapsulationally and they all start with P! –  Peter Turner Oct 7 '10 at 21:04
amusing, I don't. I've always found that it was more natural to list public first, since most users only care about public stuff. –  Matthieu M. Mar 5 '11 at 11:55
I've always found this convention to be a really silly idea. What has visibility got to do with functionality? In any case, I've always used Interfaces to define public functionality, but implemented the Interface as protected on the class. The only items I will consistently group are Published methods and properties for components, and otherwise I always group by Interfaces and inheritance, using multiple visibility keywords as needed. Those items that are unique to the class implementation (Ie: not overrides) should really be listed first. –  S.Robins Feb 3 '12 at 10:08
add comment

I tend to lay them out the following way:

Public fields (usually static constants)
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.

share|improve this answer
+1 for putting private fields at bottom. I group public methods by the interface they implement, and put those that do not implement any interface at the top, right after the constructors/destructors. –  Sjoerd Mar 3 '11 at 18:38
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
+1 - I am surprised that this hadn't been mentioned more prominently. The principle of cohesion also applies to how you lay your code out, and grouping by access modifier is (more often than not) counter productive. –  Daniel B Feb 3 '12 at 6:55
add comment

I currently layout classes like this:

class types
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 () { ... }
share|improve this answer
What are "members" at the bottom? To me that's a catchall term for all pieces of a class. –  Mason Wheeler Sep 25 '10 at 19:37
@Mason: should be "member variables" to avoid confusion. –  Skizz Sep 27 '10 at 9:07
I really don't get grouping things by type like that. What's the difference between a method and a property really? I have never once gone looking for a class' properties, I will however look for logically related code, whether they are properties, methods, whatever. –  Ed S. Mar 3 '11 at 18:11
add comment

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.

share|improve this answer
add comment

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.
share|improve this answer
add comment

Your Answer


