S# Audit Area CheckList Item
1 Member functions and Variables Each member function should have the following:
• Generator comments above the signature
• Objective Comments above the signature
2 Each member variable should have an objective.
3 Comments Write comments on top of all methods to describe
 their usage and expected input types and return type information.
4 Complex algorithms should be :
• Heading commented
• Thoroughly commented.
5 Code that has been optimized or modified to "work around" an issue
 should be thoroughly commented, so as to avoid confusion and re-introduction of bugs.
6 Code that has been "commented out" should be explained or removed.
7 Code that needs to be reworked should have a TODO comment
 and a clear explanation of what needs to be done.
8 Definitions Variable name should represent its main attribute in the model, so Avoid using short variable names
Cn ->Connection
Str->SQLQueryString
9 Avoid uncalled members and classes.
10 Delete unreached codes
11 Do not initialize variable without need for validation on its value before generating the real object.
12 Use access specifiers (private, public, protected, internal, and protected internal)
 as per the scope need of a method, a class, or a variable.
13 Use enumerations for groups of related constants that have integer values.
14 Use “var” keyword while defining variable to keep less code, less noisy, more clean, and keep solution maintainable when changing is required.
Example:
//ConfirmedOrders clsConfirmedOrder = new ConfirmedOrders();

   var clsConfirmedOrder = new ConfirmedOrders();
  Do not use var in case of Getting variable from another reference:
ConfirmedOrders clsConfirmedOrder = obj.GetModel().GetConfirmedOrders();
15 Prevent using of hard-coded values that will be subject for changes.
Separate them in managed resources, like DB and configuration files.
16 Signatures Don't pass any Boolean flag to a function in order to direct the business (SRP) in the same function. Instead use two different functions for the negative and positive states
17 Maximum number of arguments to a function should be less than or equal 4
18 Functions should start with a verb.
  Class diagram should represent the business for variables and operations, so matching between methods names and business requirements should be met.
  Function parameters should be limited to what will be used in the function scope
 protected void SetViewMode(bool bCancelEditing, int nNewID)
        {
            IsUpDownPressed = 0;
            CancelEditNode = bCancelEditing;
        }
19 Use descriptive names for functions and variables according to its objective
20 References Do not drill down in a reference many times, get the value and leave the reference.
//Do not do the following
//If (txt.Text == "1") …Do Something
//else if (txt.Text == "2") …Do Something
//else If (txt.Text == "3") …Do Something
//else If (txt.Text == "4") …Do Something

//Do the following
string strVal =txt.Text;
If (strVal == "1") …Do Something
else if (strVal == "2") …Do Something
else If (strVal == "3") …Do Something
else If (strVal == "4") …Do Something
21 If function signature contains the similar object attributes, Passing objects instead of separate attributes if the attributes represent an object:
CreatEmp (Employee emp)
Not
CreateEmp (id,name,salary)
22 Reusable components, events that are subject for changes in parameters  should pass its parameters throw structure/class in order to decrease coupling and increase maintainability

pEmbCls->CreatEmp (Employee emp)
Not
pEmbCls->CreateEmp (id,name,salary)
  do not inject views with unrferenced JavaScript Code, Separate all Client Side codes into separate files
23 Remove un-used imports,  unused namespaces, classes, variables
24 Naming Convension Use Camel Case : Eliminate poor naming convention: Naming for the variable, member function and class should represent the business need using CamelCase standard notation.
For variable : start with the first identifier of the variable type.
i : Integer
d : Decimal
f : Float
dt :Date
struct : Structure
btn: Button
txt: TextBox
cmb: ComboBox
25 Spelling checker Be sure that you don't make any spelling mistake (to be able to search easily)
26 Localization Localization: Put all strings in application resources file.
27 Resource management: All resources, images, icons strings, localization info should be separated in different and unified resource file.
28 Never duplicate the behavior according to the language.
29 Bloating Avoid bloated code like:
Code bloat is the production of code that is perceived as unnecessarily long, slow, or otherwise wasteful of resources.
Something ST = new Something();
ST.setField1(value1);
ST.setField2(value2);
ST.setField3(value3);

it should be :
Something ST = new Something(value1, value2, value3);
ST.DoSomething();
30 LOC Function should not exceed 30 lines of codes.
33 Logging Log for the execution as follow:
Module, class, operation, start parameters, execution steps, success flag, and exception description.
34 Logging should have suitable retention period
 in order to prevent function tractability or increase of logging media
35 Logging should be found in all building blocks
 found in the deployment model.
36 Write logs for all exceptions or main functionality success events with all its parameters:
- Date time
- Inputs
Outputs