👍

What format would the ignoring of multiple disabled rules take? Comma-separation?

Comma-separated rules is what JSCS uses: http://jscs.info/overview.html#disabling-specific-rules

// jscs:disable requireCurlyBraces, requireDotNotation

👍

👍

👍

👍

scss-lint disables lint on a given "scope". See: https://github.com/brigade/scss-lint#disabling-linters-via-source

// scss-lint:disable ExampleSniff

eslint appears to work in a similar way. See: http://eslint.org/docs/user-guide/configuring.html#disabling-rules-with-inline-comments

/* eslint-disable no-alert */

In both cases it's useful to disable select lints for a given file, particularly as you're introducing new requirements over time (such as making code style stricter).

Related PEAR request: http://pear.php.net/bugs/bug.php?id=18885

👍

👍

Slevomat Coding standard has implemented something similar in its sniffs.
https://github.com/slevomat/coding-standard#suppressing-sniffs-locally

The prep for this change has been pushed: 5325170

I've added a new shorter comment syntax and put a bit more core support in. The syntax for disabling PHPCS and ignoring lines is now phpcs:disable and phpcs:ignore.

The next step is to get these comments to allow a list of sniff codes after them so they can selectively disable or ignore some errors.

If that's working, a possible extension would be to allow the new phpcs:enable syntax to re-enable selected sniff codes only, and the new phpcs:ignoreFile syntax to set ignore rules for a whole file, but I'm not sure how useful those features are and if I'll have time to do them.

@gsherwood Will we be able to put explanation text at the end of the line?

// phpcs:disable WordPress.VIP.SlowDBQuery.slow_db_query -- Because reason

Will we be able to put explanation text at the end of the line?

That's not something I had considered yet, but it's a good idea. It would need some sort of separator like you've put in your comment. Have you seen that syntax used elsewhere? Anyone else have any suggestions?

Have you seen that syntax used elsewhere? Anyone else have any suggestions?

-- is one syntax for MySQL comments, and I think that it makes sense here. Can't think of anything better off of the top of my head.

While thinking about adding selective support for phpcs:ignoreFile I realised this isn't needed. The phpcs:ignoreFile comment tells PHPCS to quickly ignore the entire file from all checking. If you want to selectively disable rules for an entire file, you would use phpcs:disable sniff,sniff instead.

So I think the last feature to add is the ability to add your own comments.

It would need some sort of separator like you've put in your comment.

What if you matched one or more spaces followed by any non-word character?

Something like this: https://regex101.com/r/w1hwws/1

(could be improved a bit, but you get the idea)

Have you seen that syntax used elsewhere?

Not really, I just use it in my own projects/at work.

What if you matched one or more spaces followed by any non-word character?

That should be possible given the data that goes into those comments, but I'd prefer to decide on a specific syntax because it makes it easier to document and test.

Hey folks, I just wanted to weigh in here on the syntax of the comments. I would really recommend that you follow the syntax for eslint because it would allow for some good overlaps.

https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments

as for the separators for "following comments", I would recommend something very simple. How about you just consider it as a list of comma separated rules which makes this valid

// eslint-disable-next-line no-console, this is more of a comment
console.log('face');

and becausethis is more of a comment doesn't match with any rule it just doesn't do anything.

Just an idea

@mansona
Wouldn't you expect it to spit out some kind of warning like "unrecognized rule" in that case?

-- is also how you add comments in Lua btw. I like the // phpcs:disable WordPress.VIP.SlowDBQuery.slow_db_query -- Because reason idea.

How about you just consider it as a list of comma separated rules which makes this valid

The new comment syntax does use a comma separated list of rules, but PHPCS doesn't know if they are valid or not because it doesn't only have a built-in list of sniffs. Plus, it allows for single words to mean something important (disable or enable an entire standard - see comment above #604 (comment)) and it supports setting sniff config vars (phpcs:set sniff var value).

I'd like a comment syntax that supports all those formats without confusion.

I could just assume they are sniff codes and throw them into the main array. But that means having to put a comma before your comment, like this:

phpcs:disable sniffCode, because reasons

And it makes life really hard if you want to comment a "disable all" style comment, like this:

phpcs:disable Because reasons

(is Because reasons a sniff code, or should it have been phpcs:disable , Because reasons?)

I think a separator is the way to go, and I think -- is probably a good one. That's going to be an easy change, so I'll implement -- and can change it later if a better idea pops up.

I've added support for additional developer comments using the -- separator.

So you can now do this:

// phpcs:disable -- Turn off PHPCS
// phpcs:disable Generic.Commenting.Todo, PSR1.Files.SideEffects -- Because reasons

etc

You can also use block comments if you want something with more explanation. In this case, you don't need to use the comment separator because the explanation is on a different line:

/*
    We pasted this code in from a library doc and it needs to
    remain as is, so disable PHPCS for this block of code.
    phpcs:disable
*/

function Foo() {}

// phpcs:enable

@Frenzie I wouldn't expect an error in this case no, this process is about turning off errors so I don't think it would be necessary.

One thing I would like to add to the wider conversation here, I use these eslint style "overrides" every day, and have been for a few years now but never have I wanted to add "extra comments" to the one line

I don't see anything wrong with the following if you really need that:

// allow for console.log here so that we can tell the user something
// eslint-disable-next-line no-console
console.log('face');

I'd much rather a simple case like this ☝️ than over-complicate the syntax.

I don't see anything wrong with the following if you really need that:

// allow for console.log here so that we can tell the user something
// eslint-disable-next-line no-console
console.log('face');
I'd much rather a simple case like this ☝️ than over-complicate the syntax.

You can do that with the new PHPCS syntax as well. The benefit of putting it all on one line (if it is a short message) is that the comment line itself is completely ignored by PHPCS and doesn't need to confirm to your standard's comment rules. That's not something I personally care about, but I think other developers do.

I'll throw this idea into feedback for a while, but I think this feature is now done.

I'm using sniff Generic.Files.LineLength. I would like to disable it for specific line. It works when I place this comment above of long line. But it does not work on same line:

[
    'foo' => 'very_long_string...' , // phpcs:disable Generic.Files.LineLength.TooLong
]

In case of $lineLimit is 30 warning occurs:

FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------
 2 | WARNING | Line exceeds 30 characters; contains 87 characters
   |         | (Generic.Files.LineLength.TooLong)

@o5 The // phpcs:disable syntax disable that error message from that comment onwards. If you want to ignore that line, you need to use // phpcs:ignore. Some docs here: https://github.com/squizlabs/PHP_CodeSniffer/wiki/Advanced-Usage#ignoring-parts-of-a-file

Edit: I'd also suggest ignoring the whole sniff given that the really long comment is probably going to push the line length to MaxExceeded. So I'd suggest // phpcs:ignore Generic.File.LineLength

@gsherwood Option $ignoreComments=true for Generic.Files.LineLength resolves my issue :)

This issue shows up a lot in the search so I just wanted to share this as a result of this discussion.

The @codingStandards syntax is deprecated as of v3.2.0, use phpcs instead.

Some examples:

For Multi-line disable

// phpcs:disable
// phpcs:enable

For Single line ignore

// phpcs:ignore

See this page for more information: https://github.com/squizlabs/PHP_CodeSniffer/wiki/Advanced-Usage#ignoring-parts-of-a-file

Peace! ✌️

Gooood feature!
One hint: Hints for the editors needed to search and select for eg: @phpcs<strg+space> :) like it works in phpunit apigen Codeception ... and others. Or does it exists and i dont know how?

I prefer using @ annotations which works like:

/**
 * ....
 * @phpcs:ignoreFile

For disabling and enabling a specific rule

// phpcs:disable WordPress.PHP.DevelopmentFunctions
error_log( $error_message );
// phpcs:enable WordPress.PHP.DevelopmentFunctions