ハクソク

世界を動かす技術を、日本語で。

構文ハイライトの誤り

222日前原文(tonsky.me)

概要

  • シンタックスハイライト はコード可読性向上のための重要なツール
  • 色の使いすぎは逆効果で、 最小限の色数 が理想
  • 何を強調し、何を目立たせないかの 選択が重要
  • コメントや定数など、 目立たせるべき要素 の明確化
  • Alabaster という実践的配色テーマの提案

シンタックスハイライトの正しい使い方

  • シンタックスハイライト はコードの読みやすさ・探索効率向上のためのツール
  • 適切に使えば、 大規模ファイル内での位置把握や特定要素の素早い発見 が可能
  • しかし、 全てを強調 すると、逆に何も目立たなくなる現象（クリスマスライトダイアリア現象）が発生
  • 全要素を明るくする配色 は、重要な情報の識別を困難にする
  • 強調箇所の取捨選択 が不可欠

色数の最小化と実用性

  • 理想的な配色テーマは、 記憶できる色数に制限 すること
  • 例：Alabasterテーマは 4色のみ を使用
    • グリーン：文字列
    • パープル：定数
    • イエロー：コメント
    • ライトブルー：トップレベル定義
  • 色と要素の対応を即座に思い出せる範囲に限定
  • 色の入れ替えが即座に気づけるレベルが理想

強調すべき要素と避けるべき要素

  • 強調すべきは 数が少なく、意味的な区切りや参照点となる要素
    • 定数（数値・文字列）
    • トップレベル定義
  • 変数や関数呼び出しは 頻度が高すぎて強調の意味が薄い
  • 言語キーワード（class, function, ifなど） は強調不要
    • これらは検索対象になることが少なく、目立たせる意義が薄い
  • コメント は本来重要な情報源であり、 目立つ色で強調 すべき
  • コメントには 説明 と 無効化コード の2種類があり、可能なら区別

配色テーマ設計の原則

  • 明度差 を活用し、色の違いを明確に
  • 必要以上に 色数を増やさない
  • 背景色の活用 で、白背景でも色の識別性を向上
  • 太字やイタリック は色の代わりにはならないため、基本的に非推奨
  • 科学的な均整配色（例：全色同明度・均等色相配置）は 実用性が低い

ダークテーマとライトテーマの違い

  • ダークテーマ は色のバリエーションが豊富で、見た目も鮮やか
  • ライトテーマ は使える色が限られ、色の識別性が低下しやすい
  • 背景色の工夫 でライトテーマでも色の判別性を高めるテクニックが有効

実践例：Alabasterテーマの設計

  • 言語キーワード・変数使用・関数呼び出しの強調を排除
  • トップレベル定義や定数、コメントを 明確な色 で強調
  • 記憶しやすく、目に優しい配色 を実現
  • 複数エディター（VS Code, JetBrains, Sublime Text等）で利用可能

まとめと提案

  • 色数の制限と強調箇所の取捨選択 がシンタックスハイライトの本質
  • Alabasterテーマはその実践例であり、他テーマでも応用可能
  • 既存のカラフルなテーマから抜け出し、 意図的で合理的な配色設計 を推奨
  • 配色設計の見直しが、コード可読性・作業効率を大きく向上

Hackerたちの意見

脳って、すごく微妙なことをキャッチするんだよね。特に、パターン認識の力を活かせるときは。デフォルトでごちゃごちゃしない方がいいって意見には賛成だけど、さっきも変な構文ハイライトのおかげで、変数のタイプに基づいてデバッグが30秒も短縮できたばかりなんだ。すぐに間違いだって分かったし、すぐに直せた。しかも、俺は色盲なんだよね。著者が言うほど、もっと色を上手く使えると思うよ。

黒い背景に強烈な黄色のブログを持ってる人から色のアドバイスを受けるのは難しいよね。冗談じゃなくて。著者は様々な構文ハイライトの比較を見せようとしてるけど、明るい黄色の背景と黒いコードサンプルの背景の大きなコントラストに圧倒されちゃって、違いが全然分からないんだよ。

└

俺はこれでいいと思うよ。ここで見たダークグレーに紫よりは全然マシだし。

└

俺はこれでいいと思うし、確かにすごく認識しやすいよ。

└

うわ、目にきつかったな。。

└

アドバイスには同意だけど、うん、このウェブサイトは目が疲れた。

└

黄色？確認しに戻らなきゃ - Darkreaderを試してみて :)

└

同意、彼のサイトの他のページもいくつかチェックして、あの特定の投稿だけの皮肉じゃないか確認したよ。

└

黄色を見た瞬間、読むのをやめた。色が好きなんだ。虹色のデリミタも好き。今は変えないつもり。ミニマリスティックなハイライトには満足してる。もっとミニマルなハイライトでVisual Studioを使ってたこともあるし、それも悪くなかった。好みの問題だと思うし、あまり気にする価値はないと思う。気になるなら、気にならなくなるまで変えればいい。あんまり考えないようにしてる。

└

わかる。これ、今年見た中で一番ダサいページだわ。明るい背景に、ヘッダーにはダサいサインがいっぱい、テキストは何か意味不明なことを言ってるし。

ここで簡単なテストをしてみて。ここで関数の定義を見つけてみて。 最初の例で著者が視聴者に関数の定義を見つけるように頼んだとき、彼が間違ってると思ったカラフルな構文ハイライトのおかげで、俺はそれをもっと早く見つけられたんだ。コードの異なる要素を認識するのは、単に色だけじゃなくて、言語の実際の構文やコードブロックの形状にも関わってる。これは好みの問題だし、俺のプログラミングの何十年かの経験の中で、同僚や多くのチームが色々なファンシーなテーマを試してみた結果、結局「つまらない」テーマ、例えばマテリアルテーマに戻ってくるのを見てきた。著者は、リテラル（彼が定数と呼んでいるもの）や、同じ明るさの要求を拒否すること、コメントを強調することについては良いアイデアを持ってると思う。彼の完璧な構文ハイライトをアイデアの市場に持ち込むのは大歓迎だよ。もし彼のアイデアが勝てば、その採用が証明するはず。

└

同じ経験をしたよ。虹色のハイライトの方がずっと見つけやすかった（モノクロのハイライトの時にどこを探せばいいかは知ってたけど！）。著者は後で色クラス定義について尋ねてるけど、シンタックスハイライトが人間にどう役立つかを根本的に間違えてると思う。お気に入りのハイライトでは色が何か全然わからないけど、脳はすごいパターン認識をして、意識せずにコードを理解する手助けをしてくれるんだ。だから、彼の問題提起は成り立たないけど、実際に問題がないわけじゃない。

└

これって、Veritasiumの動画だったかも？テストから始まるYouTubeの動画があって、残りは一つの結果に基づいて予測されてたけど、私やほとんどの観客は違う結果だったんだ。最悪の場合は普通にコードを読むだけで、最高の場合は特定の色にジャンプできるよ。

└

同意する。あの例で苦労することになるとは思わなかった。詳細なシンタックスハイライトでリターンのスペルミスが見えにくくなるのは確かだけど、コーディングしてるときは主に自分が書いてるトークンに集中してるから、シンタックスハイライトが自分のトークンをキーワードとして間違って表示してたり、間違ったタイプの識別子として表示してたりしたら、すぐに気づくよ。色が何か知らなくても、見た目が変だと感じる。虹色のハイライトは論理的には悪いアイデアに思えるけど、証明するのが難しいこともあって、実際には多くの人がそれが良いと感じると思う。特にtree-sitterやLSPがより詳細なシンタックスハイライトを提供してるから、「あ、これ間違った識別子の色だよね？」っていう恩恵を感じるし、ハイライトが壊れるエッジケースに遭遇するとすぐに気づくようになる。

└

OPは何か色盲のようなものがあって、彼の例がもっと理解できるのかな？私は彼のアイデアよりも現状の例の方がずっとわかりやすい。彼が黒いテキストに黄色い背景を使ってるのが、読むのがひどくて、私の理論を助けてる。

└

ここまで来ると、「画面に色の『動物園』があってもいいじゃん…コードの形や色の相対的な位置に基づいてパターンをすぐに見つけられるなら」という方向にもっと進めるんじゃないかと思う。多くのゲーム、特に複数の直交的な「レベル」を追跡する必要があるガチャゲームなんかでは、膨大なデータをキャラクターや装備アイテムのポートレートに圧縮しているよね。上にティック、横にドット、色付きのフレームとか…これらは、カスタムソートを設定しなくても、群衆の中から物を見つけやすくするためなんだ。でも、IDEは「レンダリングの最適化」や「ANSIエスケープコードとの一貫性」みたいなくだらない理由を挙げて、各キャラクターに前景色を一色、背景色を一色、そして多分ちょっとした波線の下線しか許可してない。なんでそこで止まるの？任意のトークンにオーバーレイやデコレーションを追加する自由をちょうだい。特定の条件を満たすトークンの右上にちょっとした色付きのドットや絵文字を置けるようなスタイル要素をください…例えば、ユーティリティ関数とか、画面の右上に開いているファイルからの参照とか。私たちを虹の中で泳がせて、目の前をキラキラさせながら。私たちは強い泳ぎ手なんだから。

└

最初の例で、著者が視聴者に関数の定義を見つけるように頼んだ時、彼が間違っていると考えたカラフルなシンタックスハイライトを使った方が、私は早く見つけられたのが面白い。 同じく。これで記事の魅力が半減した感じ。彼のテーマでは色の制限が最終的に私を困らせると思ってた。数字と文字列が同じ色になるのは最悪だよ。私のテーマでは色が違うから、数字が引用符で囲まれているせいで文字列として誤って認識されるミスに気づいたことがある。

└

私も同じ、目が関数のキーワードからキーワードへと飛び跳ねちゃった。

俺は著者とは全然違う脳の形をしてるみたい。色の処理は無意識的で、「色のオーバーロード」なんて全く感じないんだ。脳がずっと前にハードウェアで加速してるから、追加の色を追ったり違いを見つけたりする意識的な負担はない。唯一それを感じるのは、ペアリングのときに他の人のカラースキームを見るときだけだ。ここから先はちょっと分からなくなった。> ここで簡単なテストをしてみて。ここで関数の定義を見つけてみて。俺はもっと色があった方がすぐに見つけられたし、色が少ないと苦労した。後の例でも同じだったよ。

└

なんか、伝統的な意味でのハイライトを好む人と、もっと一般的な色分けされたコードを好む人がいるみたいだね。

└

色の処理は無意識的なもので、私は「色のオーバーロード」を感じない。

同じく。昔の友達と作ったWhatsAppグループでこれに気づいたんだ。メンバーは8人くらいで、それぞれ名前に特定の色が付いていて、パッと見で誰が話してるか分かるんだよね。ある時、誰かが電話番号を変えて、グループを一度抜けて再入場したんだけど、そのせいでみんなの色が変わっちゃった。数週間は地獄だったよ。Aさんはピンク、Bさんは黄色っていうふうに慣れてたから、色が変わったことでAに返信するつもりがBに返信しちゃったりして、めっちゃ混乱した。

実際、カラフルな例の方が扱いやすいと感じたけど、真ん中くらいのものが一番好みかも。多分、普段Sublimeを使ってるから、そのせいかもしれない。著者は特定のハイライトカラーを特定の意味に結びつけることで価値を得てるみたいだけど、俺はむしろ異なるハイライトグループから価値を得てると思う。その観点から見ると、エディタを開いて文字列が緑でも気にしない。文字列が変数名とは違うグループに属してるかどうかが大事なんだ。俺が「複雑」なスキームで問題に感じたのは、紫の再利用だった。分岐、ループ、インポート、関数、this、new — これらは全然関係ないから、紫にしても意味がないんだ（俺や著者にとっても）。どちらの方法が間違ってるとは思わないけど、違う人にはそう感じるかもね。

俺は低色数の構文ハイライトのバリエーションを試したことがある（構文ハイライトなしも試したことがある！）。ほとんどのカラースキームが色が多すぎてノイズになってるのには同意するけど、超低色数を目指すと可読性が損なわれると思う。例えば、キーワードは特にハイライトするのがすごく役立つ。この記事では「return」のスペルミスが簡単にスキャンできる色の変化を生まなかったと文句を言ってるけど（紫から赤に変わっただけで、特別な色に見える）、その後キーワードを全くハイライトしないことを提案してるから、「return」のスペルミスを視覚的にすぐに見つけるのが不可能になるんだ！提案されたカラースキームでは、「return」と「retunr」は同じ色、つまり白になる。一般的に言って、構文ハイライトの視覚的ノイズは色が多すぎることから来てると思う。例えば、「class」キーワードを「const」キーワードとは違う色にする必要はないし、多くの構文ハイライトテーマがまさにそれをやってる。だけど、タイプミスをすぐに視覚的に確認できるのは便利なんだ。キーワードを書くつもりだったのに、普通のテキストのように色がついてたら、間違えたって分かるからね。同様に、コードをレビューする時に、どこかにタイプミスがあるかすぐに見分けられるのは便利だ。俺はNeovim用にかなりカスタムした構文ハイライトテーマを持ってる。いくつかのカテゴリーが異なる色でハイライトされてる：

  • キーワード
  • 関数呼び出しとメソッド呼び出し（同じようにハイライト）
  • プロパティアクセス（単にプロパティにアクセスしてるだけの時に間違いをハイライトするため — メソッド呼び出しとは違う色）
  • 数字やブール値などの非文字列の組み込みプリミティブ型
  • 文字列
  • コメント
  • 型 最終的に、構文ハイライトはミスを見つけるためのツールだと思う。色を使いすぎると、すべてがユニークな色になるから、何かが間違ったユニークな色であることを見分けるのが難しくなるのは確か。でも、比較的控えめなパレットを使えば、かなりの価値が得られると思うし、この記事は色の使用を減らしすぎてると思う。
└

シンタックスハイライトがなかった頃にコーディングを学んだんだ。80x25の端末では、顔文字一つ、フォント一つ、色一つしかなかった。緑か、琥珀色か、白っぽい色だったけど、それだけだった。そこにあるべきでないもの以外は、最小限のシンタックスハイライトがいいな。存在しないキーワードはハイライトされるべきだし、閉じてない文字列やバランスの取れてない括弧もね。コメントは別の色にして、実際のコードと簡単に分けられるようにするのが好きだけど、それ以外は最小限派だよ。

└

あなたの考え、私と似てるね。色を使いすぎると、視覚的にうるさくなるだけだよね。でも、ここまで色を減らしちゃうと、役に立つ色もなくなっちゃう。デフォルトのVisual Studioのカラースキームは、いいバランスだと思ってる。特に、そのテーマの緑のコメント色が好き。目立ちすぎず、でも背景に溶け込むこともない（多くのテーマが本当にそうなっちゃうのがウザいけど）。もちろん、作者がそのミニマルな色を好むなら、間違ってるとは言わないけど、客観的に良いとするのには同意できないな。

└

でも、キーワードを全く強調しない提案をしているから、「return」のスペルミスを視覚的にすぐに見つけるのは不可能だよね！ うん、私は基本的にその逆がいい。キーワードが強調されるべきだと思ってる。あと、派手すぎるテーマが苦手で、ライトモードが好きなんだ（ダークモードは目に優しくないし、逆に焦点を合わせるのが大変で、ぼやけて見えることが多い）。でも、作者のアルバスターテーマは間違ったものを強調してて、一貫性がないんだよね。public async Task SomeMethodName(Type param, Type param) では、Task、SomeMethodName、データ型とパラメータ名の両方が強調されてる。もし強調がキーワードのためじゃないなら、なんでTaskやデータ型が強調されてるの？同様に、var result = await SomeMethodName(param, param); ではresultとSomeMethodNameが強調されてて、私は基本的にその逆がいい。PLのキーワードだけが強調されて、他は何もいらないんだ。

└

「シンタックスハイライトなしでも試してみたことあるよ！最初はWindowsのNotepadで始めて、ほぼ10年それを使ってたけど、Linuxに切り替えてvimの使い方を学んだ。やっぱり、あの頃に戻るよりは虹色のハイライトの方が好きだね。」

時々、ひどくなりすぎてベースのテキストカラーが見えなくなることがあるよね。全部ハイライトされちゃってる。ここでのベーステキストカラーって何？この前提がよくわからないんだけど。「ベーステキストカラー」って何で、見ることが重要なの？すべてに特定の色が割り当てられてるけど、なんでその中の一つの色が他より重要だと考えられるのかがわからない。 > ちょっとテストしてみて。ここで関数定義を探してみて: [...] わかる？いや、わからない。文脈から、著者が二つ目の例の方が見つけやすいと言ってるのはわかるけど、私は一つ目の方が見つけやすかった。どちらも私にとってはかなりひどいシンタックスハイライトのスキームだと思うけど。

└

私もこれがよくわからない。私のコードには「ベーステキスト」なんてないし、すべてが何かになってる！HTMLみたいなものではそうかもしれないけど、ほとんどのプログラミング言語ではそうじゃないと思う。

いや、同じ識別子のすべての出現に同じ色を使うのが一番だよ。だから、最後の例では「audio」のすべてのインスタンスは同じ色で、「filename」は別の色にすべきだね。元のアイデアはここから: https://medium.com/@evnbr/coding-in-color-3a6db2743a1e Emacsの実装例: https://github.com/ankurdave/color-identifiers-mode それでも、ニキを尊敬してるよ。

└

しばらくそれを試したけど、色が多すぎると感じた。私は、この記事で示されている二つの悪い極端の中間にある、センスの良い色が好み。クリックしたら、その識別子のすべてのインスタンスがハイライトされるのもいいね。

どうか、言語のキーワードをハイライトしないでください。著者の言ってることにはほとんど同意だけど、これは違う。強く反対だ。私の見解では、キーワードはハイライトすべき最も重要なものだと思う。他のものはなくても大丈夫。キーワードは、ほとんどの言語でプログラムの構造を描いてる。例えば、トップレベルの定義の場合、私が目を引かれるのはキーワード。長い定義の中をスキャンする時の予測可能なアンカーなんだ。識別子はそうじゃない：長いのもあれば（とても）短いのもある。プログラムの制御フローを理解するにはどうするか？キーワードを見るんだ。条件を読みたいなら、条件を見つけなきゃ。でも、すべての条件は違って見える。どうやってそれを見分けるのが確実なの？必ず前にある予測可能な「if」だよ。私の目はパーサーなんだ。トークンを認識する必要がある。でも、いくつかのトークンは混同しやすい：キーワードは識別子にそっくりなんだよね。

└

これには同意だね。特に、同じ記事で紹介されているreturnキーワード引数については。味に関する正しさの主張は、皮肉なことに簡単に反証可能だと思う。とはいえ、僕は著者の言っていることのほとんどに個人的には賛同しているんだけどね（自分の好みとしては）。コメントの視覚的な重要性を高めることには、ぜひ挑戦してみたいな。

└

ちょっと同意するけど、壊れてなければたまにはキーワードをオフにしてもいいと思う。逆再生の動画で「retunr」を強調してみて。

└

でも、キーワードに特別な色は必要ないと思うよ。基本の色を使って、明るくしたり太字にしたりすれば十分だよね。

コンピュータプログラムをどう表示するのがベストかについてのおすすめの本はこれだよ：「Human Factors and Typography for More Readable Programs」

└

アーカイブはここにあるよ：https://archive.org/details/humanfactorstypo0000baec