squizlabs
Generic.CodeAnalysis.EmptyStatement Add option to allow only comments in statements
There are cases where it's considered valid to only have a comment in a statement, this adds an option to allow it (refs https://github.com/libero/php-coding-standard/pull/34#discussion_r233818322).
Just thinking out loud: is a property the way to go here or should this be solved via error codes, i.e. having a different error code for a completely empty statement vs an empty statement only containing a comment ?
That way, you could, for instance, exclude DetectedCatchComment, while still throwing errors for DetectedCatch and DetectedIfComment.
I like the idea of more granular errors. Might need to go for something like DetectedCatch.ContainsComment to maintain BC? (eg to not change the behaviour of https://github.com/doctrine/coding-standard/blob/0247a0d440e196d93611bd0f3c561ee12bd82789/lib/Doctrine/ruleset.xml#L24-L27)
Error codes are not supposed to contain .s, which is why I suggested DetectedCatchComment.
Adding additional error codes will be BC-break, but only a quite minor one in this case, so I suspect it would be an acceptable one, though @gsherwood can give you a more definite answer.
I prefer the new error codes over the sniff property as it is more flexible, but this BC break will silently stop existing include and exclude rules from working.
This sniff was changed to use new error codes (issues #314) so that it could be customised more easily, so I assume people are doing that today.
What PHPCS probably needs is the ability to provide aliases for message codes to allow for these sort of deprecations to occur. For example, we throw a EmptyCatchWithComment but we alias it as EmptyCatch so it still works with old rulesets. These aliases can then be removed during a major release.
