Is your feature request related to a problem?
The Generic.Functions.OpeningFunctionBraceKernighanRitchie accepts a checkClosures property, false by default, that determines whether the sniff should also check closures. Because closures, unlike functions, support an additional use clause, sometimes formatting and indentation can be trickier to get right. For example, in:
$closure = function ( string $firstArgument, string|bool|null $secondArgument = null )
use ( $firstUsedVariable, $secondUsedVariable, $thirdUsedVariable, $fourthUsedVariable )
{
echo 'Function body starts here';
};
Here, changing the brace style allows better separation between the parameter and use list and the function body.
Of course we could argue on the best™ way to indent the use and the rest, and perhaps there's a way that works better than mine. However, that's beyond the point here. Instead:
Describe the solution you'd like
It would be nice if the sniff used different error codes for closures. This way, individual coding standards would have more flexibility, and potentially disable problematic checks for closures. In the example above, one would disable Generic.Functions.OpeningFunctionBraceKernighanRitchie.BraceOnNewLine to allow that style while still benefitting from the other checks. However, this currently uses the same code for functions and closures, so it's not possible to do this selectively for closures.
For example, the sniff could use:
Generic.Functions.OpeningFunctionBraceKernighanRitchie.X for functions
Generic.Functions.OpeningFunctionBraceKernighanRitchie.ClosureX for closures
Additional context (optional)
Strictly speaking, the sniff also has a checkFunctions option to toggle functions checks, enabled by default. However, assuming that functions are more common than closures, and considering the default states of the two toggles, as well as reducing backward compatibility breaks, I think it makes sense to keep using unprefixed error codes for functions, and add a prefix for closures only.
NB, I'll first wait to hear whether this proposal would be accepted before working on an implementation.
Is your feature request related to a problem?
The
Generic.Functions.OpeningFunctionBraceKernighanRitchieaccepts acheckClosuresproperty, false by default, that determines whether the sniff should also check closures. Because closures, unlike functions, support an additionaluseclause, sometimes formatting and indentation can be trickier to get right. For example, in:Here, changing the brace style allows better separation between the parameter and
uselist and the function body.Of course we could argue on the best™ way to indent the
useand the rest, and perhaps there's a way that works better than mine. However, that's beyond the point here. Instead:Describe the solution you'd like
It would be nice if the sniff used different error codes for closures. This way, individual coding standards would have more flexibility, and potentially disable problematic checks for closures. In the example above, one would disable
Generic.Functions.OpeningFunctionBraceKernighanRitchie.BraceOnNewLineto allow that style while still benefitting from the other checks. However, this currently uses the same code for functions and closures, so it's not possible to do this selectively for closures.For example, the sniff could use:
Generic.Functions.OpeningFunctionBraceKernighanRitchie.Xfor functionsGeneric.Functions.OpeningFunctionBraceKernighanRitchie.ClosureXfor closuresAdditional context (optional)
Strictly speaking, the sniff also has a
checkFunctionsoption to toggle functions checks, enabled by default. However, assuming that functions are more common than closures, and considering the default states of the two toggles, as well as reducing backward compatibility breaks, I think it makes sense to keep using unprefixed error codes for functions, and add a prefix for closures only.NB, I'll first wait to hear whether this proposal would be accepted before working on an implementation.