MediaWiki-Codesniffer 0.8.0 is now available for use in your MediaWiki
extensions and other projects. Here's the full list of changes since the
last release (0.8.0-alpha.1):
* Add sniff for cast operator spacing (Sam Wilson)
* Allow filtering documentation requirements based on visibility (Kunal
* Don't require documentation for test cases (Kunal Mehta)
* Don't require @return annotations for plain "return;" (Kunal Mehta)
* Explicitly check for method structure before using (Sam Wilson)
* Fix test result parsing, and correct new errors that were exposed (Sam
* Prevent abstract functions being marked eligible (Sam Wilson)
* PHP_CodeSniffer to 2.9.0 (Paladox)
This release contains a lot of new rules documenting functions and
ensuring parameters and return types are specified. It's most likely
that existing code will not pass the new rulset without documentation
improvements (see MediaWiki Documentation Day email ;)).
If you encounter any bugs or have suggestions on new rules, please reply
to this thread or file a bug in the #MediaWiki-Codesniffer Phabricator
> If you encounter any bugs or have suggestions on new rules, please reply
> to this thread or file a bug in the #MediaWiki-Codesniffer Phabricator
I ran this over a few repositories and ran into some issues.
- "@param string $name" seems fine on a method like "getItemByName()",
there's little point in making that "@param string $name The name"
- It whines if PHP builtins aren't documented. Do we really need to
document __toString() over and over again?
- Doxygen is happy to inherit documentation from the parent class for an
overridden method. Your phpcs check doesn't even honor @inheritdoc, it want
> On May 6, 2017, at 12:25 PM, Legoktm <[hidden email]> wrote:
> On 05/05/2017 01:38 PM, Brad Jorsch (Anomie) wrote:
>> I ran this over a few repositories and ran into some issues.
> Thanks for testing :)
>> - "@param string $name" seems fine on a method like "getItemByName()",
>> there's little point in making that "@param string $name The name"
> That makes sense. I'm just not sure how we could identify whether a
> parameter is trivial and doesn't need documentation versus those that do. :/
I didn't find a link to the MediaWiki-Codesniffer 0.8.0 source in this email thread, and I didn't find the method in question when I made a quick search, so I don't have any context to go by. All the same, I'm saying this as someone frequently frustrated by the lack of helpful comments in MediaWiki source code. Even if a parameter seems trivial, its purpose, meaning, format, etc., might not be obvious to someone reading the code later. The name of what? If it's the name of the item, "the name of the item" would be an improvement over "the name". What kind of item? If it's a menu item, "the name of the menu item" would be a further improvement.
>> - It whines if PHP builtins aren't documented. Do we really need to
>> document __toString() over and over again?
> Stuff like __toString()? No. Filed T164650 for that. But documentation
> is needed for things like __construct. And if you're overriding magic
> methods like __get you probably want to explain why.
>> - Doxygen is happy to inherit documentation from the parent class for an
>> overridden method. Your phpcs check doesn't even honor @inheritdoc, it want
>> everything copied.
> Filed as T164649.
> -- Legoktm
> Wikitech-l mailing list
> [hidden email] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wenlin Institute, Inc. SPC (a Social Purpose Corporation)
Software for Learning Chinese
E-mail: [hidden email] Web: http://www.wenlin.com Telephone: 1-877-4-WENLIN (1-877-493-6546)