Syntax highlighting is a form of secondary notation, since the highlights are not part of the text meaning, but serve to reinforce it. Some editors also integrate syntax highlighting with other features, such as spell checking or code folding, as aids to editing which are external to the language.

Contents

Highlighting the effect of missing delimiter (after watch='false) in JavaScript

Syntax highlighting is one strategy to improve the readability and context of the text; especially for code that spans several pages. The reader can easily ignore large sections of comments or code, depending on what they are looking for. Syntax highlighting also helps programmers find errors in their program. For example, most editors highlight string literals in a different color. Consequently, spotting a missing delimiter is much easier because of the contrasting color of the text. Brace matching is another important feature with many popular editors. This makes it simple to see if a brace has been left out or locate the match of the brace the cursor is on by highlighting the pair in a different color.

A study published in the conference PPIG evaluated the effects of syntax highlighting on the comprehension of short programs, finding that the presence of syntax highlighting significantly reduces the time taken for a programmer to internalise the semantics of a program.[2] Additionally, data gathered from an eye-tracker during the study suggested that syntax highlighting enables programmers to pay less attention to standard syntactic components such as keywords.

Some text editors can also export the coloured markup in a format that is suitable for printing or for importing into word-processing and other kinds of text-formatting software; for instance as a HTML, colorized LaTeX, PostScript or RTF version of its syntax highlighting. There are several syntax highlighting libraries or "engines" that can be used in other applications, but are not complete programs in themselves, for example the Generic Syntax Highlighter (GeSHi) extension for PHP.

For editors that support more than one language, the user can usually specify the language of the text, such as C, LaTeX, HTML, or the text editor can automatically recognize it based on the file extension or by scanning contents of the file. This automatic language detection presents potential problems. For example, a user may want to edit a document containing:

more than one language (for example when editing an HTML file that contains embedded JavaScript code),

a language that is not recognized (for example when editing source code for an obscure or relatively new programming language),

a language that differs from the file type (for example when editing source code in an extension-less file in an editor that uses file extensions to detect the language).

In these cases, it is not clear what language to use, and a document may not be highlighted or be highlighted incorrectly.

Most editors with syntax highlighting allow different colors and text styles to be given to dozens of different lexical sub-elements of syntax. These include keywords, comments, control-flow statements, variables, and other elements. Programmers often heavily customize their settings in an attempt to show as much useful information as possible without making the code difficult to read.

The ideas of syntax highlighting overlap significantly with those of syntax-directed editors. One of the first such editor for code was Wilfred Hansen's 1969 code editor, Emily.[3][4] It provided advanced language-independent code completion facilities, and unlike modern editors with syntax highlighting, actually made it impossible to create syntactically incorrect programs.

In 1985 Ben Shneiderman suggested "color coding of text strings to suggest meaning".[5] The Live Parsing Editor (LEXX) written for the VM operating system for the computerization of the Oxford English Dictionary in 1985 was one of the first to use color syntax highlighting. Its live parsing capability allowed user-supplied parsers to be added to the editor, for text, programs, data file, etc.[6] On microcomputers, MacPascal 1.0 (October 10, 1985) recognized Pascal syntax as it was typed and used font changes (e.g., bold for keywords) to highlight syntax on the monochrome compact Macintosh and automatically indented code to match its structure.[7]

Some text editors and code formatting tools perform syntax highlighting using pattern matchingheuristics (e.g. Regular expressions) rather than implementing a parser for each possible language.[8] This can result in a text rendering system displaying somewhat inaccurate syntax highlighting and in some cases performing slowly. A solution used by text editors to overcome this problem is not always parsing the whole file but rather just the visible area, sometimes scanning backwards in the text up to a limited number of lines for "syncing".

On the other hand, the editor often displays code during its creating, while it is incomplete or incorrect, and the strict parsers (like ones used in compiles) would fail to parse the code most of the time.

Some modern, language-specific IDEs (in contrast to text editors) perform full language parsing which results in very accurate understanding of code. An extension of syntax highlighting was called "semantic highlighting" in 2009 by David Nolden [9] for the open-source C++ IDE KDevelop. For example, semantic highlighting may give local variables unique distinct colors to improve the comprehensibility of code. In 2014 the idea of colored local variables was further popularized due to a blog post by Evan Brooks,[10] and after that, the idea was transferred to other popular IDEs like Visual Studio,[11]Xcode,[12] and others.