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

  • 1
    Are you talking about layout in general or using "#regions"?
    – snmcdonald
    Commented Mar 3, 2011 at 13:20
  • 1
    @snmcdonald I use #region tags to define a section
    – Rachel
    Commented Mar 3, 2011 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
    Commented Mar 3, 2011 at 13:37
  • 7
    I start by deleting all #regions Commented Mar 5, 2011 at 6:39
  • 3
    @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
    Commented Oct 13, 2011 at 10:24

10 Answers 10


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


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)

  • 2
    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
    Commented Sep 24, 2010 at 18:55
  • 2
    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
    Commented Mar 5, 2011 at 5:20
  • 1
    @Rachel favour composition.
    – MattDavey
    Commented Oct 13, 2011 at 10:26

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.

  • 1
    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
    Commented Mar 5, 2011 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
    Commented Mar 5, 2011 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. Commented Mar 29, 2011 at 14:08

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.

  • 3
    I find it quite amazing that private, protected, public and published are both ordered alphabetically and encapsulationally and they all start with P! Commented Oct 7, 2010 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. Commented Mar 5, 2011 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
    Commented Feb 3, 2012 at 10:08

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.

  • +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
    Commented Mar 3, 2011 at 18:38

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.


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?

  • 1
    +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
    Commented Feb 3, 2012 at 6:55

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 () { ... }
  • What are "members" at the bottom? To me that's a catchall term for all pieces of a class. Commented Sep 25, 2010 at 19:37
  • @Mason: should be "member variables" to avoid confusion.
    – Skizz
    Commented Sep 27, 2010 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. Commented Mar 3, 2011 at 18:11

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.