Re: PHPCS: too much noise?

> I dutifully looked through the results and couldn't help noticing that > 95% > of stuff there is petty complaints dealing with PHPDoc comments: Take a peek at / add your comments to: http://pear.php.net/pepr/pepr-proposal-show.php?id=538 Absolutely agree re docblock comments, despite the fact I'm the one generating most of these requests :P In most cases; if something gets released and generates phpcs errors / warnings, I'll stick a request on it - active maintainer; chances are reasonable that they will make the changes at some point. If its an older package, I generally supply a patch with it. >>> I have no idea since when this CS rules applied and yes almost of them >>> are about inline doc comments. It's not a rule, just a quality metric. If a package has a very high number of errors and warnings, it means one of two things: - the code could do with refactoring for clarity / the author's style is different to the majority of PEAR - there is nothing wrong with the code, except that a tool doesn't like it The first case is the only one to worry about, and the second is usually pretty trivial to fix. So; the positive aspects of this: A year or two ago, PEPr proposals were filled with tiny nitpicks about coding style. endless comments about trivial things. Now, people just say: "Run PHPCS over your code"; and then provide other thought out comments about the general use and architechture of a potential package. Also: A lot of packages/proposals hit PEAR, make it through a few hoops and get to an alpha release, then the maintainer up and disappears after 3, 6 or 12 months. The package then tends to get bugs piling up and PEAR QA people have to step in and deal with it. If people have run PHPCS over the package and gotten the errors down to ones they will live with (long line warnings, for instance); it's a lot easier for a PEAR QA person to come along and fix bugs - the learning curve is lower, there's no new-funky-style to pick up. You might be interested in other metrics; which are generated overnight: http://pear.cweiske.de/ and http://www.lauken.com/doconnor/ final note: I'm pretty sure that most of the world does /** * ... snip ... */ public function foo() {} rather than: /** * */ public function foo() {}