Re: PHPCS: too much noise?

From: Date: Tue, 11 Nov 2008 16:00:00 +0000
Subject: Re: PHPCS: too much noise?
References: 1 2 3 4 5  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-51046@lists.php.net to get a copy of this message
Hi, Daniel O'Connor wrote:
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
These changes don't speak about Numbers of Spaces within Phpdoc Comments, either. I wonder, where exactly are those "coding standards" coming from? Can you point the source?
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.
My question is: is it worth the effort?
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)
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*?

« previous php.pear.dev (#51046) next »