Newlines at end of file in PSR-2

2,958 views
Skip to first unread message

Greg Sherwood

unread,
Aug 5, 2012, 9:20:54 PM8/5/12
to php...@googlegroups.com
Hi all,

I'd like to know what this part of the standards requires: "All PHP files MUST end with a single blank line."

It seems that there is some confusion as to what a "blank line" actually is, probably not helped by the fact they are represented differently by different text editors.

Does this mean:
that the end of the file must contain a single newline character (i.e., stop the "no newline at end of file" messages in vi); or
that the end of the file must contain 2 newlines characters (providing a visual blank line in all text editors, and 2 in some like ST2)

The standard is not very clear here, so I can't figure out the intention of it. I'm really looking for some voting members to help me out here please, or maybe some pointers to where this might have been discussed.

Thanks

Handrus Nogueira

unread,
Aug 6, 2012, 12:21:37 AM8/6/12
to php...@googlegroups.com

Hi Greg.
The intention is to avoid problems with files ending with "?>".
So instead of closing the php tag just enter a new line.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/cfxJvzTw3qkJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Greg Sherwood

unread,
Aug 6, 2012, 2:09:06 AM8/6/12
to php...@googlegroups.com
Hi Handrus,

The ending tag is banned by another line in the standard, and that makes sense. So to be clear, are you saying that you think the end of the file should be (newlines are shown):

Option 1 (closing tag omitted only)
1. <?php[\n]
2. echo 'last line of code';[\n]

or

Option 2 (newline in place of closing tag)
1. <?php[\n]
2. echo 'last line of code';[\n]
3. [\n]

Thanks

On Monday, 6 August 2012 14:21:37 UTC+10, Handrus wrote:

Hi Greg.
The intention is to avoid problems with files ending with "?>".
So instead of closing the php tag just enter a new line.

Em 05/08/2012 22:20, "Greg Sherwood" <gshe...@gmail.com> escreveu:
Hi all,

I'd like to know what this part of the standards requires: "All PHP files MUST end with a single blank line."

It seems that there is some confusion as to what a "blank line" actually is, probably not helped by the fact they are represented differently by different text editors.

Does this mean:
that the end of the file must contain a single newline character (i.e., stop the "no newline at end of file" messages in vi); or
that the end of the file must contain 2 newlines characters (providing a visual blank line in all text editors, and 2 in some like ST2)

The standard is not very clear here, so I can't figure out the intention of it. I'm really looking for some voting members to help me out here please, or maybe some pointers to where this might have been discussed.

Thanks

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+unsubscribe@googlegroups.com.

Hari K T

unread,
Aug 6, 2012, 2:26:58 AM8/6/12
to php...@googlegroups.com
Hi Guys,

As I am the person who reported the bug I will try to say what I was doing and what phpcs was doing .

I am using Ubuntu and I feel the editor Netbeans always will go unix line feed ( I am not sure though ) .

Or probably I may be wrong also . I will say

Please find the attached screenshot for the first result is for that .

hari@vostro-lx1:/var/www/PHP_CodeSniffer$ php scripts/phpcs --standard=PSR2 ../test/CodeSniffer.php
Time: 0 seconds, Memory: 3.00Mb

I have created it via vim . I kept a blank line in the class and when opened it in Netbeans I am seeing 2 blank lines .

Then I remove one blank line and ran again the phpcs . Now it throws error as below .

hari@vostro-lx1:/var/www/PHP_CodeSniffer$ php scripts/phpcs --standard=PSR2 ../test/CodeSniffer.php

FILE: /var/www/test/CodeSniffer.php
--------------------------------------------------------------------------------
FOUND 1 ERROR(S) AFFECTING 1 LINE(S)
--------------------------------------------------------------------------------
 7 | ERROR | Expected 1 blank line at end of file; 0 found
--------------------------------------------------------------------------------

Time: 0 seconds, Memory: 3.00Mb

3 ) Now I went and added a space on line 8  and ran phpcs again . Its not throwing anymore .

I am wondering whether its the problem with netebans editor or something else .

Thanks for your time .

I am attaching the class for if anyone needs .

Hari K T
M: +91-9388758821 | W: http://harikt.com/blog



To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/ZYG3QpJQrF0J.
Screenshot from 2012-08-06 11:46:55.png
CodeSniffer.php

Carlos Campderrós

unread,
Aug 6, 2012, 4:52:14 AM8/6/12
to php...@googlegroups.com
From my experience with netbeans, if you remove the "empty" last line in a file (so the last shown line number is in a line with "content"), it will also remove the \n from the last line of the file, so the last byte in the file would be the last character in the last line.

Running hexdump on the attached file:

$ hexdump -C CodeSniffer.php
00000000  3c 3f 70 68 70 0a 63 6c  61 73 73 20 43 6f 64 65  |<?php.class Code|
00000010  53 6e 69 66 66 65 72 0a  7b 0a 20 20 20 20 70 75  |Sniffer.{.    pu|
00000020  62 6c 69 63 20 66 75 6e  63 74 69 6f 6e 20 5f 5f  |blic function __|
00000030  63 6f 6e 73 74 72 75 63  74 28 29 0a 20 20 20 20  |construct().    |
00000040  7b 0a 20 20 20 20 7d 0a  7d 0a 20                 |{.    }.}. |
0000004b
$

If opening it in netbeans, removing the last line and running hexdump again:

$ hexdump -C CodeSniffer.php
00000000  3c 3f 70 68 70 0a 63 6c  61 73 73 20 43 6f 64 65  |<?php.class Code|
00000010  53 6e 69 66 66 65 72 0a  7b 0a 20 20 20 20 70 75  |Sniffer.{.    pu|
00000020  62 6c 69 63 20 66 75 6e  63 74 69 6f 6e 20 5f 5f  |blic function __|
00000030  63 6f 6e 73 74 72 75 63  74 28 29 0a 20 20 20 20  |construct().    |
00000040  7b 0a 20 20 20 20 7d 0a  7d                       |{.    }.}|
00000049
$

You see how the last bytes have changed from "7d 0a 20" ( "}", "\n", "space" ) to just "7d" ("}"). If I edited the file in vim and just add a line in the middle of the file, the next hexdump shows a "\n" added at the end of the file:

$ hexdump -C CodeSniffer.php
00000000  3c 3f 70 68 70 0a 2f 2f  20 61 64 64 65 64 20 74  |<?php.// added t|
00000010  68 69 73 20 63 6f 6d 6d  65 6e 74 20 69 6e 20 76  |his comment in v|
00000020  69 6d 0a 63 6c 61 73 73  20 43 6f 64 65 53 6e 69  |im.class CodeSni|
00000030  66 66 65 72 0a 7b 0a 20  20 20 20 70 75 62 6c 69  |ffer.{.    publi|
00000040  63 20 66 75 6e 63 74 69  6f 6e 20 5f 5f 63 6f 6e  |c function __con|
00000050  73 74 72 75 63 74 28 29  0a 20 20 20 20 7b 0a 20  |struct().    {. |
00000060  20 20 20 7d 0a 7d 0a                              |   }.}.|
00000067
$

I think the standard wanted to say that the last byte in a file should be a \n, to avoid problems with vim or more probably with git, that shows an extra line-diff at the end of file:

$ git diff
diff --git a/CodeSniffer.php b/CodeSniffer.php
index a01a664..95465d8 100644
--- a/CodeSniffer.php
+++ b/CodeSniffer.php
@@ -1,7 +1,8 @@
 <?php
+// added this comment in vim
 class CodeSniffer
 {
     public function __construct()
     {
     }
-}
\ No newline at end of file
+}
$

What I don't know is if the standard wanted to limit how many \n should be at the end of file or if it just wanted to be sure that the last byte was a \n.
Si no puedes deslumbrar con tu sabiduría,
desconcierta con tus gilipolleces

Paul Dragoonis

unread,
Aug 6, 2012, 5:32:24 AM8/6/12
to php...@googlegroups.com
Hi Guys,

The answer is that there should always be one newline after the last
PHP-related character in the file.

"
<?php
class A {
}

"

As for the question about how many new lines? I believe that's up to
the sniffer rules to define, the standard doesn't specify. You can be
strict and limit it at one, or just be happy with the fact that there
are newlines there.

Cheers,
Paul.

Lucas Arruda

unread,
Aug 6, 2012, 6:36:50 AM8/6/12
to php...@googlegroups.com
I would be with the second option. Let's read it again: "All PHP files MUST end with a single blank line." It doesn't matter how many blank lines there are at the end of the file. At least one resolves the issue which regards this rule.

ucas Arruda

justin

unread,
Aug 6, 2012, 12:11:28 PM8/6/12
to php...@googlegroups.com
On Mon, Aug 6, 2012 at 3:36 AM, Lucas Arruda <luna...@gmail.com> wrote:
> I would be with the second option. Let's read it again: "All PHP files MUST end with a single blank line." It doesn't matter how many blank lines there are at the end of the file. At least one resolves the issue which regards this rule.

The word "single" adds ambiguity... If it ends with two, is that spec-compliant?

The phrase "blank line" adds ambiguity... Is a blank line "\n\n", e.g.
a full line with nothing between the newlines? That's what NetBeans
(and many other IDEs) considers a "blank line". Or is it just a
newline character? That's what Vim (and many other text editors)
considers a blank line.

It would be more clear to say "All PHP files MUST end with a newline character."

--j

Lucas Arruda

unread,
Aug 6, 2012, 4:19:19 PM8/6/12
to php...@googlegroups.com
I agree with u.

Lucas Arruda

FGM at GMail

unread,
Aug 6, 2012, 4:32:56 PM8/6/12
to php...@googlegroups.com
No voting rights for me, but I think that last formulation is the most
efficient "All PHP files MUST end with a newline character.". It
avoids alla mbiguities introduced by the "single" word in previous
wordings.

One might even want to specify that newline means just "\n".

2012/8/6 Lucas Arruda <luna...@gmail.com>:

justin

unread,
Aug 6, 2012, 4:56:57 PM8/6/12
to php...@googlegroups.com
On Mon, Aug 6, 2012 at 1:32 PM, FGM at GMail <fgma...@gmail.com> wrote:
> One might even want to specify that newline means just "\n".

IIRC that's specified in PSR-1.

--j

Greg Sherwood

unread,
Aug 6, 2012, 6:37:33 PM8/6/12
to php...@googlegroups.com
Thanks everyone. I'll implement the PHP_CodeSniffer rule to be: the last character in the file must be a newline character

I don't think anyone would disagree with that.

The second bit about the "single blank line" seems to imply that I should also ensure the second last character is not a newline, so there is no superflous whitespace at the end of the file. But given the standard doesn't say anything about mixing PHP with HTML/XML/etc, I guess it is conceivable that the end of a PHP file may contain raw HTML and so a couple of empty lines at the end might be exactly what is required (I'm thinking a template that contains logic and produces output, but no functions/classes/etc - I don't think that violates PSR-1). So I think it's best if I don't limit the number of newlines at the end of the file unless there are more strong opinions against this.

Thanks for all the feedback.

Greg

Paul Dragoonis

unread,
Aug 6, 2012, 7:16:43 PM8/6/12
to php...@googlegroups.com
No problem Greg, look forward to a finished result so we can start sniffing! :-)
> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To post to this group, send email to php...@googlegroups.com.
> To unsubscribe from this group, send email to
> php-fig+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/php-fig/-/RLY_8Kao8vYJ.

Paul M. Jones

unread,
Aug 6, 2012, 10:39:28 PM8/6/12
to php...@googlegroups.com
> On Mon, Aug 6, 2012 at 11:37 PM, Greg Sherwood <gshe...@gmail.com> wrote:
>> Thanks everyone. I'll implement the PHP_CodeSniffer rule to be: the last
>> character in the file must be a newline character


That's true, but not quite enough. A single blank line means "one line at the end of the file with nothing on it." Essentially this means two newline characters at the end. For example:

1. <?php
2. class Whatever
3. {
4. }
5.

Hope that helps.


-- pmj

Greg Sherwood

unread,
Aug 6, 2012, 11:21:28 PM8/6/12
to php...@googlegroups.com
So that's a bit different to what Paul was saying and is how I originally interpreted and coded it, even though it seemed a little strange (just because I've never seen a rule like that before).

Do you think it is going to have implications for templates (etc) that mix PHP logic and HTML output? You don't want that extra newline being output to screen, so do I need to detect the fact that the last bit of content in the file is not actually PHP code and change the behaviour accordingly? Not a hard thing to do if that's the case. I just want to be able to point people somewhere (here) if they ask me about why PHPCS is reporting an error that they can't fix. It's already happened with the PSR-2 standard a couple of time and I haven't even released it yet :)

Greg

Paul M. Jones

unread,
Aug 6, 2012, 11:54:04 PM8/6/12
to php...@googlegroups.com

On Aug 6, 2012, at 10:21 PM, Greg Sherwood wrote:

> So that's a bit different to what Paul was saying and is how I originally interpreted and coded it, even though it seemed a little strange (just because I've never seen a rule like that before).

/me nods


> Do you think it is going to have implications for templates (etc) that mix PHP logic and HTML output? You don't want that extra newline being output to screen, so do I need to detect the fact that the last bit of content in the file is not actually PHP code and change the behaviour accordingly? Not a hard thing to do if that's the case. I just want to be able to point people somewhere (here) if they ask me about why PHPCS is reporting an error that they can't fix. It's already happened with the PSR-2 standard a couple of time and I haven't even released it yet :)

I agree that PSR-2 is insufficiently explicit here. I would argue that the "end the file with one blank line" rule applies to files containing *only* PHP. Files with mixed PHP and HTML (or other code) would be exempt from the rule.


-- pmj

Greg Sherwood

unread,
Aug 7, 2012, 12:03:51 AM8/7/12
to php...@googlegroups.com
PHP will tokenize anything outside PHP tags as T_INLINE_HTML, so it is certainly possible for me to detect that the file contains something other than PHP. Note that it will also do this if the open PHP tag is not the very first thing in the file. So an accidental newline at the top will stop this part of the standard from being checked, and not actually generate any errors because there is nothing in the PSRs (that I can see) about spacing at the top of the file.

Is this something that needs to be discussed between voting members (maybe a minor change to the standard even?) or should I just go ahead and code in the check this way?

Greg

Paul M. Jones

unread,
Aug 7, 2012, 12:14:46 AM8/7/12
to php...@googlegroups.com

On Aug 6, 2012, at 11:03 PM, Greg Sherwood wrote:

> PHP will tokenize anything outside PHP tags as T_INLINE_HTML, so it is certainly possible for me to detect that the file contains something other than PHP. Note that it will also do this if the open PHP tag is not the very first thing in the file. So an accidental newline at the top will stop this part of the standard from being checked, and not actually generate any errors because there is nothing in the PSRs (that I can see) about spacing at the top of the file.

Ah, that's a tricky bit isn't it? You're correct, there's nothing in existing PSRs about opening blank lines. Even so, I recall ever seeing (since 1999) any incidents of accidental *opening* whitespace, so I think that case is rare enough to dismiss.


> Is this something that needs to be discussed between voting members (maybe a minor change to the standard even?) or should I just go ahead and code in the check this way?

Seeing as your code stands outside the voting process, you are free to do as you wish. I say go ahead and code it, and we can submit a vote for amendment if necessary.

Thank you for your close attention to detail. :-)


-- pmj

Greg Sherwood

unread,
Aug 7, 2012, 2:10:32 AM8/7/12
to php...@googlegroups.com
On Tuesday, 7 August 2012 14:14:46 UTC+10, pmjones wrote:

> Is this something that needs to be discussed between voting members (maybe a minor change to the standard even?) or should I just go ahead and code in the check this way?

Seeing as your code stands outside the voting process, you are free to do as you wish.  I say go ahead and code it, and we can submit a vote for amendment if necessary.

Thanks, I will go ahead with the change.

Greg

Jason Judge

unread,
Aug 7, 2012, 5:45:43 AM8/7/12
to php...@googlegroups.com
I am not a voting member, but have been following this discussion and seeing different people's interpretations going off in all directions.

I think what is causing confusion is the mixing of two concepts too tightly: the structure of a text file, and the structure of the code.

The structure of a text file should be a definition of what a line is (and we are just talking about lines of PHP code here - what happens outside of teh PHP tags is out of scope). A line is something, or nothing, followed by a newline (\n). A text file, or the PHP part of a text file, will consist of lines. Some lines will be blank (\n) and some will not (what-ever\n).

So I believe the specifications are correct in talking about "blank lines" and this is totally unambiguous to me. A blank line at the end of a file may *look* like it has "\n\n" as its last line. But actually the last blank line is just "\n". The first "\n" in the pair is a part of the last line-but-one.

So rather than trying to squeeze statements into the PSR-1 and PSR-2 standards concerning newlines, it can stick to "lines of code/comments" or "blank lines", and what they mean are dealt with at an entirely different level.

To me, trying to define what the structure of a text file is, when the aim is really defining the structure of code, is adding to a lot of ambiguity in interpretation. Maybe these PSR standards are standing too alone, and need more fundamental foundations to build on?

-- Jason

Drak

unread,
Aug 7, 2012, 6:05:03 AM8/7/12
to php...@googlegroups.com
Thank you. I was trying to find the right words to sum up what you just said.

I completely disagree with the interpretation of use statements. It's as clear as day in the words and in the given examples.

Drak

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To post to this group, send email to php...@googlegroups.com.
To unsubscribe from this group, send email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-fig/-/QegOySRba-QJ.
Reply all
Reply to author
Forward
0 new messages