Stupid Question 45: How should I organize the code?

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 https://nuget.org/packages/StyleCop.MSBuild.

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. 

class
{
     member declarations (in region, ha!)
     events
     statics
     ctors
     public methods
     internal methods
     private methods
     properties
}

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. 

My favorite:

Class
{
  constants
  static readonly fields (for dependencyProperties)
  fields
  events
  static constructor
  constructors (in ascending order of inheritance and ascending number of params)
  partial methods (rarely used in non-generated code)
  methods
  indexers
  operators
  properties
}
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. 

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. 

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. 

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
Source: https://raw.github.com/gist/3753571/2f3a8702a0fd0ae08f9778956b8efe4d998b4d65/gistfile1.txt