Manual talk:Pre-commit checklist

Previous page history was archived for backup purposes at Manual talk:Pre-commit checklist/LQT Archive 1 on 2015-07-10.

Rather we need a specialized checklist for each popular language

feel free to start one.

Nothing about documenting hooks?

Moved from How to become a MediaWiki hacker:

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 php tests/parserTests.php --quick --quiet 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.

done.

The checkSyntax.php --modified documentation says "check only files modified in the current working copy (requires that the script is run from a Subversion checkout and that the SVN command-line client is present. Use this option to quickly check your changes before committing them to the repository." So, what about git?

Filed https://bugzilla.wikimedia.org/show_bug.cgi?id=42392

The following comments where put in inline comments by several editors, I've moved them here:

1. Is each use of fopen(), fread(), etc. checked for errors or problems?
   • does this mean that there is error handling?
2. If you've created a new function, have you documented its parameters and what it returns?
   • need to note where this should be documented
3. Have you used the proper output functions? echo should almost never be used.
   • where do we find this info? needs link. not in coding conventions
4. Have you use the proper termination functions? exit should almost never be used.
   • where do we find this info? needs link. not in coding conventions
5. * Where appropriate, have you used the MediaWiki wrapper functions instead of their PHP equivalents?
   • where do we find this info? needs link. not in coding conventions
6. wfIniGetBool() instead of ini_get to get boolean params
   • it doesn't seem that the various wf* functions are documented

This actually relates to a comment I just made on IRC. For first-timers, it might be good to give explanations / additional info about some (most?) of the items on the list, but most developers won't need the information after that. So, I'd like to find some way of catering to both audiences. I'm currently pondering a table version (first column: short regular checklist, second column: explanations) vs. a two-list version (short regular checklist above, same checklist with explanations below). I'd like to hear ideas / preferences / alternatives.

By the way, global functions are documented here: http://svn.wikimedia.org/doc/GlobalFunctions_8php.html#_details (Functions are below the constants)