PSR-2 : Linefeeds versus Newlines

1,245 views
Skip to first unread message

Anthony Watson

unread,
Apr 13, 2016, 12:14:59 AM4/13/16
to PHP Framework Interoperability Group
Hey all,

The current accepted version of PSR-2 has the recommendation :

All PHP files MUST use the Unix LF (linefeed) line ending.

This rule leaves it ambiguous whether or not CR+LF is acceptable. The rule--as it currently stands--could be interpreted in a few ways:
  1. All PHP files MUST use the Unix LF (linefeed) line ending. All PHP files MUST NOT use the combined (CRLF) line ending.
  2. All PHP files MUST use the Unix LF (linefeed) line ending. All PHP files SHOULD NOT use the combined (CRLF) line ending.
  3. All PHP files MUST use the Unix LF (linefeed) line ending. All PHP files SHOULD use the combined (CRLF) line ending.
The subtle difference between these three are that in version 1, CRLF is explicitly forbidden; in version 2, CRLF is acceptable but standalone LF is preferred; in version 3, CRLF is actually preferable to a standalone LF, but an LF is mandatory.

I think it needs to be made more clear whether the rule means "a single LF MUST be used, and a CR+LF must/should not be used" or it is meant to be read only as an endorsement for the LF, without regards to its use in CR+LF.

Reasons why this is important:

1. Tools such as php-cs-fixer may interpret this rule to mean "replace existing CRLF line endings with a single LF" or might interpret the rule to mean "LF must be used, so CRLF is fine". Similarly, this rule leaves it vague for how a validator would handle a CRLF line ending.

2. CRLF is the preferred line-terminator for many official web-standards, such as SMTP, iCalendar, vCard, etc. So if CRLF is acceptable (allowed), then some programmers/developers may prefer to consistently use CRLF, or at least know the specific standing on CRLF for each standard (such as PSR-2) to know when it is not allowed/acceptable.

Thanks for reading!

~~ Anthony

Alessandro Pellizzari

unread,
Apr 13, 2016, 5:25:08 AM4/13/16
to php...@googlegroups.com
On 13/04/2016 05:14, Anthony Watson wrote:

> Hey all,
>
> The current accepted version of PSR-2 has the recommendation :
>
>
> All PHP files MUST use the Unix LF (linefeed) line ending.

From my POV this is unambiguous. "Unix LF line ending" means "only LF".

CRLF is "Windows line ending" and CR is "MacOS legacy line ending".

Bye.

Mathew Whitney

unread,
Apr 13, 2016, 10:42:45 AM4/13/16
to PHP Framework Interoperability Group
The use of CRLF in web standards should have no impact in this case. Most of those standards carried over the conventions from earlier tools which designated CRLF primarily as a cross-platform solution in the earliest days of computer networking. One explanation can be read here: https://www.rfc-editor.org/old/EOLstory.txt

If you are formatting a message for output at a low enough level at which one of those standards comes into play, you need to be explicit about your use of CRLF anyway, and should not rely on the line endings configured in your editor. In some standards you would strip all line endings from the message as a matter of course, in others you would replace them with "/r/n", and in still others you might ignore them in the message, but insert "/r/n" to break the message into lines of a specific length.

In my opinion, the use of "Unix" in this context is enough of a clue to prevent most people from finding ambiguity regarding the intent that all line endings use LF and not CRLF. However, it could be made more explicit in PSR-12.

Larry Garfield

unread,
Apr 13, 2016, 12:39:55 PM4/13/16
to php...@googlegroups.com
I agree, I've always understood that part of PSR-2 to mean "LF, and only
LF". Clarifying that in PSR-12 should be easy enough, though.

--
--Larry Garfield

Alexander Makarov

unread,
Apr 14, 2016, 5:28:51 AM4/14/16
to PHP Framework Interoperability Group

Anthony Watson

unread,
Apr 14, 2016, 6:12:15 AM4/14/16
to PHP Framework Interoperability Group
 I feel like I stumbled into a Jets rally asking if they **really** hated the Sharks or if this was left ambiguous when they sang
 When you're a Jet, you're a Jet all the way From your first cigarette to your last dyin' day!
Like, maybe being so PRO Jet still leaves the idea of being pro Shark as well.

It is now clear to me that there are three "types" of line-endings :
  • LF - The cool, correct, pro, and street, and geek line ending used by Unix
  • CR - The dusty old ending for pre-OSX versions of Apple
  • CRLF - The wretched clunky compromise that Windows and DOS introduced to fix a problem that wan't really a problem.
Thus LF or CR should never be mistaken as "CRLF OR LF", since CRLF is a beast all its own. 

Here's why it crossed my path and got me to writing the original post:

1. I didn't know that these three line-ending groupings were considered so mutually exclusive of one another. Which was silly and naive of me to not expect tribal opinions from my same peer group that goes to blood wars over vim vs emacs and are known to start bar-brawl level shouting over GNU licensing versus BSD.

2. So not realizing that "Must use LF" is equivalent to "Must not use CR or CRLF", I naively thought of LF as an option that could exist as either a plain LF or as CRLF, with the rule being more about "hey, you Windows shmucks, can you remember to throw in an LF if you are going to use CR? Yknow, so it looks right in my editor?"

3. The main reason I got to writing this was because in the last 2–3 weeks, I've encountered an exceptionally higher number of scripts/documents that contain a mix of standalone CR and occasional CRLF.  So something seems to be wonky and growing in popularity, and I wanted to see what the official PSR-2 ruling was on line endings, since I wanted to fix it so that all of the stray CRs were changed to CRLF (which would fulfill the rule of "MUST USE LF"), or if I should instead zap all CRLFs to plain LF and then any remaining CRs to LF.  Point being, I seriously doubt that there is a sudden surge of developers out there who have decided to go retro and do all of their coding on an Acorn, or are hammering out code on their G3 Blue and White running Mac OS 9. So some modern tools are the likely source of the trouble, like maybe a web-editor or some snazzy IDE or whatever, something that defaults to "CR" for line endings. Which, in the grand hierarchy of pet peeves, surely it must be ordered "CR" (worst); "CRLF" (acceptable Windows BS); "LF" (ideal). So having the style guide/code standard say something like :

i. All PHP files MUST use the Unix LF (linefeed) line ending. 
ii. All PHP files MUST NOT use the CR (carriage return) line ending. 
iii. All PHP files SHOULD NOT use the Windows CRLF (linefeed + carriage return) line ending.
iv. All PHP files MUST use the same line ending consistently throughout the script; the file; the project.

So that any tools or default settings or whatever that might be floating around and getting adopted subliminally can be pointed to as *definitely* wrong (rule ii) as well as definitely *not right* (rule i). If I'm seeing standalone CR line endings in the handful of files I peruse one a more frequent basis, some trend or tool is causing this, and having clear and unambiguous rules is the only way we can all be sure we're fixing/repairing these issues as we each encounter them separately.

Many thanks to Alexander M. for filing an official issue for this.

Stefano Torresi

unread,
Apr 14, 2016, 7:41:50 AM4/14/16
to php...@googlegroups.com
Hi Antony, 

To be honest, I don't understand what's all the fuss about.

CRLF is not LF. LF and LF only is allowed, end of story.
 
> iii. All PHP files SHOULD NOT use the Windows CRLF (linefeed + carriage return) line ending.

That's not the case. CRLF MUST NOT be used.


iv. All PHP files MUST use the same line ending consistently throughout the script; the file; the project.

That's not necessary since only one type of line ending is allowed.

Cheers

FGM at GMail

unread,
Apr 14, 2016, 7:54:40 AM4/14/16
to php...@googlegroups.com
Not sure it's entirely the same issue, but does this cover the "single LF at end of file" specifics ?

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFojS1vKRrbL76m_%3DNxK0DsWCefZUZH_Sf9tnnpejuciyC8eow%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Benni Mack

unread,
Apr 14, 2016, 8:02:21 AM4/14/16
to PHP Framework Interoperability Group
Hey FGM,

that's also covered:


"a single blank line" and "no closing PHP tag" clears it up, or is this also unclear for you in PSR-2?

All the best,
Benni.

-- TYPO3 Core Team Leader

FGM at GMail

unread,
Apr 14, 2016, 8:10:16 AM4/14/16
to php...@googlegroups.com
ISTR there having been some discussions on what the "single blank line" actually involved.

AIUI, it means the last two bytes in any text file MUST be 0x0A, 0x0A, and the last three bytes MUST NOT be 0x0A 0x0A 0x0A, but I'm not sure this is entirely clear.

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

Jason Judge

unread,
Apr 15, 2016, 6:48:07 AM4/15/16
to PHP Framework Interoperability Group
On Thursday, 14 April 2016 13:10:16 UTC+1, FGM wrote:
ISTR there having been some discussions on what the "single blank line" actually involved.

AIUI, it means the last two bytes in any text file MUST be 0x0A, 0x0A, and the last three bytes MUST NOT be 0x0A 0x0A 0x0A, but I'm not sure this is entirely clear.

Your interpretation is what I would argue the PSR strictly says, when it talks about a "blank line" on the end of the file. But that was not the intent. The "blank line" was a description of the situation as viewed from *some* types of code editor, and has nothing to do with how the file is actually terminated. From previous discussions, the intent was that the file should end with a *single* LF - not two, and it should also not be left out.

IMO it comes down to a much simpler set of rules:

* The PHP file consists of lines.
* A line MUST be terminated with a single LF.
* A blank line consists of just a LF.
* The file MUST NOT end with any blank lines.

So what was intended, is arguably the complete opposite of what PSR-2 actually says, when it talks about ending the file with a blank line.

Jason Judge

unread,
Apr 15, 2016, 6:52:16 AM4/15/16
to PHP Framework Interoperability Group


On Wednesday, 13 April 2016 05:14:59 UTC+1, Anthony Watson wrote:
Hey all,

The current accepted version of PSR-2 has the recommendation :

All PHP files MUST use the Unix LF (linefeed) line ending.

This rule leaves it ambiguous whether or not CR+LF is acceptable. The rule--as it currently stands--could be interpreted in a few ways:
  1. All PHP files MUST use the Unix LF (linefeed) line ending. All PHP files MUST NOT use the combined (CRLF) line ending.
  2. All PHP files MUST use the Unix LF (linefeed) line ending. All PHP files SHOULD NOT use the combined (CRLF) line ending.
  3. All PHP files MUST use the Unix LF (linefeed) line ending. All PHP files SHOULD use the combined (CRLF) line ending.

Don't forget, this is not the law. This is a convention chosen for people to use and share if complying with PSR-2. There are no arguments about what is better or worse in the PSRs - they are about choosing and approach and using it for consistency. Then we can forget about those decisions and get on with creating code.
Reply all
Reply to author
Forward
0 new messages