Best Practices

This is our definitive list of guidelines, suggestions, recommendations, etc

link - learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions 

Numbers 1 - 10 are aimed at Beginner Programmers.
Numbers 11 - 20 are aimed at Intermediate Programmers.
Numbers 21 - 30 are aimed at Advanced Programmers.


1) Very simple project structure, no sub folders.
Fewer files means more consistency
naming conventions
descriptive filenames
Avoid adding any dependencies unless absolutely necessary


2) Always indent your code to make it more readable.
You can use spaces to indent your code, although tabs are recommended.
Indenting your code consistently makes the code easier to understand and the program flow more obvious.
Always vertically align curly brackets.


3) Use meaningful method names, property names, variable names, etc.
Only use the same method name when it is overloaded (no duplicates across namespaces)
Using the same name with a different access modifier will work but is extremely confusing.


4) Avoid using the Ternary Operator
It makes your code very hard to read and depending on your changes you might have to remove it altogether at a later date.

if (bvalue == true) ? sVariable1 = "text": sVariable = "text" 

Always put your if statements on multiple lines
Always include curly brackets

if (bvalue == true) 
{
}

or

if (bvalue == true) 
{ ... }

5) Try to declare your variables at the top rather than close to where they are being used.
Declaring some variables just before they are used can make refactoring the code easier but it means you have to look in multiple places.
Always declare local variables "outside" the try-block so they can be used in the catch error handling.
Remember to keep your methods to less than 30 lines.

string myText; 
try
{}

6) Use camelCasing for local variables and method arguments.
Do not use hungarian notation which is prefixing your variables with a data type abbreviation.
Avoid any types of abbreviations because these will be inconsistent between developers.
Use PascalCasing for class names and properties
Class Names should be nouns, noun phrases or adjective phrases and should not contain an underscore
Member Names should be verbs or verb phrases
Use upper case for constants

string firstName; 
long rowCount;

7) Use the predefined type names instead of system type names like Int16, Single, UInt64, etc
Use the alias names

int lastIndex;       // not System.Int32 
bool isSaved; // not System.Boolean

8) Do not add any unnecessary comments
Place the comment on a separate line, not at the end of a line of code.
Begin comment text with an uppercase letter.
End comment text with a period.
Insert one space between the comment delimiter (//) and the comment text, as shown in the following example.
Don't create formatted blocks of asterisks around comments.
Ensure all public members have the necessary XML comments providing appropriate descriptions about their behavior.


9) Always change your Exception Settings to break on all exceptions
Select (Debug > Windows > Exception Settings) and make sure "Common Language Runtime Exceptions" is checked.
Selecting this checkbox will break the code whenever an exception is thrown, regardless of whether it is handled or not.


10) Do not use "using", prefix everything in full.

using System.Collections.Generic 

Always fully qualify the names from any namespace (including any Office enumerations)
Organize namespaces with a clearly defined structure
Remove any 'using' commands that are not used


Intermediate Best Practices

Numbers 11 - 20 are aimed at Intermediate Programmers.


11) When developing VSTO Add-ins use two projects
Create an Office specific project for the VSTO add-in.
Create a different (dll) project for all the add-in specific code.


12) When developing VSTO Add-ins use an alias directive for the corresponding application namespace.

using Excel = Microsoft.Office.Interop.Excel 
Excel.Workbook
Excel.Range

13) Add a try-catch to all your methods

try 
{}
catch (System.Exception ex)
{}

Never embed or nest try-catch statements
Use ex as the variable for a general exception


14) Declare all member variables at the top of a class, with static variables at the very top.
Group all the variables with the same data type together

public class Account 
{
    public static string BankName;
    public string Number {get; set;}

15) Always specify the access modifier, never rely on the defaults
private for member
internal for class


16) Add prefixes
Any procedures or functions that are declared inside classes should be prefixed
This makes it a lot easier to identify and find your code in the intellisense

public void Method_DoSomething(); 

17) Any public class members should only be accessible through Properties


18) Always use this. when accessing class member variables (esp private variables)
Prefix private member variables (or internal fields) with an underscore so they are not confused with the method parameters.

private string _myfield; 

19) Add suffixes
Add the suffix "_Delegate" to any delegates
Add the suffix "_EventArgs" to any classes that extend System.EventArgs
Add the suffix "Exception" to any types that inherit from System.Exception
Add the suffix "Stream" to any types that inherit from System.IO.Stream
Add the suffix "en" to any enumeration types


20) Use singular names for enumerations
do not explicitly specify a type of an enum or values of enums

public enum Color 
{
   Red,

21) Never pass arguments in to methods using "ref"



Advanced Best Practices

Numbers 21 - 30 are aimed at Advanced Programmers.


22) Only use the implicit type var for variables when it makes sense

var customers = new System.Collections.Generic.Dictionary(); 

23) Always prefix interfaces with the letter I.
Interface names are noun (phrases) or adjectives.


24) If continuation lines are not indented automatically, indent them one tab stop (four spaces).


25) Add at least one blank line between method definitions and property definitions.


26) Use parentheses to make clauses in an expression apparent, as shown in the following code.


27) Windows Forms Controls
Do not change any of the properties in the designer.
Always change the properties in the code for more visibility.


28) Do not provide a default constructor for a structure ??



© 2024 Better Solutions Limited. All Rights Reserved. © 2024 Better Solutions Limited TopPrevNext