QA SoftVision Team/Mobile/Robocop basic code guidelines

The purpose of this page is to specify a minimum guideline of code formatting and coding style that needs to be followed in order to receive a positive review on a patch

All TABs should be replaced by 4 spaces - use the "use spaces" option in your editor to substitute Tab with spaces
No spaces should be present at the end of a line after ";", "}", "{" or any other line ender
Comments should be added in the code to explain what the code does every time you consider that you would have to explain what or why you did things like that
One line comments should use "//". There should always be a space after "//" and the first letter of the comment should be capitalized

e.g. // This is a one line comment

Multiple line comments should use the format " /* comment */ ". The same rules of the single line comment apply plus the text should be aligned for the different lines of the comment:

e.g. /* This is a multiple line comment
        The text should be aligned at the first letter not the comment start */

Long comments should be spread across multiple lines and not left to be autosplit by display formating
Blank lines can be used inside the body of a method and should be used only to separate logically connected blocks of code
After each "{" the text should be indented with an additional tab which should be eliminated at the first "}"

first_lvl_of_indentation {
    second_lvl_of_indentation {
        3rd_lvl_of_indentation {
        }
    }
    We are now at the second level
}

We are back at the 1st level of indentation

e.g. method_name(arg1, arg2, arg3) {

- no space between the method name and the parameter list, spaces after each "," in the parameter list and a space between the list and "{"

Leave a blank line between 2 methods
Do not leave a blank line between the end of the last method in the class and the end of the class

class {
    variables defined here

    method1() {
    }

    method2() {
    }

    method3() {
    }
}

Do not leave a blank line between the class declaration and the global variable declaration blocks and indent the variable declaration block to the first method declaration
When testing equality between 2 strings use .equals instead of '=='

e.g. String1.equals(String2);

If a block of code is used more then 2 times in a class create a method out of it
If you need to change a parameter received by the method inside it but you don't want to change it globally define the parameter using an "m" before the label

class example {
    int globalVariable;
    ...
    method(int mGlobalVariable) {
    int globalVariable = mGlobalVariable;
    ....
    }
}

When naming methods and variables use suggestive names and use camel case for them (the name starts with a non-capital letter, the words making up the name are not separated and each following word is capitalized):

e.g. thisIsAVariableNameWrittenInCamelCase

If a method used in your test would be usefull in further/other tests define it in BaseTest or PixelTest not in your test class - This is not a requirement for positive review but will usually result in a follow-up bug after patch acceptance
Make variables and methods which do not need to be accessed from outside private
Declare variables that do not change final
Do not hardcode any data. If you need a value somewhere declare it as a variable at the beginning of the code - for e.g. URLs, timeouts
When using timeouts for test reuse the ones declared in BaseTest unless you need different values for the timeout
Clean up the import list after the test is complete and tested by removing any imports that are not used
Clean up variables that you end up not using in the test
If you have multiple variables that are of the same type and logically connected add them in an array rather then declaing them separatly - for e.g. a list of options

Navigation menu