Editing Newline (section)

=== In programming languages ===
{{Redir|\n|the similar number notation|\nnn (disambiguation)}}
To facilitate creating [[Porting|portable]] programs, [[programming language]]s provide some abstractions to deal with the different types of newline sequences used in different environments.

The [[C (programming language)|C language]] provides the [[escape sequence]]s <code>\n</code> (newline) and <code>\r</code> (carriage return). However, these are not required to be equivalent to the ASCII {{mono|LF}} and {{mono|CR}} control characters. The C standard only guarantees two traits:
# Each of these escape sequences maps to a unique implementation-defined number that can be stored in one {{mono|char}} value.
# When writing to a file, device node, or socket/fifo in ''text mode'', <code>\n</code> is transparently translated to the native newline sequence used by the system, which may be longer than one character. When reading in text mode, the native newline sequence is translated back to <code>\n</code>. In ''binary mode'', no translation is performed, and the internal representation produced by <code>\n</code> is output directly.

On [[Unix]] [[operating system]] platforms, where C originated, the native newline sequence is ASCII {{mono|LF}} ({{mono|0x0A}}), so <code>\n</code> was simply defined to be that value. With the internal and external representation being identical, the translation performed in text mode is a [[NOP (code)|no-op]], and Unix has no notion of text mode or binary mode. This has caused many programmers who developed their software on Unix systems simply to ignore the distinction completely, resulting in code that is not portable to different platforms.

The [[C standard library]] function {{mono|[[fgets]]()}} is best avoided in binary mode because any file not written with the Unix newline convention will be misread. Also, in text mode, any file not written with the system's native newline sequence (such as a file created on a Unix system, then copied to a Windows system) will be misread as well.

Another common problem is the use of <code>\n</code> when communicating using an Internet protocol that mandates the use of ASCII {{mono|CR}}+{{mono|LF}} for ending lines. Writing <code>\n</code> to a text mode stream works correctly on Windows systems, but produces only {{mono|LF}} on Unix, and something completely different on more exotic systems. Using <code>\r\n</code> in binary mode is slightly better.

Many languages, such as [[C++]], [[Perl]],<ref>{{cite web |title=binmode |url=https://perldoc.perl.org/functions/binmode |work=Perl documentation |publisher=Perl 5 Porters}}</ref> and [[Haskell]] provide the same interpretation of <code>\n</code> as C. C++ has an [[Input/output (C++)|alternative input/output (I/O) model]] where the manipulator {{mono|std::endl}} can be used to output a newline (and flushes the stream buffer).

[[Java (programming language)|Java]], [[PHP]],<ref>{{cite web |title=PHP: Strings - Manual |url=https://www.php.net/manual/en/language.types.string.php#language.types.string.syntax.double |work=PHP Manual |publisher=The PHP Group}}</ref> and [[Python (programming language)|Python]]<ref>{{cite web |title=2. Lexical analysis |url=https://docs.python.org/3.11/reference/lexical_analysis.html#string-and-bytes-literals |work=The Python Language Reference |publisher=The Python Foundation}}</ref> provide the <code>\r\n</code> sequence (for ASCII {{mono|CR}}+{{mono|LF}}). In contrast to C, these are guaranteed to represent the values {{mono|U+000D}} and {{mono|U+000A}}, respectively.

The [[Java Class Library]] [[input/output]] (I/O) methods do not transparently translate these into platform-dependent newline sequences on input or output. Instead, they provide functions for writing a full line that automatically add the native newline sequence, and functions for reading lines that accept any of {{mono|CR}}, {{mono|LF}}, or {{mono|CR}}+{{mono|LF}} as a line terminator (see [http://download.oracle.com/javase/6/docs/api/java/io/BufferedReader.html#readLine%28%29 {{mono|BufferedReader.readLine()}}]). The {{mono|[http://docs.oracle.com/javase/8/docs/api/java/lang/System.html#lineSeparator-- System.lineSeparator()]}} method can be used to retrieve the underlying line separator.

Example:
<syntaxhighlight lang="java">
   String eol = System.lineSeparator();
   String lineColor = "Color: Red" + eol;
</syntaxhighlight>

Python permits "Universal Newline Support" when opening a file for reading, when importing modules, and when executing a file.<ref>{{cite web |title=What's new in Python 2.3 |url=https://www.python.org/download/releases/2.3/highlights/ |publisher=Python Software Foundation}}</ref>

Some languages have created special [[variable (computer science)|variables]], [[constant (computer programming)|constants]], and [[subroutine]]s to facilitate newlines during program execution. In some languages such as [[PHP]] and [[Perl]], [[double quotes]] are required to perform escape substitution for all escape sequences, including <code>\n</code> and <code>\r</code>. In PHP, to avoid portability problems, newline sequences should be issued using the PHP_EOL constant.<ref>{{cite web |title=PHP: Predefined Constants - Manual |url=https://www.php.net/manual/en/reserved.constants.php |work=PHP Manual |publisher=The PHP Group}}</ref>

Example in [[C Sharp (programming language)|C#]]:
<syntaxhighlight lang="C#">
   string eol = Environment.NewLine;
   string lineColor = "Color: Red" + eol;
   
   string eol2 = "\n";
   string lineColor2 = "Color: Blue" + eol2;
</syntaxhighlight>