Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

User:Phalacee/Peer Review: Difference between revisions

From MoodleDocs
No edit summary
No edit summary
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
==Peer review check-list==
==Peer review check-list==


These are the things I have picked up from peer-reviewing issues. They can also be applied when solving issues. If you can think of anything that needs to be added, please do so.
These are the things I have picked up from peer-reviewing issues. They can also be applied when solving issues. If you can think of anything that needs to be added, please do so. (Thanks Sam for your suggestions)


===Syntax===
===Syntax===
Ensure that:
Ensure that:
* There are no unnecessary blank lines in the new code.
* there are no unnecessary blank lines in the new code;
* Blank lines do not contain spaces.
* blank lines do not contain spaces;
* Variables are named correctly (all lower case, no underscores).
* variables are named correctly (all lower case, no underscores);
* Functions are named correctly.
* functions are named correctly; and
* There are no changes to whitespace in other areas on the file.
* there are no unnecessary changes to whitespace in other areas on the file.
* new strings Don't Use Camel Case
 
See the [[Coding style]] guide for details.


===Output===
===Output===
Ensure that:
Ensure that:
* The code doesn't use buffered output unless absolutely necessary.
* the code doesn't use buffered output unless absolutely necessary; and
* Lang-strings are used for output of text.
* lang-strings are used instead of hard-coded strings for text output.
* There are no hard-coded strings for text output.


===Databases===
===Databases===
Line 21: Line 23:


Ensure that:
Ensure that:
* There are minimal DB calls (no excessive use of the DB).
* there are minimal DB calls (no excessive use of the DB); and
* The code uses SQL compatible with all the supported DB engines.
* the code uses SQL compatible with all the supported DB engines.


===Misc===
===Misc===
Ensure that:
Ensure that:
* The code doesn't use deprecated functions https://docs.moodle.org/dev/Deprecated_functions_in_2.0
* the code seems to solve the described problem;
* The code makes sense in the broader scheme of things look at the whole function, not just the altered code.
* there are specific testing instructions that state how, as well as what, to test;
* The code is easy to understand, and where it isn't, comments have been provided.
* the code doesn't use deprecated functions (see [https://docs.moodle.org/dev/Deprecated_functions_in_2.0 Deprecated functions in 2.0]);
* the code makes sense in the broader scheme of things (look at the whole function, not just the altered code); and
* the code is easy to understand, and where it isn't, comments have been provided.
* It doesn't break XHTML
* It doesn't remove strings, or rename strings from stable branches (permitted only in master)
* php docs have been updated and adhere to coding style guide
* The idea/solution makes sense and is complete.
* The developer has searched for and fixed other areas that may also have been affected (provided they are in the scope of the original issue)
* String changes include AMOS syntax where required (moving, copying, deleting strings)
* No inline styles have been used in HTML output (everything has to be in CSS)
* CSS has been added to the appropriate CSS files (base, specific area, sometimes canvas)
* $_GET, $_POST, $_REQUEST, $_COOKIE, and $_SESSION are never used
* Unit tests all pass for related areas where changes have been made
* Uses sesskey for all write actions where appropriate (some read actions as well although not as common)
 
===GIT===
* The commit message includes the tracker issue number
* Git history is clean
* Make sure the original author of the work has been given credit within the commit (as author of in the commit message if changes were made)
 
 
 
 


==See Also==
==See Also==
http://moodle.org/plugins/view.php?plugin=local_codechecker
* [http://moodle.org/plugins/view.php?plugin=local_codechecker Code checker plugin]

Latest revision as of 07:40, 19 January 2012

Peer review check-list

These are the things I have picked up from peer-reviewing issues. They can also be applied when solving issues. If you can think of anything that needs to be added, please do so. (Thanks Sam for your suggestions)

Syntax

Ensure that:

  • there are no unnecessary blank lines in the new code;
  • blank lines do not contain spaces;
  • variables are named correctly (all lower case, no underscores);
  • functions are named correctly; and
  • there are no unnecessary changes to whitespace in other areas on the file.
  • new strings Don't Use Camel Case

See the Coding style guide for details.

Output

Ensure that:

  • the code doesn't use buffered output unless absolutely necessary; and
  • lang-strings are used instead of hard-coded strings for text output.

Databases

If there is SQL code you can test quickly, do so.

Ensure that:

  • there are minimal DB calls (no excessive use of the DB); and
  • the code uses SQL compatible with all the supported DB engines.

Misc

Ensure that:

  • the code seems to solve the described problem;
  • there are specific testing instructions that state how, as well as what, to test;
  • the code doesn't use deprecated functions (see Deprecated functions in 2.0);
  • the code makes sense in the broader scheme of things (look at the whole function, not just the altered code); and
  • the code is easy to understand, and where it isn't, comments have been provided.
  • It doesn't break XHTML
  • It doesn't remove strings, or rename strings from stable branches (permitted only in master)
  • php docs have been updated and adhere to coding style guide
  • The idea/solution makes sense and is complete.
  • The developer has searched for and fixed other areas that may also have been affected (provided they are in the scope of the original issue)
  • String changes include AMOS syntax where required (moving, copying, deleting strings)
  • No inline styles have been used in HTML output (everything has to be in CSS)
  • CSS has been added to the appropriate CSS files (base, specific area, sometimes canvas)
  • $_GET, $_POST, $_REQUEST, $_COOKIE, and $_SESSION are never used
  • Unit tests all pass for related areas where changes have been made
  • Uses sesskey for all write actions where appropriate (some read actions as well although not as common)

GIT

  • The commit message includes the tracker issue number
  • Git history is clean
  • Make sure the original author of the work has been given credit within the commit (as author of in the commit message if changes were made)



See Also