Re: PHPCS: too much noise?

>> Take a peek at / add your comments to: >> http://pear.php.net/pepr/pepr-proposal-show.php?id=538 > > These changes don't speak about Numbers of Spaces within Phpdoc Comments, > either. No Alexey, they don't - this was a link so you could add to the discussion about CS going forward.. > I wonder, where exactly are those "coding standards" coming from? > Can you point the source? Greg builds PHPCS' expected behavior from http://pear.php.net/manual/en/standards.sample.php >> 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. > > My question is: is it worth the effort? imo, absolutely :) Not because it's about applying CS changes, but because when people are authoring those changes, they are having an automated tool encourage them to review their own code. More review equates to better code. Also, having more developers more familiar with more code means less bus factor. When I've gone through and understood a package when doing PHPCS improvements; it has better enabled me to fix bugs on more than one occasion. Having more people to fix more bugs is certainly a good thing. >>>>> 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 > > Yes, and I think we should fix the tool to be less picky. Coding standards > are fine when they are dealing with actual code style. But they start to > look less like coding standards and more like spaces-in-comments standards. > The next logical step is switching to Whitespace from PHP: > http://en.wikipedia.org/wiki/Whitespace_(programming_language) See the previously mentioned link to add your comments to the next lot of CS improvements. >> final note: I'm pretty sure that most of the world does >> >> /** >> * ... snip ... >> */ >> public function foo() {} >> >> rather than: >> /** >> * >> */ >> public function foo() {} > > So what? Is that an *error*? > It's trivial to fix with a find and replace; which would quiet down many of the phpcs messages :)