Unlike most coding standards, ours does not strive to be restrictive or overly cumbersome. Instead it focuses on the most important things to standardize. Because of this, some may think there are omissions, while in fact such omissions may be intentional.
All warnings should be eliminated so that a build is clean. This allows any new warnings to be easily seen, assessed, and dealt with. Leaving warnings otherwise increases noise and causes new warnings to be overlooked.
Believe it or not, most code formatting rules regarding indents, placement of {}, and spacing has no effect on code quality. But developers are highly contentious that theirs is the best and anything else drives them crazy. Most cannot pinpoint why, but it really boils down to personal preferences and nothing more.
Use any formatting you want! Just follow these steps when checking files out.
Won't this create a source repository with multiple formats? Yes, but for source code builds we can do a mass reformat.
Won't this create unnecessary differences and check ins? If you only reformat code you plan to edit, it will not create unnecessary check ins. Differencing tools ignore whitespace, so in most cases looking at a change set will still only show actual code changes and not all the formatting changes.
In a perfect world, TFS would format to our personal settings on check out, and format to a system standard on check in. Maybe one day. Or if you want to write such a plug in, please contact us!
| Prefix | Usage |
|---|---|
| x | Local |
| a | Argument, by value |
| o | Argument, out |
| r | Argument, ref |
| m | protected member field |
| I | Interface |
Casing should be used to improve readability, but should never be used to imply meaning. No two identifiers should be differentiated only by case. This causes code portability problems to other languages, and reduces readability by developers especially from certain on English speakers whose languages upper and lower case letters are not as differentiated in the Latin alphabet. (i.e. they are not used to looking for such case differences).
For example, this is prohibited because value and Value are only differentiated by case.
String value;
public String Value {
get { return value; }
set { this.value = value; }
}
Underscores should be avoided in identifiers. Underscores require a shift stroke and slow down coding. Instead, rely on casing. Customer_Name is incorrect, while CustomerName is correct.
Most developers do not understand proper uses of interfaces and over use of interfaces complicate code. Interfaces however are permitted and valid, but should be the exception rather than the rule, and must be defendable.
As with interfaces, most developers cannot properly differentiate between proper use of private and protected. Protected should be used unless a clear case can be demonstrated why an item should be private.
Optimizations that should be used when possible:
When possible constructor injection should be used. That is, if certain parameters are required for an object to function, force the arguments to be passed in the constructor(s). This forces the consumer to pass the arguments during construction rather than after, and greatly simplifies the objects logic and reduces exception paths.
Usage of the var keyword is encouraged, but not required or even appropriate in every case. A suggestion is to use var with objects, but explicit types with simple types. i.e.
int i = 6;
string s = "Hello";
var xSB = new StringBuilder();
This is incorrect:
if (x == 4)
DoSomething();
In later modifications, developers often simply add another line below not noticing missing braces. This introduces a bug. This is correct:
if (x ==4) {
DoSomething();
}
or
if (x ==4)
{
DoSomething();
}
Note - Up in the air on this syntax. We previously banned it in Delphi because Delphi could only trace per line. However Visual Studio accurately traces each statement. So I would suggest it be allowed, although not necessarily encouraged.
if (x == 4) { DoSomething(); }
Each source file generally (There are some exceptions allowed) should only contain one public class. Any additional classes should be directly related to the public class. The filename is the same name as the class. So Foo.cs would contain a class named Foo.