Skip to main content

Environment.NewLine or "\r\n"

Ma uitam zilele astea peste un cod si am vazut de mai multe ori cod de genul acesta:
string v2 = v1 + "\n";
Scopul la acest cod este de a trece pe o linie noua. Desi functioneaza si este folosit de catre foarte multi dezvoltatori nu este cea mai buna solutie. Pentru a trece la o linie noua cei de la Microsoft au adaugat o propietatea Environment.NewLine. De fapt aceasta este o constanta ce ne returneaza "\r\n" pe Windows.
IL care se genereaza face un call la System.Environment::get_NewLine() care in spate are urmatoarea implementare pentru Windows:
.method public hidebysig specialname static string get_NewLine() cil managed
{
.maxstack 8
L_0000: ldstr "\r\n"
L_0005: ret
}
In functie de platforma NewLine poate sa difere, o implementare pentru UNIX ar contine doar "\n". Desii Environment.NewLine este mult mai clar in cod, nu cred ca se va renunta la "\r\n" deoarece nimeni nu va uita ce inseamna "\r" sau "\n". Pana se va ajunge sa se scrie aplicatii .NET care sa ruleze by default pe mai multe sisteme de operare o sa mai treaca ceva vreme.
Eu prefer si incerc sa folosesc Environment.NewLine, voi ce folositi?

Update:
Un caz cand nu se poate folosii NewLine este cand vrem sa declaram o constanta care sa contina si NewLine:
const string Text = "Hello" + Environment.NewLine + "Word!";
Din cauza ca NewLine este o propietate si nu o contanta linia de cod scrisa mai sus o sa crape.
Daca lucram cu un TextBox o sa ne trezim ca urmatoarea linie de cod nu ne da rezultatul pe care l-am astepta:
errorTextBox.Text = "Error: \n\n\";
Problema este ca TextBox-ul necesita si un CRLF, nu doar LF. In acest caz avem posibilitati:
errorTextBox.Text = "Error: \r\n\r\n\";
sau
errorTextBox.Text = "Error: "+ Environment.NewLine + Environment.NewLine ;

Comments

  1. Pe linga faptul ca la mine pe Chrome codul tau apare cu webdings font, nu sint de acord cu Environment.NewLine decit acolo unde isi are rostul. De exemplu: ai vrea ca un fisier de configuratie de aplicatie sa fie salvat intr-un fel pe Windows si in altul pe Linux? Cum faci unit testing la algoritmi? Inlocuiesti \r cu empty string ca sa pastrezi consistenta? Am avut un caz de curind in care un test care primea o constanta in surse a inceput sa pice pentru ca source-controlul a schimbat new lineurile. Asa am aflat ca standardul MIME, de exemplu, se aplica doar la \r\n. Ii dai un fisier text cu doar \n si face fail la lungime de linie sau pentru ca nu se termina cu \r\n\r\n asa cum spune RFCul. Cum faci sa mock-uesti aceasta cvasi constanta? Cum o folosesti in Attributes, etc. In plus, e incomod. Nu e nimic mai urit decit constante ca si vbCrLf din Visual Basic care trebuie concatenat cu stringuri ca sa obtii new lineuri prin ele.

    Concluzia mea: Environment.NewLine ar trebui folosit doar la output. Daca vrei sa scoti niste text pe consola, baga din asta. Cine stie, poate intr-un environment mai ciudat NewLine ar fi un <br />, dar cind e vorba de string si file manipulation, nu mai adauga dependinte aiurea.

    ReplyDelete
  2. Intr-adevar, webdings apar pe chrome (e un span style="font-style: italic; font-family: webdings;" acolo)...

    Cam singurul caz in care Environment.NewLine e util ar fi cand aplicatia produce fisiere text care vor fi citite de un human..

    .NET, Silverlight mai precis _ruleaza_ pe un sistem UNIX-like, si nu ma refer la Mono, ci la Silverlight pe MacOSX, care tot un nepot al BSD Unix e..
    Ce-i drept, ma astept ca orice text editor modern pe MacOSX sa se descurce cu cele 3 stiluri posibile de newlines.

    Cat depsre unit teste, solutia e aceeasi ca la DateTime.Now - cand ai nevoie musai de asa ceva, o tratezi ca o dependinta externa pentru care apoi se poate crea un stub sau mock.

    ReplyDelete
  3. Un caz cand nu se poate folosii NewLine este cand vrem sa declaram o constanta care sa contina si NewLine:

    const string Text = "Hello" + Environment.NewLine + "Word!";

    Din cauza ca NewLine este o propietate si nu o contanta linia de cod scrisa mai sus o sa crape.

    Daca lucram cu un TextBox o sa ne trezim ca urmatoarea linie de cod nu ne da rezultatul pe care l-am astepta:

    errorTextBox.Text = "Error: \n\n\";

    Problema este ca TextBox-ul necesita si un CRLF, nu doar LF. In acest caz avem posibilitati:

    errorTextBox.Text = "Error: \r\n\r\n\";

    sau

    errorTextBox.Text = "Error: "+ Environment.NewLine + Environment.NewLine ;

    ReplyDelete
  4. E cumva logic: pe Windows si MSDOS nu ne putem baza pe orice soft ca va recunoaste doar un \n, de aceea cel mai safe e \r\n ..

    Din pacate genul asta de control characters sunt o mostenire de pe vremea cand output-ul la programe mergea doar la o imprimanta matriciala si nu existau monitoare - doar in acel context are sens un "carriage return" (deplasarea tamburului cu hartie inapoi la dreapta, dar ramane pe aceeasi linie), respectiv "line feed", avansarea cu o linie, dar ramanerea pe aceeasi coloana.. :)
    Cand s-a trecut la CRT-uri, fiecare a interpretat aceste doua caractere cum a crezut ca e mai "logic"..

    ReplyDelete

Post a Comment

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP