C# CODING

STANDARDS AND
BEST PROGRAMMING
PRACTICES
WORKING CODE AND GOOD
CODE
 Reliable
 Maintainable
 Efficient
 Performance
NAMING CONVENTIONS AND
STANDARDS
 Pascal casing for
 ClassName
 MethodNames
 FileName
 Camel casing for
 variables
 methodParameters
 Prefix “I” with Pascal Casing for interfaces
 Do not use Hungarian notation to name variables
 All member variables must be prefixed with underscore (_)
so that they can be identified from other local variables.
 Do not use underscores (_) for local variable names.
 Use Meaningful, descriptive words to name
variables
 Do not use single character variable names
(except in loops)
 Do not use variable names that resemble
keywords.
 Prefix boolean variables, properties and
methods with “is” or similar prefixes.
( private bool _isFinished)
 File name should match with class name
 Use appropriate prefix for the UI elements so
that you can identify them from the rest of
the variables (Label lblName)
GOOD PROGRAMMING
PRACTICES
 Avoid writing very long methods.
 Method name should tell what it does
 A method should do only 'one job'.
 Better to use the language specific types (aliases),
rather than the types defined in System namespace.
 int age; (not Int16)
 string name; (not String)
 object contactInfo; (not Object)
 Always watch for unexpected values
 ifyou are using a parameter with 2 possible values,
never assume that if one is not matching then the only
possibility is the other value
 Do not hardcode numbers. Use constants
instead
 Do not hardcode strings. Use resource files
 Convert strings to lowercase or upper case
before comparing
 String.Empty instead of “”
 Use null == objTemp insted of objTemp==Null
 Avoid using member variables. Declare local
variables wherever necessary and pass it to
other methods instead of sharing a member
variable between methods.
 Use enum wherever required. Do not use
numbers or strings to indicate discrete values
 Make classes Sealed where inheritance is not
intended
 Make Abstract classes
 Unmanaged recourses must used with a
wrapper class
 Avoid Unnecessary code in finalizer block
 Use IDisposableInterface
 One time reading from object
 Use generic types like dictionary
 Strongly typed
 Avoid boxing unboxing
 Use using block
 If dispose method is provided call it
 Use the AssemblyInfo file to fill information
like version number, description etc
 Logically organize all your files within
appropriate folders
 Make sure you have a good logging class
which can be configured to log errors,
warning or traces.
 If you are opening database connections,
sockets, file stream etc, always close them
in the finally block
 Declare variables as close as possible to
where it is first used. Use one variable
declaration per line.
 Keep member variables private and expose
public/protected Properties
 The event handler should not contain the code to
perform the required action. Rather call another
method from the event handler.
 Donot programmatically click a button to execute the
same action you have written in the button click event
 Never hardcode a path or drive name in code. Get
the application path programmatically and use
relative path.
 Never assume that your code will run from drive "C:".
 Avoid public methods and properties, unless they
really need to be accessed from outside
 Use
“internal” if they are accessed only within the
same assembly
 Avoid passing too many parameters to a
method.
 define a class or structure.
 If you have a method returning a collection,
return an empty collection instead of null
 Use StringBuilder class instead of String when
you have to manipulate string objects many
time.
 Do not have more than one class in a single
file
 Avoid having very large files
EXCEPTION HANDLING
 Never do a 'catch exception and do nothing
 No need to catch the general exception in all your
methods. Leave it open and let the application crash. This
will help you find most of the errors during development
cycle.
 When you re throw an exception, use the throw statement
without specifying the original exception. This way, the
original call stack is preserved.
 Do not write try-catch in all your methods. Use it only if
there is a possibility that a specific exception may occur
and it cannot be prevented by any other means
 Do not write very large try-catch blocks. If required, write
separate try-catch for each task you perform and enclose
only the specific piece of code inside the try-catch
ERROR MESSAGES
 In the application start up, do some kind of "self check"
and ensure all required files and dependencies are
available, Check database connection
 If the required configuration file is not found,
application should be able to create one with default
values.
 If a wrong value found in the configuration file,
application should throw an error or give a message
and also should tell the user what are the correct
values.
 Error messages should help the user to solve the
problem.
 Show short and friendly message to the user. But log
the actual error with all possible information.
COMMENTS
 Write comments wherever required. But good
readable code will require very less comments
 Do not write comments if the code is easily
understandable without comment.
 Fewer lines of comments will make the code more
elegant
 The bottom line is, write clean, readable code
such a way that it doesn't need any comments to
understand
 Perform spelling check on comments and also
make sure proper grammar and punctuation is used
 Use xml/doxygen standard comments.
INDENTATION AND SPACING
 Use TAB for indentation. Do not use SPACES
 Comments should be in the same level as the code
 Curly braces ( {} ) should be in the same level as the
code outside the braces
 Use one blank line to separate logical groups of code
 There should be one and only one single blank line
between each method inside the class
 The curly braces should be on a separate line and not in
the same line as if, for etc
 Use a single space before and after each operator and
brackets.
 Keep private member variables, properties and methods
in the top of the file and public members in the bottom.
Use #region to group related pieces of code together
ASP.NET
 Do not store large objects in session
 Always use style sheet to control the look
and feel of the pages. Never specify font
name and font size in any of the pages. Use
appropriate style class. This will help you to
change the UI of your application easily in
future.
 create an error handler in the Global.asax
file that will catch all unhandled ASP.NET
errors while processing a request
ARCHITECTURE
 Always use multi layer (N-Tier) architecture
 Never access database from the UI pages.
Always have a data layer class which
performs all the database related tasks.
 Use try-catch in your data layer to catch all
database exceptions
 Separate your application into multiple
assemblies. Group all independent utility
classes into a separate class library. All your
database related files can be in another class
library