POC - Allow short ternary for false #287
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi @ondrejmirtes
I recently encountered situation where short ternary could be considered useful, for instance when using
Datetime::createfromformat
. https://www.php.net/manual/en/datetime.createfromformat.phpSince the return type is
object|false
there is no risk writingand this is way shorter than
But in other cases I do like to forbid short ternary because things like
is risky, I might have forgot that
0
will end in the default value.So if you're interested I see two solutions:
nonFalsey|false
conditions (and maybe updating the error message behind the bleeding edge tag)nonFalsey|false
conditions (maybe you'll have a naming suggestion for this one ?), and when the option is enabled I think the error message should be changed too. (like "Short ternary is not allowed on non boolean falsey type. Use null coalesce operator if applicable or consider using long ternary.")This is currently a POC which should be updated based on your preferences. :)
Looking at how sometimes some rules are loosen up (like in 8afd4af), I think it could be ok to relax the forbid ternary rule without an option. But your call.
This would also close #268 (Should I assume that since you didn't close the issue, you're open to some suggestion ?)