Re: Revise the line length rule

In this case, I'd break the string over multiple lines using string concatenation. There are cases that should be ignorable though like the aforementioned require statements, long links in docblocks and long static method calls that are indented a couple of times. Cheers, Mike On 2011-12-19 02:09, Greg Sherwood wrote:

The ignorePattern idea is a good one, although I don't think it helps in the specific case you listed because I don't think I would ignore all lines starting with $error. In these cases, I'm just assigning long(ish) text strings to a variable, which I think is a general case that isn't clearly covered by most coding standards. The reason I don't change these lines is because I don't like the alternatives, and the PEAR standard doesn't define a clear alternative in this case. I could use herdocs or I could use string concat over multiple lines, but I don't think either of those makes the code easier to read, which is the intention of that part of the PEAR standard. Any other suggestions? Still, a good general suggestion that would certainly be worth adding to the tracker. I can imagine a lot of other cases where you might want to ignore various line formats, like include/require calls and specific parts of function comments. Greg On Sat, Dec 17, 2011 at 10:24 PM, Daniel O'Connor <daniel.oconnor@gmail.com>wrote:

Ironically: Generic_Sniffs_Files_LineLengthSniff

                $error = 'Line exceeds maximum limit of %s characters;

contains %s characters'; ... is 95 characters long, so the line length sniff would fail itself with the default configuration. What do you think of mirroring the checkstyle line length code? It has the ability to configure ignore patterns. http://checkstyle.sourceforge.net/config_sizes.html On Sat, Dec 17, 2011 at 3:09 PM, Greg Sherwood<gsherwood@squiz.net> wrote:

Hi Daniel, The first thing I do is --ignore=*/Tests/* otherwise you'd be checking

all

the test files that contains errors and warnings PHPCS is checking for during unit testing. Other than that, I use the PEAR standard, but try to eliminate errors primarily. The line length standard is a guide and doesn't need to be enforced, hence its warning status in the PEAR standard. I choose to

ignore

it in many places because of the poor variable names or extra complexity that it would require. Having said that, I do try and shorten lines where possible. It's just not on the top of my todo list. But that link was very good, thanks. It showed me the EOL char for the latest bit of contrib code was set incorrectly. I didn't pick it up, but will now change it. That will fix the one non-test file error in PHPCS.

The

other 3087, and a good chunk of warnings, are the actual test cases. Thanks Greg On Sat, Dec 17, 2011 at 2:56 PM, Daniel O'Connor<

daniel.oconnor@gmail.com

wrote:

http://test.pear.php.net:8080/job/PHP_CodeSniffer/29/checkstyleResult Do you have a preferred standard / set of rules for php_codesniffer's

own

source? Possibly one that ignores ~3000 line length warnings ?

-- Greg Sherwood Product Development Manager E gsherwood@squiz.com.au Squiz Australia Pty. Ltd. A 92 Jarrett Street, Leichhardt NSW 2040 P +61 2 8507 9900 F +61 2 8507 9988 SUPPORT 13000 SQUIZ W www.squiz.com.au AUSTRALIA UNITED KINGDOM NEW ZEALAND EUROPE UNITED STATES SYDNEY MELBOURNE CANBERRA HOBART BRISBANE SUPPORTED OPEN SOURCE SOLUTIONS