"Ignore this" rule
| Project: | Coder |
| Version: | 6.x-1.x-dev |
| Component: | Review/Rules |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Occasionally when I'm working on a module, Coder gives me errors that are not accurate. This usually happens with either PHP's string functions (which, in many cases, are faster than the drupal_ versions) or when dynamically building SQL queries (and a safe string is inserted into a query using %sinstead of '%s').
Those errors are annoying, and get in the way when I'm trying to look at everything else. So it would be nice if there was a way to tell coder "don't check this line." It would also be a nice way to check sections of code as you're working on them if you still have some to-do items.
To do this, I propose a comment-based mechanism:
<?php
//If this appears immediately above a line of code OR on the same line as other code, don't check that line for rule violations. CL stands for "coder line."
//!CL
//This code can wrap around a block of code to tell Coder "don't check any of the code between these two lines." CB stands for "coder block" and -s and -e stand for "start" and "end," respectively.
//!CB-s
//!CB-e
?>So for example:
<?php
//This line would not be caught as a rule violation by Coder for using substr instead of drupal_substr.
$string1 = substr($string0, 1, 2); //!CL
//The same applies here, but the structure is different.
//!CL
$string1 = substr($string0, 1, 2);
//None of the code below would be validated by Coder.
//!CB-s
$string1 = substr($string0, 1, 2);
$string2 = substr($string3, 1, 2);
//!CB-e
?>I think there should be some exceptions to the rules that are not applied to code with these tags, however. Having the right number of spaces for each indent is one example.
#1
Because php is an interpretive language, I'm really leary of "coder" directives, even in comments. I'd prefer to have a separate file that wasn't read by php, that contained these directives. I think that adding a button to coder, that allowed you to select acceptable warnings, save these in the database, and ultimately write this to a separate file that could ship with the module, would be ideal.
I've changed the version to 6.x, because 5.x is feature frozen.
#2
I considered a method where clicking on the error/warning icon would save that error in the database (and would thereafter not show up) but I thought that would end up causing a lot of overhead. Your point is well-taken though.