Automation Coding Guidelines

·       Coding Guidelines

o   Code Header

§  The code header should be listed in the beginning of the file. This Information provides a developer with a means of communicating with other readers of the source code. It provides a clear understanding during Maintenance. These comments should be as mentioned below:

o    ############################################################################

o    # Test Name      :

o    #

o    # Description   : Performs following:

o    #                     

o    #

o    # Author            :

o    # Created on      :

o    # Entry Point      : Main Screen

o    # Exit Point        : Main Screen

o    # Updated By     :

o    # Updated On     :

o    ###########################################################################

o   Function Header

§  Each function in any library file should have a header listed in the beginning of the function definition. This Information provides a developer with a means of communicating with other readers of the source code. It provides a clear understanding during Maintenance. These comments should be as mentioned below:

o    ###########################################################################

o    #

o    # Function         :

o    #

o    # Description      :

o    #

o    #

o    # Author            :

o    # Created on      :

o    # Entry Point      : NA

o    # Exit Point        : NA

o    # Updated By     :

o    # Updated On     :

o    ###########################################################################

o   Naming Conventions

§  Basic Naming Standards

• Use full English descriptors that accurately describe the variable/field/class…
• Use terminology applicable to the domain, from the point of view of the end user.
• Use all lower case characters when describing any variable.
• Use an underscore (‘_’) as a separator between two words of the variable.
• Use abbreviations sparingly. If you do so use them intelligently.
• Avoid names that are similar

§  Naming Functions

·         Methods should be named using a full English descriptor, using mixed case, with the all letters in lowercase.

·         Examples

·         public function login(in user_id, in password)

·         public function count_in_list(in obj_name, out count)

§  Naming Objects

·         For names of objects full English descriptor of the object prefixed with the object type should be used. This makes it easy to identify the purpose of the object as well as its type. Following prefixes should be used for different types of objects:

·         Sl. No.	·         Object Type	·         Prefix used
·         1	·         Text Box	·         txt
·         2	·         Lable	·         lbl
·         3	·         Buttons	·         btn
·         4	·         Radio Button	·         rd
·         5	·         Check Box	·         chk
·         6	·         Other objects	·         obj

·         Examples:

·         lbl_user_id

·         txt_password

·         btn_ok

·         rd_access_type

·         Naming Constants

·         Constants are values that do not change. Use full English words all in uppercase with underscores between the words. First character should signify the type of constant as mentioned below in the table:

·         Sl. No.	·         Constants Type	·         Prefix used
·         1	·         Error constants	·         E
·         2	·         Button Names	·         B

·         Example:

·         E_INVALID_INPUT

·         E_NOT_ASSIGNED

·         B_PATIENT

·         EXISTS_TIME

·         This convention helps to distinguish constants from variables. It is recommendable not to define constants. If the constant doesn’t fall into any category a name can be used with no prefix.

§  Naming local variables

·         A local Variable is an object or data item that is defined within the scope of a block, often a member function. The scope of a local variable is the block in which it is defined. In general, use a full-fledged descriptor for local variable names.

·         Example:

·         search_string

·         first_char

·         Naming Loop Counters

·         Use i, j or k for loop counters, use them consistently.

§  Naming Parameters

·         Parameters should be named following the exact same convention as for local variables.

§  Naming GUI objects

·         GUI objects used by the system should follow the naming convention same as for objects. All the names generated by WinRunner for the objects of the application should be changed as per the guidelines before developing or recording the scripts.

o   Coding Conventions

§  Code conventions are important to programmers for a number of reasons:

§  80% of the lifetime cost of a piece of software goes to maintenance. Hardly any software is maintained for its whole life by the original author. Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.

§  If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

o   Parameter names

·         Parameter names should be constructed like identifiers.

·         Example:

·         public function count_in_list(in obj_name, out count)

·         {

·         .

·         .

·         }

§  Declarations

·         Number per Line

·         One declaration per line is recommended since it encourages commenting.

·         Example:

·         # Boolean variable to contain 1 or 0

·         auto b_enabled;

·         # x position of the scroll button

·         auto x_scroll;

·         # y position of the scroll button

·         auto y_scroll;

·         Initialization

·         Try to initialize local variables where they're declared. The only reason not to initialize a variable where it's declared is if the initial value depends on some computation occurring first.

·         Placement

·         Put declarations only at the beginning of script or function. Don't wait to declare variables until their first use; it can confuse the unwary programmer and hamper code portability within the scope.

§  Conditions

·         if / else

·         Place the if keyword and conditional expression on the same line.

·         Example:

·         if (win_exists(…) = E_OK)

·         {  

o    win_activate(…);

o    set_window(…);

·         }

·         else

·         {

o    invoke_application(…);

·         }

·         WHILE

·         The WHILE construct uses the same layout format as the IF construct. The WHILE keyword should appear on its own line, immediately followed by the conditional expression. The statement block is placed on the next line. The curly braces may optionally be indented by up to 1 tab.

·         Example:

·         i = 1;

·         While(i<21)

·         {

o    type(i++);

·         }

·         SWITCH

·         The SWITCH construct uses the same layout format as the IF construct. The SWITCH keyword should appear on its own line, immediately followed by its test expression. The statement block is placed on the next line. The curly braces may optionally be indented by up to 1 tab character.

·         Example:

·         Switch(a)

·         {

·         case “xyz”:

o    b = a & “tw”;

o    break;

·         case “uv”:

o    pause(“hello”);

o    x = a;

o    break;

·         default:

o    x = a;

·         }

·         for Statements

·         A for statement should have the following form:

·         for (i = 1; i <= 20; i++)

·         {

o    run_me(i);

·         }

·         Return Statements

·         A return statement should not use parentheses unless they make the code more obvious in some way.

·         Example:

·         return E_OK;

·         return E_SUCCESS;

§  Comments

·         Example:

·         # This is the comment

§  Indentation

·         A tab should be used as the unit of indentation. The exact construction of the indentation (spaces vs. tabs) is unspecified.

·         Line wrapping for if statements should generally use the tab spacing rule, since conventional (4 space) indentation makes seeing the body difficult.

·         Example:

·         //USE THIS INDENTATION INSTEAD

·         if (condition1)

·         {

o    doSomethingAboutIt();

·         }

·         //OR USE THIS

·         if (condition1) {

o    doSomethingAboutIt();