Re: Revise the line length rule

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 > > > > > -- 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