Everyone has their own style guide and mine has just grown naturally. I didn’t used to do all of these so many of my early posts don’t follow these formats exactly, but I now very much prefer these coding styles.

Also, it annoys me to no end when someone calls there style good and another style bad. I will do no such thing. I will mark the styles as “My style” and “Not my style”. Just because it is “No my style” doesn’t mean it isn’t a good style for you.

Some basic guidelines

• Follow the rules of grammar whenever possible.
• Make code as self-documenting as possible.
• Make code easy to copy and paste.

Indentation

Use four spaces tabs when tabbing. Remember this, scrolling up and down is easier than scrolling side to side.

Do not tab brackets but tab code inside brackets.

My Style

for (i = 0; i < 10; i++)
{
    DoSomething();
}

Not my style

for (i = 0; i < 10; i++)
    {
        DoSomething();
    }

Whitespace

Add spaces after commas in method parameters but don’t space around the parenthesis.
My style

public void DoSomething(string inString, bool inValue)
{
   string a = "a";
   string b = "b";
   SomeWork(a, b);
}

Not my style

public void DoSomething ( string inString, bool inValue )
{
   string a = "a";
   string b = "b";
   SomeWork( a, b );
}

No space when declaring an array.

My Style

string[] myArray = new string[] {"String1", "String2"};

Not my style

string [] myArray = new string [] {"String1", "String2"};

Curly Brackets

Always put the curly brackets on the next line. Why? Think of the brackets as left-most column. The opening bracket should be directly above the closing bracket, in the left-most column. Or think of the brackets as a section you want to isolate from everything else. The brackets (start section) should never share a line. You should be able to easily highlight all the lines in the bracketed section and not include any code outside the brackets.

My Style

for (i = 0; i < 10; i++)
{
    if (SomeBoolCheck())
    {
        DoSomething();
    }
}

Not my style

for (i = 0; i < 10; i++) {
    if (SomeBoolCheck()) {
        DoSomething();
    }
}

Again, in every instance where you use a curly bracket, put it on the next line.

if

Almost always use brackets even if it is only one line.

My Style

if (SomeBoolCheck())
{
    DoSomething();
}

Not my style

if (SomeBoolCheck())
    DoSomething();

The only time I use a one line if statement is when it really is only one line. And when I do this, I always have an empty line afterwards.

My Style

public void DoSomething(object inParam)
{
    if (inParam == null) return;

    DoSomething();
}

Not my style

public void DoSomething(object inParam)
{
    if (inParam == null)
        return;
    DoSomething();
}

Variable names

Member variables or fields

All public variables are in camel case with the first letter uppercase. I feel that having the first letter lowercase is distracting in most instances.

My style

public string FirstName;
public string LastName;

All private member variables start with an underscore and are in camel case with the first letter uppercase.

My style

private string _FirstName;
private string _LastName;

Not my style

private string _firstName;
private string _lastName;

Properties

I don’t really differentiate public or private properties, as I rarely have private properties and in the rare instances where I do, I don’t change the syntax in any way. Also, I always have a space between properties.

My style

public string FirstName {get; set;}

public string LastName {get; set;}

Always use an autoproperty unless you have at least one line of code to add to the get or set.

A Property that must have a manual backing field should have the backing field right under the property. Why, because if you think about it, it is part of the property and if you copy it (or just copy the contents on the lines with and within the brackets), the backing property should come along with the copy and paste.

My Style

public string FirstName
{
    get { return _FirstName; }
    set
    {
        _FirstName = value;
        NotifyPropertyChanged("FirstName");
    }
} private string _FirstName;

Not my style

private string _FirstName;

// .... more code

public string FirstName
{
    get { return _FirstName; }
    set
    {
        _FirstName = value;
        NotifyPropertyChanged("FirstName");
    }
}

Note: In my example, I am using a property for a ViewModel in the MVVM format. I would really prefer the following syntax. Someday, I will figure out how to do this without including 3rd party software.

[NotifyPropertyChanged]
public string FirstName {get; set;}

[NotifyPropertyChanged]
public string LastName {get; set;}

Methods

Naming

Methods should be named very clearly based on what they do. Length is not a problem due to intellisense. For example, imaging you want to have a function that eats a cookie. You would name it as follows. Also, I don’t do anything different for public verses private (or protected or internal) methods. They are all camel case with the first letter uppercase.

public void EatACookie()
{
    // ... code to eat a cookie
}

Parameters

All parameters in functions are in lowercamel case. Remember, having the first letter of a name be lowercase is distracting to me. However, I get by this by and mark the variable with the preposition “in”. In rare cases where I use a ref or an out for a parameter, I use those prepositions where “in” would be.

This also adds an additional benefit of marking the parameter variables differently than internal variables.

My style

public void EatACookie(Cookie inCookie)
{
    // ... code to eat a cookie
}

Not my style

public void EatACookie(Cookie cookie)
{
    // ... code to eat a cookie
}

Variables declared in a method

I basically just go all lowercase using the same name as the object when possible, or the most self documenting variable name as possible.

public void EatACookie(Cookie inCookie)
{
    Mouth mouth = new Mouth()
    mouth.Teeth.Chew(inCookie, 27);
    mouth.Swallow();
}

However, if the word needs camel case, I often add a short tag in front similar to method parameters only I usually use “loc” or “tmp” to mark them as local or temporary variables. Again, I use the same name as the object when possible, or the most self documenting variable name as possible.

My style

public void EatACookie(Cookie inCookie)
{
    CookieMonster tmpCookieMonster = new CookieMonster ()
    tmpCookieMonster.EatCookie(inCookie);
}

Final remarks

I am sure I have more styles I use, and I will add them as I go.