Blank lines at end of scripts

[Forums]

I notice that some developers have taken to adding in a blank line at the end of scripts after the ?>

Is there a reason for this? It is generally considered bad practice and can throw up unexpected errors sometimes.

Tim

[tomglare]

I notice that some developers have taken to adding in a blank line at the end of scripts after the ?>

Is there a reason for this? It is generally considered bad practice and can throw up unexpected errors sometimes.

Tim

I suspect this is because the scripts often appear without a unix end-of-text marker, probably caused by the tools/platforms used to edit text or transmit files. Therefore a programmer may add a newline at the end of the file so that the system recognizes it as a unix text file.

[Forums]

Hi Tom, the problem is that the PHP parser interprets anything outside the <?php ?> tags as being HTML, including the extra end of line characters now being added to webERP scripts. There are times (such as when using the xml-rpc functions) when webERP will crash if any characters at all are sent before the html headers are sent.

This is why it is considered bad practice in PHP coding to add this extra line in. I suspect it started by accident (some code editors add an extra line by default unless configured not to) and then pride wouldn't allow a change, so unfortunately now it seems to be standard practice

Tim

[TurboPT]

PHP's info claims that if the file is pure php [no mixed html, etc], that it is preferable to omit the closing tag. This may help avoid the aforementioned issues. [see the first sentence in the 3rd paragraph of that link]

Not having a closing tag will appear "strange" to many that always ensure that an open/close php tag pair exists, but could omitting the closing tags from the files that ARE pure php be a possibility to consider?

Of course, if omitting the closing tag is considered, then there may be a reverse hassle of future commits possibly restoring the closing tag by those not aware of why the closing tag "appears to be" missing. I guess a simple comment, perhaps in all-caps at the end of the file about NOT adding a closing tag could be added for communication.

[tomglare]

I always use the plain old "vi" editor, and in the majority of scripts from the WebERP source, it shows "[noeol]" on the status line, showing that the last line has no end-of-line character. This could mean that the file was originally in DOS format - even if you run the dos2unix command on it it will still leave the last line unterminated. Merely saving the file in "vi" will automatically add the expected end-of-line character, unless you specifically change the "vi" configuration to tell it otherwise.

It would like to think that whatever technology is used should be robust enough not to be thrown out by addition of extra whitespace, but if it is, so be it - I make sure that there are no spaces or blank lines after the closing tab. But if the "noeol" format - which I have not seen used in any other projects - is an attempt to prevent the problems mentioned, then I think this is mistaken; the end-of-line character itself should be quite safe according to the official PHP documentation, which says :

"The closing tag for the block will include the immediately trailing newline if one is present".

[Forums]

Hi Tom,

The issue with php is that anything outside the <?php ?> tags is sent straight to the browser as output. If the script is interpreted before the http headers are sent then the characters (eol/tabs/spaces etc) get sent to the browser. This causes issues with api calls and with pdf creation.

White space is often critical in coding - look at Python for instance.

Thanks
Tim

[tomglare]

Don't get me wrong - I am not disputing the fact that, like it or not, the extra whitespace can cause problems; I was simply offering an answer to the original question, which was "... Is there a reason for this? ...", the reason being that programmers were saving scripts as "normal" unix files and mistakenly adding a blank line in the course of this. As I said, I would ensure there are no blank lines or spaces after the closing tag, and that way there is no whitespace of any sort, because, as I quoted from the documentation, the trailing newline is counted as PART of the tag.

Not sure if leaving out the closing tag is the right thing to do - is this still going to work e.g. with "include" directives? Have not had time to think that through, but from the point of view of issuing development guidelines, it would be simplest to specify a single policy that could be applied to all the scripts.

[Forums]

I agree that leaving out the closing tag altogether is considered best practice these days.

[opto]

leaving out the closing tag is only safe if there is no html in the file.

If any html would be added, the programmer would always need to check whether there is a tag, and add it if not.
That feels very error prone.

[icedlava]

It is recommended to leave off the closing php tag if there is no escaped HTML in the file.

This might be recommended but to me it seems like a bit of a lazy and possibly error prone solution instead of ensuring there is no white space after the closing tag - something that PHP programmers would normally check or educate others to do (since PHP was invented).

It is a bit like HTML5 compared to XHTML - you do not have to use closing tags however I always do. Again seems lazy otherwise and somehow making it harder or lead to possible problems if we later want to check, read, or do something with or process that HTML.

So, I prefer to have a rule - end all php files with a closing tag and ensure there is no trailing white space (or fix your editor to ensure it - along with having unix line endings).

However, consistency is better than none -whatever ruling is made for the project I'll stick to it and hope we all use the same rule.

Cheers,