The C# Code Standard

Finding the structure that works, can call for finding that right balance.

Finding the structure that works, can call for finding that right balance.

(work in progress)

It is often the case that a developer only wants to use your class, not change it — thus you should provide a #region block around the non-public members.

Here is a suggested layout for your C# classes:

public constructors
public and protected properties
public and protected methods
events
explicit interface implementations (or else place these within the preceding blocks)

internal implementation
private and internal constructors
private and internal properties
private and internal methods
private and internal fields

If a region has only one member, then give that member it’s own block with the name of that block, but don’t enclose it with a block giving it’s category — all that achieves is to force the developer to click more times to drill down into it. In fact, if that member consists of only a few lines – forgo the region-block altogether. It would be only syntactic-noise.

If a region has no members, exclude that region completely.

Within each block, the default order should be alphabetical. This is a mild preference; by “default” I mean that if there is any other grouping that makes semantic sense then by all means use that. Methods that turn something ON, should be next to the complementary method that turns that same something OFF. Properties related to technology X could be grouped together (alphabetically, unless some other order makes sense).

Organize overloads from the simplest to the most complex.

Place the Close, or Dispose, methods at the end of the public methods region. Those logically come last, as the final step of using that class.

Event Handlers:

The proper categorization of event-handlers can be a bit more subtle, as these are often private. What if you have event-handlers that are public, and others that are private? It is recommended that for a class that is to be used (ie, called) from other program-components, that you sequester everything that is public/protected into the public interface, and everything else into the “internal implementation”. However, if the class in question is not something that you would normally use externally — as, for example, your MainWindow class, then it does not make as much sense to divide it into public vs private members. The only thing you actually care about, are it’s internal workings. In this case, to have two distinct regions for your event-handlers would only be confusing. In this case it is recommended that you forgo having an “internal implementation” section, and just have the private fields at the end.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s