I was just writing a procedure that is looking for a newline and I was contemplating using Environment.NewLine vs '\n'.
Syntactically: Is Environment.NewLine clearer than '\n'?
And how important is portability really?
I was just writing a procedure that is looking for a newline and I was contemplating using Environment.NewLine vs '\n'.
Syntactically: Is Environment.NewLine clearer than '\n'?
And how important is portability really?
Depends on how likely you are to run your program on another platform doesn't it?
Any builtin API that abstracts platform specific semantics/syntax is always better to use, as it provides portability without much complexity overhead, but with easy gains for using it.
Writing portable C on the other-hand might be more complex and require a stronger business case for the effort. When dealing with things like C#, Python, Java and others ... use the provided abstractions for those annoyances across platforms, which in many cases is what they are reduced to.
I would go with Environment.NewLine. This is because, depending on the language in use, we can change its definition. If we go with '\n', each compiler/language will have its own understanding and intepretation.
So, it would be preferrable to go with Environmental.NewLine.
Environment.NewLine works well, I've used it a lot in the past, however, if the app is a web app, and you insert an Environment.NewLine in the rendered html, it will have no effect in the browser window, it will however affect your source layout.
If I remember rightly Environment.NewLine will also add a carriage return if the system expects it, where \n wont.
I forgot to answer the portability aspect. I would always make my code more portable, as someone working in a consultancy I dont want to have to redevelop code so by using Environment.NewLine (for example) I would reduce the amount of work I would have to do should the code need to be reused in future.
It is not really important if the program is written for a specific known target audience/platform and you are certain its scope will not extend beyond that. But that's where the problem lies: often you cannot be certain about these things. You cannot look into the future.
Often writing portable code is not harder than writing a non-portable alternative. So, always strive to write portable code.
For those things... \n, the newline character is a fixed character in the ASCII set, so that's portable to almost anything. It's up to you to decide how important you find your code to be portable across platforms... To make this decision, figure out what the chances are of your code ever being ported to another platform. Then think what the investment will be to make it portable now vs. porting it later, when the time comes. Choose the one that's cheapest, or most convenient...
Portability aside, wouldn't one always go with Environmental.NewLine (or whatever the equivalent is on your platform) as it's simply more human readable?
Two years down the line when 'A Random Maintenance Programmer' comes along who doesn't understand the nuances of \n Environmental.NewLine is also more bullet proof.
Having portable code is a kind of a business opportunity. Say you only sell software for Windows now. Then the government of your country decides that it doesn't want to pay licensing fees to Microsoft and migrates all government institutions to Linux. If you can't quickly port your software you are no longer able to sell it to the government and that's big money.
There are two aspects to your question: how important is portability, and how do I represent a newline in a portable way.
The need for Portability is, as others said before me, a business requirement: your own private command-line tool needn't be portable, while a commercial library may better be. Based on this need you can choose the platform you're working on.
The newline character has to be recognized by your parser. If you're working in Pytho, C++, ... the parser will always recognize the '\n' sequence. If you are writing regular expressions, the '$' will be recognized as end-of-line.
If the audience of your code is acquainted with '\n', I would use that one since it jumps out as a character. If you want to emphasize the meaning of "end-of-line", go with the symbolic thing.
As they have different meaning, you should use the one that is correct for the data that you are handling.
Environment.NewLine means the newline combination for the current system.
A char/string literal like '\n' or "\r\n" means a specific newline combination regardless of the current system.
If the data is for example a text file that is produced by a regular text editor in the system, you would use Environment.NewLine to match the newlines. If the data is some data format where the newlines are defined as a specific character combination regardless of what system they are used on, you would use that specific literal.
Unless you're working on some tiny project, portability is probably very important. Even if you do program for Windows only, you will probably want your program to run on future versions of Windows. There are quite a lot of things that break in the new versions of Windows, the most common thing I see is copy protection which depends on certain obscure undocumented runtime internal structures of Windows to exist. Similarly in Unix-like O/S, you'd want that program to work on the latest kernel, which is why you must avoid using system calls and whatnot. The thing is, if your program is very non-portable against O/S or architectures, it's likely to not even be future proof. Heh, this reminds me of Windows registry/filesystem organization.