Basic code style guidelines for Robocop tests

  • Revision slug: Basic_Code_Styling_Guidelines_for_Robocop_tests
  • Revision title: Basic Code Styling Guidelines for Robocop tests
  • Revision id: 370123
  • Created:
  • Creator: AdrianT
  • Is current revision? No
  • Comment

Revision Content

General Info

  • 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
  • Most of these guidelines also apply to all patches that are submitted on the Firefox project

Basic Code Guidelines that need to be followed

  • 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

  • Correct spacing should be kept when writing methods:
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

Revision Source

<h2>General Info</h2>
<ul>
  <li>The purpose of this page is to specify a minimum guideline of <b>code formatting</b> and <b>coding style</b> that needs to be followed in order to receive a positive review on a patch</li>
  <li>Most of these guidelines also apply to all patches that are submitted on the Firefox project</li>
</ul>
<h3><span class="mw-headline" id="Basic_Code_Guidelines_that_need_to_be_followed_for_positive_reviews">Basic Code Guidelines that need to be followed</span></h3>
<ul>
  <li>All TABs should be replaced by 4 spaces - use the "use spaces" option in your editor to substitute Tab with spaces</li>
  <li>No spaces should be present at the end of a line after ";", "}", "{" or any other line ender</li>
  <li>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</li>
  <li>One line comments should use "//". There should always be a space after "//" and the first letter of the comment should be capitalized</li>
</ul>
<pre>
e.g. // This is a one line comment
</pre>
<ul>
  <li>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:</li>
</ul>
<pre>
e.g. /* This is a multiple line comment
        The text should be aligned at the first letter not the comment start */
</pre>
<ul>
  <li>Long comments should be spread across multiple lines and not left to be autosplit by display formating</li>
  <li>Blank lines can be used inside the body of a method and should be used only to separate logically connected blocks of code</li>
  <li>After each "{" the text should be indented with an additional tab which should be eliminated at the first "}"</li>
</ul>
<pre>
first_lvl_of_indentation {
    second_lvl_of_indentation {
        3rd_lvl_of_indentation {
        }
    }
    We are now at the second level
}
</pre>
<p>We are back at the 1st level of indentation</p>
<ul>
  <li>Correct spacing should be kept when writing methods:</li>
</ul>
<pre>
e.g. method_name(arg1, arg2, arg3) {
</pre>
<p>- no space between the method name and the parameter list, spaces after each "," in the parameter list and a space between the list and "{"</p>
<ul>
  <li>Leave a blank line between 2 methods</li>
  <li>Do not leave a blank line between the end of the last method in the class and the end of the class</li>
</ul>
<pre>
class {
    variables defined here

    method1() {
    }

    method2() {
    }

    method3() {
    }
}
</pre>
<ul>
  <li>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</li>
  <li>When testing equality between 2 strings use .equals instead of '=='</li>
</ul>
<pre>
e.g. String1.equals(String2);
</pre>
<ul>
  <li>If a block of code is used more then 2 times in a class create a method out of it</li>
  <li>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</li>
</ul>
<pre>
class example {
    int globalVariable;
    ...
    method(int mGlobalVariable) {
    int globalVariable = mGlobalVariable;
    ....
    }
}
</pre>
<ul>
  <li>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):</li>
</ul>
<pre>
e.g. thisIsAVariableNameWrittenInCamelCase
</pre>
<ul>
  <li>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 - <b>This is not a requirement for positive review but will usually result in a follow-up bug after patch acceptance</b></li>
  <li>Make variables and methods which do not need to be accessed from outside <b>private</b></li>
  <li>Declare variables that do not change <b>final</b></li>
  <li>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</li>
  <li>When using timeouts for test reuse the ones declared in BaseTest unless you need different values for the timeout</li>
  <li>Clean up the import list after the test is complete and tested by removing any imports that are not used</li>
  <li>Clean up variables that you end up not using in the test</li>
  <li>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</li>
</ul>
Revert to this revision