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!
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.