Php_codesniffer: Suppress UnusedFunctionParameter with underscore prefix

Created on 23 Mar 2018  Â·  6Comments  Â·  Source: squizlabs/PHP_CodeSniffer

In cases where you need some of the parameters, but not all of them, for example:

// @codingStandardsIgnoreLine -- Not using the $slug parameter.
public function stageAction($id, $slug, $stageId)

TypeScript allows you to use an underscore prefix to suppress the error/warning, like this:

public stageAction(id, _slug, stageId)

Or, in PHP:

public function stageAction($id, $_slug, $stageId)

It's a lot cleaner and less verbose in my opinion.

The variable name sniff would need an option to allow a single underscore in front of function parameters.

Enhancement

Most helpful comment

I would like to see any solution of this problem. I encounter it too often in our project. And it's not about interface. Even if I overwrite parent class function, I have to make it compatible with parent function params. Even if I do not use them. And second problem is anonymous function. Most of the time I can't change priority how params is passed. And if I need only last param, I have to write all of them. So, everywhere I have no other option, but write ignore code "phpcs:ignore". Sometimes it's ok, but for overwriting method it's not working. If I write this comment after method description, IDE won't see description. I could write "phpcs:disable" and "phpcs:enable", but this will lead to more mess in code. Need some better solution for this.

All 6 comments

I feel like this would be far too specific to put into a core sniff because it's not an agreed standard in the PHP community. Ill leave this open to see if it gets any more support and I'm just not aware of how wide spread it is.

PR #1318 proposes changes to this sniff which would allow @glen-84 to suppress the error by excluding/including certain error codes.

I do think the PR needs some more work, but need some guidance on how to polish it off (was one of my earlier PRs to this repo).

@glen-84 PR #1318 has been merged and released as part of PHPCS 3.4.0. Did that sufficiently address this issue by allowing you to exclude certain error codes ?

It looks like with the updates to this sniff, it assumes that if there is an unused parameter in a method in a class that implements an interface, the reason for the parameter being unused must be because the method is part of the interface being implemented.

However, this isn't necessarily the case. I have multiple instances of classes that implement an interface, but also have additional methods that aren't part of the interfaces. These methods are all supplied with a second parameter that is unused, but can be used by subclasses that override the relevant methods.

While I could technically suppress the FoundInImplementedInterfaceAfterLastUsed code for these methods, it feels wrong, as that's not actually the issue. I feel like it would be a lot simpler if I could just suppress the warnings by following the convention set out in other languages - prefixing the variable name with an underscore.

@glen-84 PR #1318 has been merged and released as part of PHPCS 3.4.0. Did that sufficiently address this issue by allowing you to exclude certain error codes ?

Unfortunately not quite. The question that I asked on Gitter was related to what @mwgamble describes above (there are probably a few variations – class vs interface, etc.).

I would like to see any solution of this problem. I encounter it too often in our project. And it's not about interface. Even if I overwrite parent class function, I have to make it compatible with parent function params. Even if I do not use them. And second problem is anonymous function. Most of the time I can't change priority how params is passed. And if I need only last param, I have to write all of them. So, everywhere I have no other option, but write ignore code "phpcs:ignore". Sometimes it's ok, but for overwriting method it's not working. If I write this comment after method description, IDE won't see description. I could write "phpcs:disable" and "phpcs:enable", but this will lead to more mess in code. Need some better solution for this.

Was this page helpful?
0 / 5 - 0 ratings