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.
