Manual:Pre-commit checklist

This is an attempt to create a checklist to use before making a commit. Some of this duplicates what is in the coding conventions, but is in the form of quick checks. This checklist is in the same vein as The Checklist Manifesto. Some of these may seem silly (like asking a doctor “did you wash your hands?”) but they're meant to avoid problems that may be overlooked.

Back-end

 * Did your code run without errors under ?
 * Did your code break any of the unit tests? See Manual:PHP unit testing and Manual:JavaScript unit testing
 * Have you tested all exit points from your code?
 * Did you use tabs instead of spaces to indent?
 * If you've created a new function, did you document the function parameters and what it returns using PHPDoc?
 * Whitespace trailing at the end of lines is annoying, don't do that (but don't fix whitespace at the end of lines you didn't modify in the same commit, just make sure whatever you touched is good, see next point:)
 * Does this commit contain any whitespace-only changes? They should be isolated to their own separate coding style-only commit.
 * Have you created any identifiers that didn't use camelCase (ie. underscores)?
 * Is every exception tested?
 * If you have multiple return points, are they tested?
 * Does each message you've created exist in MessagesEn.php and is listed in maintenance/languages/messages.inc?
 * Is each use of,  , etc. checked for errors or problems?
 * Did you use  or   flags for   to ensure Windows compatibility?
 * Have you used the proper output functions?   should almost never be used.
 * Have you used the proper termination functions?   should almost never be used.
 * Where appropriate, have you used the MediaWiki wrapper functions instead of their PHP equivalents?
 * instead of  to get boolean params


 * If you add a new test to parserTests.txt did you give it a new name?
 * Have you run ?

Front-end

 * Tested in an actual browser?
 * Will it work at least in the browsers we support for A-grade functionality ? (check Compatibility)
 * (JavaScript) Does it validate (or did you at least run it through) JSHint or JSLint ? (check recommended settings)
 * (JavaScript) Are there any implied globals other than  or  ? There should not be, (not   either)

Testing
When adding features, it's vital to verify you didn't break existing functionality. The usual tool for this is automated testing frameworks. MediaWiki's test suite is still relatively sparse. We have three kinds of tests:


 * Parser tests (see tests/parserTests.php), which only test the parser. Try running  to see how those work.  Everything should pass, in theory.  You can add new tests or fix existing ones by editing tests/parserTests.txt.
 * PHPUnit-based unit tests in the tests/phpunit directory. They are typically run through the phpunit.php script invoked from the aforementioned directory. These tests also include ordinary parser tests, though parserTests.php probably works faster. See Manual:PHP unit testing for PHPUnit setup instructions and further details.
 * Selenium tests are in directory tests/selenium.

Anyway, if you can't write an automatic test, do manual testing. If you cause breakage too often, people will get annoyed at you, especially if it isn't caught until it goes live on Wikipedia. Revocation of commit access has been threatened in the past occasionally. At the very least, expect serious indignation if you check in syntax errors – try at least loading your wiki, or php maintenance/checkSyntax.php --modified</tt>.