How do you sort/group your C# code?

[Gerrit Beuze]

Hi all,

I'm wondering if you how you organize as (in sorting / order) your C# class code:

Do you sort/ group by member type: fields, methods, properties etc.?
If yes: what ordering scheme do yo use?

Do you group members by visibility - and how does that relate to grouping by type?

Where do you insert (nested) types such as enums and delegates in classes
and namespaces? any order?, top, bottom grouped by type?

The reason I ask is that I'm implementing a sorting / rearrange algorithm
in ModelMaker Code Explorer for C# classes and namespaces.

Check for details on ModelMaker Code Explorer:
http://www.modelmakertools.com


Thanks for your feedback,

Gerrit Beuze
ModelMaker Tools

 

[Stu Smith]

Hi all,

I'm wondering if you how you organize as (in sorting / order) your C# class code:

Do you sort/ group by member type: fields, methods, properties etc.?
If yes: what ordering scheme do yo use?

Do you group members by visibility - and how does that relate to grouping by type?

Where do you insert (nested) types such as enums and delegates in classes
and namespaces? any order?, top, bottom grouped by type?

Well the following is how I arrange my files, but please don't feel I'm
suggesting this is the One True Order.

1. Public nested types
2. Constructors (public, protected or private)
3. Public properties
4. Public methods
5. Protected methods
6. Private methods
7. Private nested types
8. Private member fields

My rationale for this is that you read the code like you read a story; you
dig deeper as you read further. Thus public nested types go first because
they are usually used throughout the type. Constructors come next, of all
accessibility, since they give the first indication of the use of the class
(protected? static methods only? standard? etc...). Next comes the rest of
the public and protected stuff (protected really forms part of the client
interface, so it goes with public). You could stop reading there, or dig
deeper into the actual implementation, which is of course last.

1 and 8 usually go in regions. The others are regioned by common
functionality, rather than accessibility.

Hope that's of interest,

Stu

 

[Guest]

1. Nested classes / enums.
2. Static fields.
3. Static methods.
4. Lifecycle (ie. constructor, finalize)
5. Public/Protected Instance fields.
6. Public/Protected Instance properties.
7. Public/Protected Instance methods.
8. Private Instance fields.
9. Private Instance properties.
10. Private Instance methods.

Also I enclose each of these in #region ... #endregion and collapse them all
down before checking a project in.

Chris.

 

[Guest]

Take a look at this article

http://www.c-sharpcorner.com/Code/2003/Aug/UsingRegions.asp

 

[Bill O]

Along these same lines, what do you all use for C# code formatting (code
beautifiers)? Does anyone have any suggestions?

Thank you for your consideration.

 

[Nicholas Paldino [.NET/C# MVP]]

Gerrit,

I think that an important point to make here is that not all
enumerations are nested (nor should they be, generally, there are few
enumerations that really belong as a nested type). The same thing goes with
delegates, although I think that there is more of a case for nested
delegates than there is for nested enumerations.

Also, with the advent of partial classes, I actually will place my
nested code in another file.

For fields, if there is a property that exposes them, then I try and
place the field close to the property. Other than that, I don't take the
time to arrange the properties and methods in any particular order. I
usually have my code factored out to a degree where I do not have insanely
huge class files (and if I did, they are just going to be listed all
alphabetically in the project view, or reflector anyways).

 

[Nicholas Paldino [.NET/C# MVP]]

Bill,

With VS.NET 2005, I use just the IDE. There is a huge number of options
now regarding formatting of code. There is little need for me to beautify
it, because the IDE goes to great lengths to get it right the first time.

 

[Bob Grommes]

If you're going to provide a generally usable tool you will need to allow
the developer to define what order they want this stuff in. It's a personal
or team decision, very individual, and there is no one "right" way and
probably not any one "most commonly used" way.

I do group methods alphabetically within a particular visibility -- public,
then protected, then private. Not everyone will do that, but I'm sure a lot
of folks do.

--Bob

 

[Drebin]

I would say there is probably one "commonly used" process, which is putting
variables/constants (even within a protection-level grouping) - at the top
of a class/procedure. Aside from that, everything is fair game!!

 

[Daniel O'Connell [C# MVP]]

I would say there is probably one "commonly used" process, which is putting
variables/constants (even within a protection-level grouping) - at the top
of a class/procedure. Aside from that, everything is fair game!!

You would be wrong.

It isn't uncommon, by any means, to group by overall functionality. For a
minor eaxmple, I happen to often declare fields with wrapping properties. I
doubt I'm alone in this regard.

Also, since I group methods and properties by common functionality(that is,
MethodA and MethodA's helpers and overloads) into one group, fields unique
to those method would be contained within that group as well.

In procedures I declare variables at visibility level much of the time(that
is at teh top of the *block* they are used in, not nessecerily the procedure
itself), but I am certainly not shy about declaring one in-code if it is in
use for only a few lines. And I *know* I'm not alone on that.

 

[Drebin]

Wow. I wouldn't have thought I deserved that. Nice.

 

[Nicholas Paldino [.NET/C# MVP]]

Drebin,

I wouldn't have been as forceful, but I have to agree with much of what
Daniel said (as it is the way I find myself organizing my code).

 

[Daniel O'Connell [C# MVP]]

Drebin,

I wouldn't have been as forceful, but I have to agree with much of what
Daniel said (as it is the way I find myself organizing my code).

Hrmm, I didn't think I *was* being forceful. Certainly wasn't trying to be.
Is it that people expect me to be harsh(there is plenty of history to
support that) or does my writing simply come off that way?