As a follow-up to http://drupal.org/node/212737, which does a *great* job checking for "// Something something \n", that same error should also trigger if the line is "\s+\n" rather than just "\n".
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 222672.patch | 1.94 KB | douggreen |
| #4 | coder-check-blank-lines-222672-4.patch | 1.85 KB | webchick |
| #3 | coder-check-blank-lines-222672-3.patch | 2.47 KB | webchick |
Comments
Comment #1
douggreen commentedThe rule we wrote for #212737 doesn't catch this because coder strips blank lines before storing them and sending them through the rules engine. If we removed this optimization, then the existing rule would catch it. See line 898-920 of coder.module and all of the
if (trim(...) != '')conditionals. These would need to be removed. They do provide some level of optimization though, preventing sending "mostly" blank lines through the rules engine. Do you think it's worth removing?Comment #2
webchickAh, I figured this had to be trim()ed somewhere, because changing that rule didn't seem to affect anything.
As to whether or not to remove that optimization, hm. That's a good question.
The extra whitespace certainly doesn't hurt anything; it just looks kinda sloppy. However, certain editors (Zend, for one) are smart enough to strip out trailing whitespace on these types of lines, and will do it for you automatically, leading to "noise" in patches from people using those editors. These lines are also basically impossible for the "human eye" to spot these things, and seems like a perfect opportunity for a computer to do your checking for you. :)
I guess given that, I would be in favour of removing the optimization... or, rather, leaving it in only for lines that are just \n and nothing else; no sense in running all of those rules on the plain newline between one function and another, for example.
Comment #3
webchickHere's a patch that does the above.
It looks like this whole section could be simplified by storing the various types of lines in an array or something and just iterating through them. Currently, it looks like there are quite a few lines that need to be added if we ever decided to add a new type of line in the future. But I've kept this patch simple for now.
Comment #4
webchickOops, sorry. That had the menu link fix in there accidentally.
Comment #5
douggreen commentedDid you test this patch? Does it work on Windows, or do we need to trim \r\n?
Comment #6
webchickI did test this patch, but not on Windows (I'm on OS X). That's a good question, though. Hrm... not sure how to deal with that.
Comment #7
webchickI went into Smulton and saved it as "Dark Side" line endings ;) and confirmed that this definitely doesn't strip those out. Will keep futzing.
Comment #8
douggreen commentedI think that the simple solution is to convert the existing
trim()calls totrim(..., "\r\n"). I haven't tested this, but IIRC, that's the correct syntax.Comment #9
stella commentedHmmm doesn't
trim()by default also remove\r\ntoo? See www.php.net/trimComment #10
douggreen commentedThe problem is that trim removes spaces, tabs, carriage returns, and newlines, but webchick would like to just remove the carriage returns and newlines, so that the rule that checks for extra spaces works.
Comment #11
stella commentedAh, sorry, yes then
trim(...., "\r\n")should do what you want.Comment #12
douggreen commentedHere's the patch mentioned above. Can someone please test it? Thanks!
Comment #13
stella commentedThis is good to go!
Cheers,
Stella
Comment #14
douggreen commentedStella, since you tested and confirmed, can you also commit it? Thanks!
Comment #15
stella commentedCommitted - I also made a similar change to the 5.x branch.
Cheers,
Stella
Comment #16
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.