Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 3.7.2

Request #18885 Please extend "inline" suppression to individual sniffs
Submitted: 2011-09-29 18:54 UTC
From: wolfen Assigned: squiz
Status: Closed Package: PHP_CodeSniffer (version 1.3.0)
PHP Version: Irrelevant OS: linux 2.6.9
Roadmaps: (Not assigned)    
Subscription  


 [2011-09-29 18:54 UTC] wolfen (Peter Wolfenden)
Description: ------------ Although I find the idea of adding "magic comments" inline to source code for use by external tools ugly, I appreciate the fact that CodeSniffer today supports "inline" suppression via the @codingStandardsIgnoreStart mechanism, because my boss has asked me to implement a system for tracking and managing "approved exceptions" to the coding standards which are adopted for each mission-critical project. What would make my life even easier would be if there were some way to indicate specific sniffs in the "off/on" inline comments (i.e. "turn sniffs X and Y off", and "turn sniff Z back on"). What I really want is a way to specify some combination of on/off sniffs "inline" along with a string which I can use as a key to look up a record (in an external DB) documenting the associated "exception" (e.g. why it exists, who is responsible for fixing it, and perhaps some other metadata). I realize that rules for excluding certain sniffs from certain files can now be controlled via XML rulefiles (which is much more elegant), but I need more "granular" control (i.e. exclusions only for certain *sections* of certain files). Test script: --------------- Here's what we can do today to turn off/on *all* validation checking for a given block of code in a specific file: // @codingStandardsIgnoreStart /* "excused" bad code here */ // @codingStandardsIgnoreEnd Expected result: ---------------- Here's an example of what I would *like* to be able to do (one sniff per line, with an external key for each "Start"): // @codingStandardsIgnoreStart MySniff key=x6cyz89 /* some code */ // @codingStandardsIgnoreStart YourSniff key=x6cyy13 /* some more code */ // @codingStandardsIgnoreEnd MySniff /* yet more code */ // @codingStandardsIgnoreEnd YourSniff Actual result: -------------- I am aware that there are various error cases that may arise with the abuse of such inline comments (e.g. an "End" with no "Start", or a "Start" with no "End"), but in each case I think the logical can be extrapolated from the current behavior of @codingStandardsIgnore*.

Comments

 [2011-09-29 19:01 UTC] wolfen (Peter Wolfenden)
The "external key" described in my request would of course be ignored by CodeSniffer, and I realize that I am free to add "key=gh78kcy" to a @codingStandardsIgnoreStart comment today if I wish to do so. The limitation of this approach is that *everything* is turned off for the "excepted block" instead of only the sniff(s) that I wish to "excuse".
 [2011-09-30 21:33 UTC] wolfen (Peter Wolfenden)
It occurs to me that if each @codingStandardsIgnoreStart comment and each @codingStandardsIgnoreEnd comment were to generate a CodeSniffer token (perhaps decorated with the name of a specific sniff and an external documentation key as suggested in the original FR) then it would be easy to write new sniffs to kick out a CodeSniffer warning for each block of code with one or more sniffs suppressed (perhaps with a URL pointing to documentation for the exception).
 [2011-10-07 00:46 UTC] wolfen (Peter Wolfenden)
 [2011-10-07 00:48 UTC] wolfen (Peter Wolfenden)
 [2011-10-07 00:58 UTC] wolfen (Peter Wolfenden)
I have attached two patches which I find useful. 1) The CodeSniffer/File.php patch provides a modest stop-gap solution to the problem posed in this F.R. by allowing me to safely use "magic comments" to suppress checking inline for certain blocks of code. The idea is that Warnings are generated automatically whenever a block of code is "suppressed" via @codingStandardIgnoreStart or @codingStandardIgnoreFile. There should be no violations "ignored silently inline" (although sniffs suppressed at the toplevel via XML exceptions will continue to be completely "silenced"). 2) The CodeSniffer.php patch makes coding standards easier to move around in my project trees, by allowing me to specify the location of my custom sniff files relative to the directory which contains the XML rule file, e.g.: <rule ref="$RULESET_DIR/Sniffs/Strings/InlineHTMLSniff.php"> Enjoy!
 [2016-10-31 04:31 UTC] squiz (Greg Sherwood)
-Status: Open +Status: Closed -Assigned To: +Assigned To: squiz
Closing in favour of the Github report (easier to manage in one place): https://github.com/squizlabs/PHP_CodeSniffer/issues/604