2

What do you recommend as a default fallback for line endings if the operating system cannot be determined?

Example

Mac OS up to version 9 uses carriage returns (\r) for line endings. Unix-like systems do line endings with line feeds (\n) and Windows uses two characters (\r\n) to mark a line ending.

What's the best fallback which is most compatible for all mentioned systems when writing code files which are exchanged with developers on different platforms?

5
  • 3
    ... and why do we still have to care in 2014? – JensG Nov 8 '14 at 14:41
  • 1
    This question is unanswerable without more context. How are the files exchanged between users? Is there a canonical version? How much effort do you want to spend doing conversion? – kdgregory Nov 8 '14 at 15:14
  • Files are exchanged via GitHub. – Benny Neugebauer Nov 8 '14 at 15:22
  • 1
    Isn't there a git setting for this purpose? At the bottom of that page there are some more links, especially this one. – JensG Nov 8 '14 at 16:32
  • Can you honestly say you know one extant OS that isn't capable of telling an application what OS it is? – Kilian Foth Nov 8 '14 at 18:27
6

I would vote for CRLF:

  • Windows is still the most widely used OS for personal computing, therefore all other OSs have ways to deal with DOS line endings
  • The opposite is not necessarily true, not all Windows apps can deal with Unix or Mac line endings
  • CRLF is also the line ending for all Internet Standards and RFCs, e.g. HTTP, MIME, Usenet, Internet Mail, vCard, iCal etc.
3
  • I agree with first 2 points, but I think Standards and RFCs you mention are irrelevant to the choice of EOLs. It's kind of a strange reasoning: "HTTP, MIME, Usenet, Internet Mail, vCard, iCal and others use CRLF, so I should write my Java code using CRLF too." – scriptin Nov 8 '14 at 17:20
  • 1
    Basically, you'll still get the correct behavior on Mac / Unix with CRLF whereas you won't with Windows using just CR. – Andy Nov 8 '14 at 17:26
  • 1
    @scriptin: It means that if you choose CRLF as your line format, you can be sure that it will work on all systems that are capable of connecting to the web or processing emails. OTOH, if you choose CR or LF or even something else entirely, there is no such guarantee. – Jörg W Mittag Nov 8 '14 at 17:43
0

For interpreted languages: use one that is supported by an "execution platform" (e.g. an application server) OS. That's because you should probably use the same OS for development in a first place. Also you may find yourself in a situation when you need to read or change (not a good idea, but possibility) deployed sources.

For compiled languages: I see no reasons why any choice should be favored, except there is some explicit requirement or if the majority of developers use any particular OS.

0

My 2¢:

  • Pick any EOL encoding you want, but make sure it plays well with your build system, compilers, interpreters, etc.
  • Make sure that this is cleanly explained in your wiki page, readme files, etc, intended for contributors.
  • On the same page explain how to git config core.eol properly, so that contributors have an easy time sending pull requests.

Hopefully after that you'll be able to stop caring about EOLs in source files.

Not the answer you're looking for? Browse other questions tagged or ask your own question.