Question: what scenarios would using post inc/dec cause issues if code were moved around? about phpcsextra HOT 3 CLOSED

@keevan This is not really a place to ask these questions as this is not a support forum for standard designers, but a place to report bugs in sniffs and/or request new sniffs.
Whether you want to add a sniff or not, is up to the individual standards designer.

Please also know that if you like some errors in a sniff, but not others, you can choose to include/exclude based on error code.

<rule ref="Universal.Operators.DisallowStandalonePostIncrementDecrement">
    <exclude name="Universal.Operators.DisallowStandalonePostIncrementDecrement.PostIncrementFound"/>
    <exclude name="Universal.Operators.DisallowStandalonePostIncrementDecrement.PostDecrementFound"/>
</rule>

... is effectively the same as...

<rule ref="Universal.Operators.DisallowStandalonePostIncrementDecrement.MultipleOperatorsFound"/>

The short version of "why this sniff was added", comes down to:

1. I've seen too many devs not know the difference and treating pre/post-increment/decrement as if they were doing the exact same thing.
2. This is largely caused by most code samples of for loops using $i++ in the third part of the condition and devs only knowing that form, but not actually realizing that ++$i and $i++ will only do the same thing when used in stand-alone statements.
3. As soon as incrementing/decrementing is combined with other code, the difference will cause different behaviour/results, which is where the bugs come in (and I've had to fix enough of those).
4. In too many of those cases, the bug was caused by the dev not knowing about pre-increment/decrement or not knowing the difference between pre and post-increment/decrement and expecting the behaviour to be the same. The intended behaviour was in most cases pre-increment/decrement.
5. That combined with the minor performance (memory usage) improvement, made that it seemed like a good sniff to add, especially as it should also help educate devs about the difference.

Also have a look at: https://3v4l.org/hLVgC which will stump every dev who doesn't know/understand the difference.

As for why the sniff only checks stand-alone statements - the sniff cannot determine whether the post-increment/decrement was intentional or is a bug and auto-fixing non-stand-alone statements would cause a change in the behaviour of the code, which is something sniffs should not do.

Hope this helps a little.

from phpcsextra.

Thank you @jrfnl. I appreciate the time you've taken to give a detailed explanation, laying it all out, as well as going further and creating the example code snippet.

Yes, it is a topic many devs might not be familiar with, and it might be because some never needed to deal with it as extensively. In that respect usage may differ from project to project.

I've never thought about copying the $i++ and combining it directly with other code without giving it some thought. But from your experience, it seems like this happens with devs more often than I thought, and so the sniff aims to preemptively protect against such misuse 👍

I'm happy to close this for now. And I'm sure a future traveler would find this extra bit of documentation / discussion useful.

from phpcsextra.

And I'm sure a future traveler would find this extra bit of documentation / discussion useful.

Indeed ;-)

from phpcsextra.