Edit report at http://pear.php.net/bugs/bug.php?id=18885&edit=1

ID: 18885
Comment by: pwolfenden@qualys.com
Reported By: pwolfenden at qualys dot com
Summary: Please extend "inline" suppression to individual
Status: Open
Type: Feature/Change Request
Package: PHP_CodeSniffer
Operating System: linux 2.6.9
Package Version: 1.3.0
PHP Version: Irrelevant
Roadmap Versions:
New Comment:

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


Previous Comments:

[2011-10-06 20:48:24] wolfen

Added #patch


[2011-10-06 20:46:29] wolfen

Added #patch


[2011-09-30 17:33:44] wolfen

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-09-29 15:01:11] wolfen

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-29 14:54:51] wolfen

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

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


Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
postedOct 6, '11 at 6:57p
activeOct 6, '11 at 6:57p

1 user in discussion

Pwolfenden: 1 post



site design / logo © 2022 Grokbase