PSR2/SwitchDeclarationSniff: use placeholders in error messages

[ntdiary]

Description

Replace string concatenation with placeholders to follow the best practice.

Suggested changelog entry

Changed:

• PSR2.ControlStructures.SwitchDeclaration: improvements to error messages
  • defaultNotLower and caseNotLower error messages now expose 3 data values (previously 2).
  • SpaceBeforeColonDEFAULT and SpaceBeforeColonCASE error messages now expose 1 data value (previously 0).
  • BodyOnNextLineDEFAULT and BodyOnNextLineCASE error messages now expose 1 data value (previously 0).
  • WrongOpenerdefault and WrongOpenercase error messages now expose 1 data value (previously 0).

Related issues/external references

related to #1240

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the Contribution Guidelines.
• I grant the project the right to include and distribute the code under the BSD-3-Clause license (and I have the right to grant these rights).
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added XML documentation for the sniff.
• I have opened a sister-PR in the documentation repository to update the Wiki.

Other than the line mentioned in the comment below, everything else is already covered by PSR2/Tests/ControlStructures/SwitchDeclarationUnitTest.inc

[ntdiary]

I have two small questions:

1. There are 8 strtoupper($type) in this file. Is it okay to add a $typeUc var, or just keep it as-is? BTW, I've mostly seen xxxLc in the codebase, but not xxxUc.
2. This line isn't covered by tests, so I assume there might be some room for improvement here. e.g.
   • Could add a test case for it.
   • If no valid case exists, but this sniff is supposed to provide message, we might slightly adjust the above logic, since scope_opener may not always exist.
   • Or if this is sth that should be handled as a parse error, maybe we don't event need this part.

I'm still learning this, so if this question is too basic, feel free to ignore it. I can just leave it as a note. :D

[jrfnl]

@ntdiary Sorry for my slow reply.

1. There are 8 strtoupper($type) in this file. Is it okay to add a $typeUc var, or just keep it as-is?

This would absolutely be welcome and sounds like a good change which can be included in this PR.

BTW, I've mostly seen xxxLc in the codebase, but not xxxUc.

This sniff uses UC for historic reasons. I see no reason to change it at this time though.

2. This line isn't covered by tests, so I assume there might be some room for improvement here. e.g.

   • Could add a test case for it.
   • If no valid case exists, but this sniff is supposed to provide message, we might slightly adjust the above logic, since scope_opener may not always exist.
   • Or if this is sth that should be handled as a parse error, maybe we don't event need this part.

I wonder if that line is effectively dead code or if there is a test case we can throw at it.
Please feel free to investigate & get creative with test case and I'll happily look at a PR related to the issues you point out. I do believe this should be addressed in a separate PR though (different decision point).

[jrfnl]

@ntdiary Thank you for this PR. Looking good.

Please let me know if you'd like to address the duplicate strtoupper($type) function calls in this PR or if you want to move that to a separate PR. Both are valid choices and either is fine by me.

Edit: for the record - I've checked and this sniff is not extended, so these changes do not affect any other sniffs.