What does Visual Studio mean by normalize inconsistent line endings?

Visual Studio occasionally tells me:

> The line endings in the following files are not consistent. Do you want to normalize the line endings?

It then gives me a drop down with different standards or something, such as Windows, Mac, Unix, and a couple of Unicode ones.

What does this mean and what is going to happen if I click Yes?

What that usually means is that you have lines ending with something other than a carriage return/line feed pair. It often happens when you copy and paste from a web page into the code editor.

Normalizing the line endings is just making sure that all of the line ending characters are consistent. It prevents one line from ending in \r\n and another ending with \r or \n; the first is the Windows line end pair, while the others are typically used for Mac or Linux files.

Since you're developing in Visual Studio, you'll obviously want to choose "Windows" from the drop down. :-)

Some lines end with \n.

Some other lines end with \r\n.

Visual Studio suggests you to make all lines end the same.

If you are using Visual Studio 2012:

Go to menu File → Advanced Save Options → select Line endings type as Windows (CR LF).

To turn the option ON/OFF, follow the steps below from menu bar:

Tools → Options → Environment → Documents → Check for consistent line endings on load

The file you are editing has been edited with some other editor that does not use the same line endings, resulting in a file with mixed line endings.

The ASCII characters in use for line endings are:

CR, Carriage Return
LF, Line Feed

Windows = CRLF
Mac OS 9 or earlier = CR
Unix = LF

The Wikipedia newline article might help you out. Here is an excerpt:

> The different newline conventions often cause text files that have been transferred between > systems of different types to be displayed incorrectly. For example, files originating on > Unix or Apple Macintosh systems may appear as a single long line on some programs running on > Microsoft Windows. Conversely, when viewing a file originating from a Windows computer on a > Unix system, the extra CR may be displayed as ^M or at the end of each line or as a > second line break.

It means that, for example, some of your lines of text with a <Carriage Return><Linefeed> (the Windows standard), and some end with just a <Linefeed> (the Unix standard).

If you click 'yes' these the end-of-lines in your source file will be converted to have all the same format.

This won't make any difference to the compiler (because end-of-lines count as mere whitespace), but it might make some difference to other tools (e.g. the 'diff' on your version control system).

When you copy paste something from web, you might get the inconsistent line endings.
In order to fix this, you can use Visual studio extension "Line Endings Unifier" which can make line ending consistent automatically while saving file.

It's not just Visual Studio... It'd be any tools that read the files, compilers, linkers, etc. that would have to be able to handle it.

In general (for software development) we accept the multiplatform line ending issue, but let the version control software deal with it.

Line endings also called newline, end of line (EOL) or line break is a control character or sequence of control characters in a character encoding specification (e.g. ASCII or EBCDIC) that is used to signify the end of a line of text and the start of a new one. Some text editors set/implement this special character when you press the Enter key.

The Carriage Return, Line Feed characters are ASCII representations for the end of a line (EOL). They will end the current line of a string, and start a new one.

However, at the operating system level, they are treated differently:

• The Carriage Return ("CR") character (ASCII 13\0x0D, \r): Moves the cursor to the beginning of the line without advancing to the next line. This character is used as the new line character in Commodore and Early Macintosh operating systems (Mac OS 9 and earlier).

• The Line Feed ("LF") character (ASCII 10\0x0A, \n): Moves the cursor down to the next line without returning to the beginning of the line. This character is used as the new line character in Unix based systems (Linux, macOS X, Android, etc).

• The Carriage Return Line Feed ("CRLF") character (0x0D0A, \r\n): This is actually two ASCII characters and is a combination of the CR and LF characters. It moves the cursor both down to the next line and to the beginning of that line. This character is used as the new line character in most other non-Unix operating systems, including Microsoft Windows and Symbian OS.

Normalizing inconsistent line endings in Visual Studio means selecting one character type to be used for all your files. It could be:

• The Carriage Return Line Feed ("CRLF") character
• The Line Feed ("LF") character
• The Carriage Return ("CR") character

However, you can set this in a better way using .gitattributes file in your root directory to avoid conflicts when you move your files from one Operating system to the other.

Simply create a new file called .gitattributes in the root directory of your application:

touch .gitattributes

And add the following in it:

# Enforce Unix newlines
* text=auto eol=lf

This enforces the Unix line feed line ending character.

Note: If this is an already existing project, simply run this command to update the files for the application using the newly defined line ending as specified in the .gitattributes.

git rm --cached -r .
git reset --hard

That's all.

I hope this helps

There'a an add-in for Visual Studio 2008 that converts the end of line format when a file is saved. You can download it here: http://grebulon.com/software/stripem.php

I had this problem in VS 2019 and solved it by setting the LineBreak configuration for Windows, before it was set for Unix.

Tools > Options > Format on Save > Settings > LineBreak: Windows