I cannot seem to find a major PHP framework that leaves it in so I will go ahead and officially call leaving off the closing tag a best practice by reason of: common sense, prevention is better than cure, type less--not more, etc.
Let's also hope that no noobs that were doing, or trying to do, the right thing (formal company coding practice aside) were negatively impacted in the process through performance reviews, perception, compensation, or otherwise. We understand that best practices are subjective to a degree, and that features of any language or platform will be abused. I also take this opportunity to encourage the PHP developers to add features that they believe solve real world problems and continue to make life easier for other developers.
So you're advocating both adding an unnecessary and meaningless text to every file in the project and adding an external process to protect against accidental mistakes... instead of simply getting rid of both?
Greetings encoderer. Let's discuss the encodering problem at hand. So you have this scope thing yeah. In there you can put code, and in there you can't. Cool? Cool.
Now, if you open it and don't close it, that's gonna be working, but it's gonna be working using an assumption. Yeah? Yeah. So like, what is the mother of all screwups? The assumption.
So why would you ever remove it? Well now there's like all these other people claiming they wasted some time 'cause they like pressed enter a few times after the end of the scope. I mean, how much time did they waste? And was that because they were simply unfamiliar with the issue or execution environment? And who's fault is that? Really? It's not PHP's, and it's certainly not the set of other people who happen to bother being explicit as good practice.
What is the "assumption" I'm making? That my .php files will only have php code? YES! That's correct! Because we're not co-mingling PHP and HTML like it's 1999.
There is absolutely zero valid reason to have a PHP closing tag at the end of a PHP-only script.
OK, this is a semi-valid train of thought. It certainly beats the "in case of extra whitespace!" line.
And, on the face of it, it seems logical.
Unfortunately, it's not very good practice, for the reasons I have already outlined around relying on assumptions. (Edit: Oh, you missed the assumption - that the PHP interpreter will deal with your laziness)
For just one example, assume I have one file that produces a header, one file with some static content, and one file that produces a footer. For some reason, I want to refactor them in to a single file.
With explicit close, I can just concatenate the files. With the leave it out method (or, "look mom I saved two keystrokes after my MegaSillyStupidIndentFactoryClassMethod!"), you wind up with parser issues.
In short: If you want files with just PHP code in them, write files with just PHP code in them, and feed them to the PHP interpreter. If you want files with open tags in them, then use close tags.
"zero end of discussion i win mirror haha". Child.
If the files use mode switching and generate markup, feel free to put a closing ?> at the end of the php in that file. It's a template and it's expected that you would be switching in and out of html/php modes.
The recommendation is to not put them at the end of files that declare symbols, e.g. class files (or function files if you're allergic to OOP), as those files shouldn't have html mode output anyway.
> 'cause they like pressed enter a few times after the end of the scope
A large number of text editors automatically add a newline at the end of a non-empty final line. This problem doesn't have to come up because of some explicit action.
> A large number of text editors automatically add a newline at the end of a non-empty final line
... and doesn't PHP ignore it? I believe so. You actually need two newlines to cause issue, ie. "?>\n\n".
And, anyway, the solution is trivial and good practice anyway, on a number of levels. So why continue to argue? Sometimes people don't like to change their habits.
PS. Many editors can be configured to add "?>" for you, too!
