-
Notifications
You must be signed in to change notification settings - Fork 26
Consistently use php opening tag #74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Which is mandated by "3. Declare Statements, Namespace, and Import Statements".
I don't think this really applies here. I almost never see the PHP opening tags in markdown code blocks. The intent of the referenced section is that in a file you must start with the open tag, and use the long-tag version. That doesn't really apply to code snippets. Leaving this open to see if anyone else on the team disagrees, but I'm voting won't-fix here. |
(The unnecessary extra line in that one code block can be fixed in a separate PR.) |
Including the opening PHP tag
Some PSrs do include the opening tag, when conveying the context of the file, as seen in: |
I agree that the opening tag should not be mandatory for code snippets. I’m voting for wont-fix here, but probably we should define a general rule for code blocks/snippets |
I don't see value in including the PHP tag in code snippets unless the snippet encompasses the entire file so I agree this isn't something we should do. |
I agree that there's no sense in adding it in these cases. |
Separate PR: #80 |
Actually, I disagree on that specific one because it could be the full code of this file., as well. https://www.php-fig.org/psr/psr-3/#12-message This would be a prime example where I would expect the php opening tag |
While I like the consistency of having opening tags everywhere, I can see it being "too much", especially for one liners. What do you think of the alternative in #81? |
Which is mandated by 3. Declare Statements, Namespace, and Import Statements, anyway.
Kinda "eat your own dog food".
Plus, it makes it even more clear in what file type context the code examples are.
Lastly, this also fixes thie following oddly looking (and unnecessary) whitespace in 7.1 Short Closures: