[RFC] Clarification on formatting for bangs (!) #4457
Conversation
It seems to me that > Add a single space around operators would mean using the practice on the bang operator as well; as discussed in [this thread](https://github.com/php-fig/fig-standards/issues/102), there is somewhat of a conflict--so this may not be the way to go. If the PSR could be amended, then this change would make sense.
|
-1, it isn't done in the Symfony standard, so it shouldn't belong here. /cc @fabpot |
|
👎 for the same reasons |
|
Symfony does not put spaces around |
|
That makes sense. I will submit a pull request with the opposite
|
|
Alright; as discussed, I have added a clarification to the opposite affect. |
| @@ -86,7 +94,10 @@ Structure | |||
|
|
|||
| * Add a single space after each comma delimiter; | |||
|
|
|||
| * Add a single space around operators (``==``, ``&&``, ...); | |||
| * Add a single space around operators (``==``, ``&&``, ...), with the excption | |||
|
I'm still not sure if it is really necessary to add this clarification. Let's see what the others think. |
|
@xabbuh Thanks--I corrected the errors you mentioned. Personally, I think the clarification is worth while as it would save folks like me some time. All the well-organized projects I had worked on until recently have had the bang spacing, and the current wording would seem to say that is the right way. The only reason I discovered the discrepancy was my having another pull request to a symfony-based project critiqued on that front, and reading a more specific coding standard would have saved me the trouble of having to go back through and adjust them all. |
| if (!isset($value)) { | ||
| return; | ||
| } | ||
| return !$value; |
There was a problem hiding this comment.
Missing empty line above return
|
the right way to say it would be |
|
@stof: I modified the language as you suggested. What do you think? |
|
|
||
| private function reverseBoolean($value = null) | ||
| { | ||
| if (!isset($value)) { |
There was a problem hiding this comment.
$value is always set. So this is a redundant check. if (!$value) would be against the CS, so I propose to add another switch which defaults to false or the like to do something else and then use if (!$theSwitch)
There was a problem hiding this comment.
indeed, we never use !isset($value) to check for null, but null === $value
| @@ -86,7 +95,10 @@ Structure | |||
|
|
|||
| * Add a single space after each comma delimiter; | |||
|
|
|||
| * Add a single space around operators (``==``, ``&&``, ...); | |||
| * Add a single space around binary operators (``==``, ``&&``, ...), with | |||
| the exception of the concatenation (``,``) operator; | |||
There was a problem hiding this comment.
Should this be a period? Or am I mis-understanding this?
|
@stof This looks sensible to me, but I'd like to have your +1 on it before I merge. |
|
👍 |
|
Thanks Bryan for the conversation and PR :). Cheers! |
…gee) This PR was submitted for the master branch but it was merged into the 2.3 branch instead (closes #4457). Discussion ---------- [RFC] Clarification on formatting for bangs (!) It seems to me that > Add a single space around operators would mean using the practice on the bang operator as well; as discussed in [this thread](https://github.com/php-fig/fig-standards/issues/102), there is somewhat of a conflict--so this may not be the way to go. If the PSR could be amended, then this change would make sense. Commits ------- ee888c6 Fixes concat operator typo 33e76a5 Incorporates @wouterj 's suggestion for more realistic usage of bang 837e895 Changes operator spacing language 835d5eb Adds missing space before return statement 3799bc0 Fixes spelling and formatting errors 30d19ab Fixes wrong bullet character 3212b6c Adds bullet addressing bang placement 95a1cc5 Reverses statement about bang spacing and corresponding examples a68d3e5 [RFC] Clarification on formatting for bangs (!)
…uggested by Symfony conventions
It seems to me that
would mean using the practice on the bang operator as well; as discussed in this thread, there is somewhat of a conflict--so this may not be the way to go. If the PSR could be amended, then this change would make sense.