Sep 152012
 September 15, 2012  Posted by at 11:36 pm Not So Stupid Questions, Uncategorized  Add comments

[To celebrate my first year of programming I will ask a ‘stupid’ questions daily on my blog for a year, to make sure I learn at least 365 new things during my second year as a developer]

How to best organize the code?

How to best organize the code?

The last question, Stupid Question 44: Should I use regions in my code? has gotten 30 comments so far, so it seems suitable to have a question that is related.
I will admit that I haven’t been that ‘organized’, and my code is generally not organized in any particular way. Usually you would find the constructor at the top, followed by properties and (belonging) fields (when using properties backed up by a private field), and then methods. I haven’t put much thought into how the code should be organized, but I have a feeling I should. Specially after the last question, and the super-duper comments the question (and answer) got.

How do you do? And what do you consider to be best practice (and why)?

  8 Responses to “Stupid Question 45: How should I organize the code?”

  1. For detailed, nitty gritty, organisation of source code, the first thing I’d recommend doing is using StyleCop. Many teams use the out of the box rules as a standard and even if you don’t agree with all the rules, it gives you a good starting point, since you can switch off rules you don’t want and even write your own ones. It is possible to install StyleCop on your machine and have it as a VS addin for on-demand analysis, but I recommend that you don’t do this, and rather install StyleCop.MSBuild into your project from NuGet so that your code is checked every time you compile (the checking is generally very fast). See

    Bias alert – I’m the author of the StyleCop.MSBuild package. I’m not the author of StyleCop, but I am responsible for packaging it up like this so it can be dropped into a .csproj via NuGet.

  2. class
    member declarations (in region, ha!)
    public methods
    internal methods
    private methods

    In all the code I’ve written in the past 10 years or so (200K lines of C# at least) I use this strict rule. Paid off well. Organize your code according to a set of rules you choose, doesn’t matter which ones, at least pick a way to organize the code. Same goes for naming scheme / coding scheme (e.g. { at new line, always {} around if/for clauses, _ instead of m_ prefix for members, etc.

  3. My favorite:

    static readonly fields (for dependencyProperties)
    static constructor
    constructors (in ascending order of inheritance and ascending number of params)
    partial methods (rarely used in non-generated code)
    Within each group sorted alphabetically.

    If a group of methods should stay together, the naming should express this and make the alpha sort keep them together.

    The explicit and implicit interface implementations go together. When searching for a member (for example GetEnumerator), I must not need to know if it’s explicit.

    All accessibilities must go together: when looking for a method I must not need to know it’s accessibility.

    The static readonly WPF fields are a separate category, because they are more an expression of metadata than actual code. Nowadays I tend to refactor the dependency stuff into a separate generated partial.

  4. I used StyleCop on a few projects, made some stuff that was 100% StyleCop clean and it is a pretty good learning exercise which helps form your own, better educated opinions on things, like ordering of member kinds in a class. Right now I try to keep things ordered roughly as StyleCop recommends except for keeping dependency properties with related members and properties with backing fields close together. It’s a waste of time though to apply fascist approach to code organization. Keeping it tidy – yes. Strict rules and using tools to enforce them is form over function.

  5. Regardless of what you do, consistency is the key. Make sure you do it the same throughout the codebase so anyone can pick it up and get it 🙂

    • Simon has it right: the most important thing is consistency. ‘Be Consistent’ is the number one software development principle I follow.

      It’s no big deal to choose an arrangement… you’re not locked into it. Using a productivity tool like Telerik JustCode, you can set up the organizational structure you prefer and have it automatically rearrange everything.

    • Very true. That’s primarily what I see StyleCop as – a consistency tool, rather than a ‘correctness’ tool. The reason I like StyleCop (and sticking as much as possible to the default ruleset), is that it’s an external standard which can be used industry-wide. I.e. the more individuals and teams that use it, the easier it is to pick up anyone’s code anywhere.

  6. Maybe its not structure as such but a valid point from a extremely experienced developer:

    “Polite code is like a well written newspaper article. It allows you to bail out early. A well written article has a
    headline, a synopsis, and a set of paragraphs that begin with the high level concepts and get more and more detailed as you
    read through the article. At any point you can decide: “I get it! I don’t need to read further.” Indeed, this is how most
    people read newspapers or magazines. The articles are polite, because they allow you to get out quickly.”

    Robert C Martin

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



What is 3 + 11 ?
Please leave these two fields as-is:
IMPORTANT! To be able to proceed, you need to solve the following simple math (so we know that you are a human) :-)