Loading article…
構文ハイライトは、プログラミング、スクリプト、またはHTMLなどのマークアップ言語で使用されるテキストエディタの機能です。この機能は、用語のカテゴリに応じて、テキスト、特にソースコードを異なる色とフォントで表示します。 [ 1 ]この機能により、構造と構文エラーの両方が視覚的に区別されるため、プログラミング言語やマークアップ言語などの構造化言語での記述が容易になります。この機能は、プログラミング関連の多くのコンテキスト (プログラミングマニュアルなど) でも使用されており、カラフルな書籍やオンライン Web サイトの形式で、読者がコードスニペットを理解しやすくしています。ハイライトはテキスト自体の意味には影響しません。人間の読者を支援することのみを目的としています。
構文ハイライトは、テキストの意味の一部ではなく、意味を補強する役割を果たすため、二次的な表記法の一種です。一部のエディタでは、スペルチェックやコード折りたたみなど、言語とは独立した編集補助機能として、構文ハイライトを他の機能と統合しています。
watch='falseで区切り文字（カンマの後）が欠落した場合の影響を強調する構文ハイライトは、特に複数ページにわたるコードの可読性と文脈を向上させるための戦略の一つです。読者は、探している内容に応じて、コメントやコードの大部分を簡単に無視できます。構文ハイライトは、プログラマーがプログラムのエラーを見つけるのにも役立ちます。たとえば、ほとんどのエディタでは文字列リテラルを別の色でハイライト表示します。その結果、テキストの色が対照的になるため、区切り文字の欠落を簡単に見つけることができます。中括弧のマッチングも、多くの人気エディタに搭載されている重要な機能です。中括弧が省略されているかどうかを簡単に確認したり、カーソルがある中括弧のペアを別の色でハイライト表示することで、対応する中括弧を見つけたりすることができます。
PPIG会議で発表された研究では、構文ハイライトが短いプログラムの理解に与える影響を評価し、構文ハイライトがあるとプログラマがプログラムの意味を理解するのにかかる時間が大幅に短縮されることがわかった。[ 2 ]さらに、研究中にアイトラッカーから収集されたデータは、構文ハイライトによってプログラマがキーワードなどの標準的な構文要素に注意を払う必要が少なくなることを示唆している。
テキストエディタの中には、色付きのマークアップを印刷に適した形式や、ワープロソフトなどのテキストフォーマットソフトにインポートするのに適した形式でエクスポートできるものもあります。例えば、HTML、色付きのLaTeX、PostScript、RTF形式の構文ハイライトなどです。他のアプリケーションで使用できる構文ハイライトライブラリや「エンジン」はいくつかありますが、それ自体は完全なプログラムではありません。例えば、 PHP用の Generic Syntax Highlighter (GeSHi) 拡張機能などです。
複数の言語をサポートするエディタの場合、ユーザーは通常、C、LaTeX、HTMLなどのテキストの言語を指定できます。または、テキストエディタがファイル拡張子に基づいて、あるいはファイルの内容をスキャンすることによって、自動的に言語を認識することもできます。この自動言語検出には潜在的な問題があります。[ 3 ]例えば、ユーザーが次のような内容のドキュメントを編集したい場合を考えてみましょう。
このような場合、どの言語を使用すべきかが明確ではなく、文書がハイライトされないか、誤ってハイライトされる可能性があります。GuesslangやPLangRecなどのツールは、ソースコードからプログラミング言語を検出するように設計されています。[ 3 ]
構文ハイライト機能を備えたほとんどのエディタでは、構文のさまざまな要素（キーワード、コメント、制御フロー文、変数など）に異なる色やテキストスタイルを設定できます。プログラマは、コードの可読性を損なうことなく、できるだけ多くの有用な情報を表示するために、設定を細かくカスタマイズすることがよくあります。
構文装飾と呼ばれる機能として、一部のエディタでは、ソースコード内のポインタ演算子を->実際の矢印記号（→）に置き換えたり、ソースコードのコメント内の斜体、太字、下線などのテキスト装飾の手がかりを実際の斜体、太字、下線に変更するなど、特定の構文要素をより視覚的に魅力的な方法で表示します。
以下は、構文ハイライトされたC++コードの別の抜粋です。
import std ;using std :: array ; using std :: shared_ptr ;constexpr size_t MAX_WINDOW_COUNT = 100 ;// Window オブジェクトを作成し、windows に格納します。const int windowCount = 10 ; array < shared_ptr < Window > , MAX_WINDOW_COUNT > windows = {}; for ( size_t i = 0 ; i < windowCount ; ++ i ) { windows [ i ] = std :: make_shared < Window > (); }C++の例では、エディタはいくつかのC++キーワードを認識して強調表示します。 冒頭のコメントも、動作中のコードと区別するために特別な方法で強調表示されます。
構文強調表示の考え方は、構文指向エディタの考え方と大きく重なり合っています。そのようなコードエディタの最初のものの1つは、ウィルフレッド・ハンセンが1969年に開発したコードエディタ「Emily」です。[ 4 ] [ 5 ]これは高度な言語非依存のコード補完機能を提供し、構文強調表示を備えた現代のエディタとは異なり、構文的に誤ったプログラムを作成することを実際に不可能にしました。
1982年、Anita H. KlockとJan B. Chodakは、最初の構文強調表示システムの特許を出願しました[ 6 ]。これは、1983年に発売されたIntellivisionのEntertainment Computer System（ECS）周辺機器で使用されました[ 7 ]。BASICプログラムのさまざまな要素を強調表示し、初心者、特に子供たちがコードを書き始めるのを容易にするために実装されました[ 8 ] 。その後、1985年にオックスフォード英語辞典のコンピュータ化のためにVMオペレーティングシステム用に作成されたLive Parsing Editor（LEXX）は、色付き構文強調表示を使用した最初のものの1つでした。そのライブ解析機能により、テキスト、プログラム、データファイルなどに対して、ユーザーが提供したパーサーをエディタに追加することが可能になった。[ 9 ]マイクロコンピュータでは、MacPascal 1.0 (1985 年 10 月 10 日) は入力された Pascal 構文を認識し、モノクロのコンパクトな Macintosh上で構文を強調するためにフォントの変更 (キーワードの太字など) を使用し、コードの構造に合わせて自動的にインデントを行った。[ 10 ]
テキストエディタやコードフォーマットツールの中には、考えられるすべての言語に対してパーサーを実装するのではなく、パターンマッチングヒューリスティック（正規表現など）を使用して構文強調表示を行うものがあります。 [ 11 ]このため、テキストレンダリングシステムでは構文強調表示がやや不正確になったり、場合によっては動作が遅くなったりすることがあります。この問題を克服するためにテキストエディタが採用している解決策は、必ずしもファイル全体を解析するのではなく、表示領域のみを解析し、場合によってはテキストを限られた行数まで遡って「同期」することです。
一方、エディタはコードの作成中に、コードが不完全または誤っている状態でも表示することが多く、厳密なパーサー（コンパイラで使用されるようなもの）では、ほとんどの場合、コードの解析に失敗します。
現代の言語固有のIDE（テキストエディタとは対照的に）の中には、完全な言語解析を実行するものがあり、その結果、コードの理解が非常に正確になります。構文ハイライトの拡張は、2009年にDavid Nolden [ 12 ]によってオープンソースのC++ IDEであるKDevelop向けに「セマンティックハイライト」と呼ばれました。たとえば、セマンティックハイライトでは、ローカル変数に固有の異なる色を付けて、コードの理解度を向上させることができます。2014年には、Evan Brooks [ 13 ]のブログ記事により、ローカル変数に色を付けるというアイデアがさらに広まり、その後、Visual Studio [ 14 ]、Xcode [ 15 ]などの他の人気IDEにもこのアイデアが移されました。
ユーザーインターフェースにおける色は、ユーザーに何らかの色覚異常がある場合、あまり役に立たなくなる。