Beruflich Dokumente
Kultur Dokumente
CODING STANDARD -
C#
Table of Contents
1 INTRODUCTION.................................................................................................................... 3
2 FILE NAMING........................................................................................................................ 4
3 CODING STANDARDS – GENERAL....................................................................................5
3.1 ALL FUNCTIONS MUST HAVE RETURN TYPE........................................................................5
3.2 USING............................................................................................................................. 5
3.2.1 Name space references............................................................................................5
4 NAMING CONVENTIONS..................................................................................................... 6
4.1 NAMESPACE.................................................................................................................... 6
4.2 CLASS............................................................................................................................. 6
4.3 INTERFACE...................................................................................................................... 7
4.4 ENUMERATION................................................................................................................. 7
4.5 STATIC FIELD.................................................................................................................. 7
4.6 PARAMETER.................................................................................................................... 7
4.7 METHOD NAME................................................................................................................ 8
4.8 PROPERTY NAME............................................................................................................. 8
4.9 EVENT NAME................................................................................................................... 8
5 USAGE GUIDELINES.......................................................................................................... 10
5.1 PROPERTY USAGE......................................................................................................... 10
5.2 EVENT USAGE............................................................................................................... 10
5.3 METHOD USAGE............................................................................................................ 11
5.4 CONSTRUCTOR USAGE.................................................................................................. 12
5.5 FIELD USAGE................................................................................................................ 12
5.6 PARAMETER USAGE....................................................................................................... 13
5.7 ARRAY USAGE............................................................................................................... 13
5.8 OPERATOR OVERLOADING.............................................................................................13
5.9 TYPE CASTING.............................................................................................................. 15
6 TASKS................................................................................................................................. 16
6.1 TODO.......................................................................................................................... 16
6.2 REVIEW...................................................................................................................... 16
6.3 BUG............................................................................................................................. 16
6.4 TEST........................................................................................................................... 16
7 EXCEPTIONS AND VALIDATIONS....................................................................................17
7.1 EXCEPTIONS.................................................................................................................. 17
7.1.1 Exception Handling................................................................................................. 17
7.1.2 Throwing Exceptions............................................................................................... 18
7.2 VALIDATIONS................................................................................................................. 18
8 DOCUMENTATION AND COMMENTING...........................................................................19
8.1 TAGS............................................................................................................................ 19
9 UNIT TESTS........................................................................................................................ 20
9.1 TEST MODULE............................................................................................................... 20
9.2 TEST CLASS.................................................................................................................. 20
9.3 TESTS........................................................................................................................... 20
9.4 Test Coverage............................................................................................................. 20
1 Introduction
This document describes the standards that every developer in Tally should follow while
coding in C#.
This document addresses the following standards
File naming
Coding Standards General
Coding Standards - Platform
Coding conventions are very important and it is expected that all developers will know
these standards and follow them.
2 File Naming
The section explains the coding standards to be used by all developers while coding.
3.2 Using
3.2.1 Name space references
All the namespaces referenced in the code must be included in to the assembly by
using the using keyword.
E.g.
using Microsoft.Practices.EnterpriseLibrary.Common.Configuration;
4 Naming Conventions
4.1 Namespace
You should use Pascal case for namespaces, and separate logical components with
periods, as in TallyShoper9.Lib.Log. The general rule for naming namespaces is to use
the company name followed by the technology name and optionally the feature and
design as follows.
ProductName.Group.[.Feature][.Design]
For example:
TallyShoper9.Comp.ExportServer;
Prefixing namespace names with TallyShoper9 name will avoid conflicts with
namespaces. For TallyShoper9.Lib and Tally9Erp.Lib will form two different libraries and
will not create any conflicts.
Second level in the name space should identify the group of the namespaces. For
example, Lib for library and Comp for Components.
Do not use the same name for a namespace and a class. For example, do not provide
both a Debug namespace and a Debug class.
4.2 Class
Use a noun or noun phrase to name a class
Use Pascal case.
Use abbreviations sparingly
Do not use a type prefix, such as C for class, on a class name. For example, use the
class name FileStream rather than CFileStream.
Do not use the underscore character (_).
Occasionally, it is necessary to provide a class name that begins with the letter I, even
though the class is not an interface. This is appropriate as long as I is the first letter of an
entire word that is a part of the class name. For example, the class name IdentityStore is
appropriate.
Where appropriate, use a compound word to name a derived class. The second part of
the derived class's name should be the name of the base class. For example,
ApplicationException is an appropriate name for a class derived from a class named
Exception,
4.3 Interface
Name interfaces with nouns or noun phrases, or adjectives that describe behavior. For
example, IComponent , ICustomAttributeProvider, IPersistable
Use Pascal case
Use abbreviations sparingly
Prefix interface names with the letter I, to indicate that the type is an interface.
Use similar names when you define a class/interface pair where the class is a standard
implementation of the interface. The names should differ only by the letter I prefix on the
interface name.
Do not use the underscore character (_).
4.4 Enumeration
Use Pascal case for Enum types and value names.
Use abbreviations sparingly.
Do not use an Enum suffix on Enum type names.
4.6 Parameter
It is important to carefully follow these parameter naming guidelines because visual
design tools that provide context sensitive help and class browsing functionality display
method parameter names to users in the designer.
Use camel case for parameter names.
Use descriptive parameter names. Parameter names should be descriptive enough that
the name of the parameter and its type can be used to determine its meaning in most
scenarios. For example, visual design tools that provide context sensitive help display
method parameters to the developer as they type. The parameter names should be
descriptive enough in this scenario to allow the developer to supply the correct
parameters.
Use names that describe a parameter's meaning rather than names that describe a
parameter's type. Development tools should provide meaningful information about a
parameter's type. Therefore, a parameter's name can be put to better use by describing
meaning. Use type-based parameter names sparingly and only where it is appropriate.
Do not prefix parameter names with Hungarian type notation.
Do not use a prefix or suffix on the event declaration on the type. For example, use Close
instead of OnClose.
In general, you should provide a protected method called OnXxx on types with events
that can be overridden in a derived class. This method should only have the event
parameter e, because the sender is always the instance of the type.
5 Usage guidelines
When you refer to events in documentation, use the phrase, "an event was raised"
instead of "an event was fired" or "an event was triggered."
Use a return type of void for event handlers, as shown in the following C# code example.
Event classes should extend the System.EventArgs Class, as shown in the following
example.
Use a protected (Protected in Visual Basic) virtual method to raise each event. This
technique is not appropriate for sealed classes, because classes cannot be derived from
them. The purpose of the method is to provide a way for a derived class to handle the
event using an override. This is more natural than using delegates in situations where the
developer is creating a derived class. The name of the method takes the form
OnEventName, where EventName is the name of the event being raised. For example:
By default, methods are nonvirtual. Maintain this default in situations where it is not
necessary to provide virtual methods.
Use method overloading to provide different methods that do semantically the same
thing.
Use method overloading instead of allowing default arguments. Default arguments do not
version well and therefore are not allowed in the Common Language Specification (CLS).
Use a consistent ordering and naming pattern for method parameters. It is common to
provide a set of overloaded methods with an increasing number of parameters to allow
the developer to specify a desired level of information. The more parameters that you
specify, the more detail the developer can specify.
Note that the only method in the group that should be virtual is the one that has the most
parameters and only when you need extensibility.
If you must provide the ability to override a method, make only the most complete
overload virtual and define the other operations in terms of it.
You might want to expose a method that takes a variable number of arguments. A classic
example is the printf method in the C programming language. For managed class
libraries, use the params (ParamArray in Visual Basic) keyword for this construct. For
example, use the following code instead of several overloaded methods.
void Format(string formatString, params object [] args)
C++ operator
symbol Name of alternative method Name of operator
/ Divide op_Division
% Mod op_Modulus
^ Xor op_ExclusiveOr
| BitwiseOr op_BitwiseOr
|| Or op_LogicalOr
= Assign op_Assign
== Equals op_Equality
!= Compare op_Inequality
*= Multiply op_MultiplicationAssignment
-= Subtract op_SubtractionAssignment
^= Xor op_ExclusiveOrAssignment
%= Mod op_ModulusAssignment
+= Add op_AdditionAssignment
|= BitwiseOr op_BitwiseOrAssignment
/= Divide op_DivisionAssignment
-- Decrement op_Decrement
++ Increment op_Increment
~ OnesComplement op_OnesComplement
6.1 Exceptions
6.1.1 Exception Handling
All exceptions are captured at the procedure level and will not catch any general exceptions. All
the unknown exception and unhandled exceptions will be caught at the application/thread level.
For example
class Example
{
public static void Main()
{
try
{
//Try something
DoSomeThing();
}
catch (Exception e)
{
//catch all ubknown exception types and handle the same
//log the exception and rollback
}
finally
{
//finalize
}
}
try
{
i = j / i;
}
catch (DivideByZeroException e) //catch only known exception
types and process
{
Console.Write("divided by zero error occurs");
}
}
}
6.2 Validations
All function calls must be validated for a valid return value. All lib functions will return only
reference types and it will return null when the processing is not done. The calling function will
have to validate the result before use. If the function has to return a value type then out parameter
will be used and the function will return a bool value.
Function call:
//Try something
resultString = DoSomeThing(2);
if (resultString == null)
{
Console.WriteLine("error occurred");
Console.ReadLine();
}
Function definitions:
static String DoSomeThing(int j)
{
int i;
i = 0;
try
{
i = j / i;
return (i.ToString());
}
catch (DivideByZeroException e) //catch only known exception
types and process
{
Console.Write("divided by zero error occurs");
return (null);
}
}
All code segments must be well commented. All functions and logical steps should have
documentation tags defined in the doxygen format. The following tags should be used
when documenting the code.
7.1 Tags
<c> Identifies inline text that should be rendered as a piece of code. Similar to using
<tt>text</tt>.
<code> Set one or more lines of source code or program output. Note that this command
behaves like \code ... \endcode for C# code, but it behaves like the HTML equivalent
<code>...</code> for other languages.
<example> Marks a block of text as an example, ignored by doxygen.
<exception cref="member"> Identifies the exception a method can throw.
<list type="type"> Starts a list, supported types are bullet or number and table. A list
consists of a number of <item> tags. A list of type table, is a two column table which can
have a header.
<item> List item. Can only be used inside a <list> context.
<description> Part of a <list> command, describes an item.
<listheader> Starts the header of a list of type "table".
<para> Identifies a paragraph of text.
<param name="paramName"> Marks a piece of text as the documentation for parameter
"paramName". Similar to using \param.
<paramref name="paramName"> Refers to a parameter with name "paramName".
Similar to using \a.
<remarks> Identifies the detailed description.
<returns> Marks a piece of text as the return value of a function or method. Similar to
using \return.
<see cref="member"> Refers to a member. Similar to \ref.
<seealso cref="member"> Starts a "See also" section referring to "member". Similar to
using \sa member.
<summary> Identifies the brief description. Similar to using \brief.
<term> Part of a <list> command.
<typeparam name="paramName"> Marks a piece of text as the documentation for type
parameter "paramName". Similar to using \param.
<typeparamref name="paramName"> Refers to a parameter with name "paramName".
Similar to using \a.
8 Unit Tests
Coding should be started only after the tests that the code should pass are ready. Each
code block should have a test written. This ensures that running all the tests will make
sure that all the known issues are tested. This is useful for unit testing.
8.3 Tests
The test must be intended to test one or more logical units of the application.
The function that will contain the test will have to be marked as test by using [Test] before
the definition of the function.
Assert class should be used for comparision of the results as applicable.
Eg: We can test a division function by passing 8, 2 as values which will return 4. This will
be a passed test and all the lines of code is visited. It does not mean that a test with parameters
8, 0 will also pass. You have to think all the possible scenarios and use cases to test.