views:

226

answers:

3

I writing code that should compiled and run on both Windows and unix like Linux. I know about difference between line endings, but question is which to prefer for my code? Does it matter? I want it to be consistent - say all my code uses LF only, or is it better CRLF only? Are there critaria for comparing?

If it matters mostly I care for C++ and Python codes

+2  A: 

For the code itself, it does not matter. All reasonably modern editors and compilers handle both just as well (I presume you are not using notepad :-) ). Just use the line ending of the main development platform.

Andrew Stein
not notepad but many editors on Linux show CR as ^M which anoyying
zaharpopov
most editors only show the <kbd>^M</kbd> if you have a mixture of line endings in the same file.
Ben Voigt
Xcode is one major editor that behaves improperly when editing source files with CRLF line endings.
Justin
+8  A: 

Use a version control system that's smart enough to ignore line-endings on check-in, and use the correct value for the platform on check-out.

Ben Voigt
+1. `svn propset svn:eol-style native <file>` (or the equivalent git command), and your version control software sets line ends to whatever your current platform expects.
DevSolar
what do you mean by "ignore on checkin"? What exactly is stored in the reposotory?
zaharpopov
@zaharpopov it doesn't really matters. The point is when you check out a working copy, your files get the proper line endings.
Antonio Perez
By "ignore" I mean that the check-in tool doesn't consider a file to have changed if the only difference is line endings, and therefore doesn't create a new version (of course this applies to text files only, if you tag the file as binary then every difference counts). Most tools do this by normalizing all line-endings, probably to unix `'\n'`, but there are also diff tools which can ignore `'\r'` differences as well as other whitespace changes.
Ben Voigt
+2  A: 

IME the easiest is to use *NIX line endings. Windows' compilers and IDEs can deal with it fine and it is native for *NIX tools. Using DOS line endings creates, if not problems, inconveniences with some (even the more popular) text editors on *NIX. You often get ugly '^M' at the end of the line then and you have to explicitly convert or tell your editor it has DOS line endings.

wilx