様々な命名規則の起源を調べてベストプラクティスを考えてみた

RESTful な URI 設計ではケバブケースだとか、プログラム言語ごとにスネークケースが使われたりキャメルケースが使われたりとか、命名規則には色んなモノがある。それらがどういう経緯で登場したのかを調べることで、プロジェクトや使用言語に囚われない普遍的な命名規則を体系的に構築できないか、と考えている。

今回は調べた情報を雑多にまとめておく。

目次

スネークケースの起源

snake_case というように、アンダースコアを使って文字列を区切る記法。このスネークケースはどのようにして生まれたのか。

前提として、元々のプログラミング言語はコードをパースする際に、スペース (空白文字) や改行を区切り文字記号として使用してきた。いわゆるトークン・字句解析の区切りというワケだ。今でもほとんどの言語がそうだが、

const hoge = 'const value';

↑ 例えばこんなコードに対して、コードを解釈するパーサを実装する時に

という条件を組み込もうとしたら、厳密には「const という文字列の前後にスペース文字等の区切り文字が登場すること」という条件になる。その他にも、「文字列はクォートで囲む」「イコール記号 = で代入を表す」といったことを区別することで、文字列リテラルの中に const という文字が出てきても、パーサは定数宣言だとは勘違いせずに文字列として解釈できるワケである。

consthoge  =  'const value';

↑ このように、consthoge とスペース区切りがないコードは構文エラーになる。

con st ho ge = 'const value';

↑ このように con st とスペースが開いているのも、パーサは定数宣言として解釈ができなくなる。

スペースが構文・予約語 (トークン) を判別するための区切り文字として機能する、というパーサの都合を考えれば、ココまでは理解できるだろう。

そんなワケで、「変数名」や「関数名」の部分を無闇にスペースで区切ることはパーサの都合上できない。しかし、変数名や関数名を示す際に、一般的な英文として単語と単語を区切れないと、finduserbyid こんな感じで可読性が悪い。そこで、プログラミング言語の発展途上において、「スペース以外で単語を区切る別の記号文字」を模索していたようだ。

歴史的には、Lisp (1958年) や Cobol (1959年) といった言語では、ハイフン - 記号を使って単語を区切れるような言語仕様になっていたそうだ。

しかし一方で、ハイフンという記号は一般的に「マイナス」、つまり減算を表す記号としても使われる。そうするとコードのパーサの実装としては、「変数名を区切るためのハイフン記号」なのか、「減算を示すマイナス記号」なのか、という区別が必要になるワケだが、この判定処理は凄く難しい。JavaScript で例示してみよう。

// JavaScript の場合、以下の変数名は構文エラーになる
const hoge-fuga = 100 - 10;

// なぜかというと、以下のような「減算処理」と区別が極めて難しいから
const hoge = 100;
const fuga = 10;
const result = hoge-fuga;

最初に書いた const hoge-fuga は、ハイフン記号で単語を区切ったつもりの「変数名」。しかしこの書き方は、「変数 hoge と変数 fuga の値を引き算する」という意味になるコード hoge - fuga との区別が極めて付けにくいのだ (パーサがこの2つを間違いなく区別するには相当複雑な実装になり、1950年代のコンピュータのスペックから考えればそうした実装コストをかけられなかったことだろう)。

当時登場した言語の中でも、Fortran (1955年) や Algol (1958年) など数学指向の言語は、既に減算記号にハイフンを使う仕様だったので、変数名などにハイフンを使うのは適さなかったのだ。

そこで、1960年代後半頃からは、単語を区切るのにハイフンの代わりにアンダースコアを使おう、という流れが出てきた。そうして C 言語 (1972年) では関数名や変数名の中でアンダースコアを使い、単語を区切って可読性を高められるようになった。

C 言語は後に登場する Perl や Python など様々な言語に影響を与えており、プログラミング言語のコンパイラ部分は現在でも C や C++ で実装されていたりするので、その流れで現在でもスネークケースを使う言語が多いワケである。

パンチカード時代は大文字だけ (ケースインセンシティブ)

C 言語のようなヒューマンリーダブルなプログラミング言語が登場する以前は、プログラミングというとパンチカードというモノを使って、機械に命令を渡していた。

当時はマシンスペックの問題などもあり、マシンが理解できるのはアルファベット大文字と数値、一部の記号のみであり、その区切りとして空白 = スペースを利用してきた、という経緯もあったりする。つまり「大文字と小文字の区別がない、ケースインセンシティブ」な環境がデフォルトだったワケである。大文字と小文字を区別しようとすると、アルファベットだけで大文字と小文字という2倍の領域を必要とするため、大文字か小文字のみに統一していたというワケだ。

そう思うと、Windows コマンドプロンプトやその前身である MS-DOS (1981年)、1974年頃に登場した SQL などの構文が、基本的には大文字小文字を区別せず、ほとんどが大文字に統一して書かれていたというのは納得がいくことだろう。現代では「全部小文字」で書くスタイルも増えている気がするが、自分はその昔、学校で BASIC で簡単なプログラムを書かされた時に、全部大文字でコーディングしたなぁという記憶がある。

Xerox Alto が生んだキャメルケースとハンガリー記法

1970年代、Xerox Alto というコンピュータが登場した。このコンピュータのキーボードにはアンダースコアキーがなかったそうだ。

開発には Xerox 社が設立した PARC (パロアルト研究所) が関わっており、Alto 上で動くソフトウェア、およびプログラミング言語についても PARC が開発していた。その中で、1974年に Mesa というプログラミング言語が開発されたワケだが、

ということになり、検討の結果、各単語の1文字目だけを大文字にすることで単語を区切る、キャメルケースが誕生したそうだ。

Mesa 言語は型付けも持つようになり、それを変数名で示すハンガリー記法というモノも生み出された。この当時はマシンスペックの問題もあり、変数名の長さなどにも制限があったため、専用の略語を組み合わせて表現するための命名規則として、ハンガリー記法というモノが形成されていった。ちなみにハンガリー記法はマイクロソフトでもしばらく採用されており、Windows API などにはその名残りがある (.NET Framework 以降は採用されていない)。

スネークケースについては、アンダースコアの下線を見落としやすくスペース区切りと見間違えることも多かったようで、そうした理由からもキャメルケースが採用されるプログラミング言語が登場していたようだ (Smalltalk など)。

Sun・Java によるキャメルケースの浸透

1995年頃に Sun Microsystems が発表した Java 言語は、C や C++ に影響を受けた構文が特徴だが、その中で Sun が提唱した命名規則によって、キャメルケースがさらに一般に浸透していったといわれている。Java は強い静的型付け言語であり、パッケージ名、クラス名、メソッド名、変数名などを見た目で区別しやすくするために、おおよそ次のような命名規則を採用していた。

やはりハイフン記号を使うケバブケースについては、減算記号との混同を避けるために使われてこなかったが、キャメルケースをベースに、大文字と小文字を区別するケースセンシティブな言語仕様を利用し、よりヒューマンリーダブルな命名規則を編み出したワケである。

C 言語時代のコードが由来だと思うが、古めの Java コードが書かれた文献で、プライベートな変数に対して、先頭をアンダースコアで始める _myVar といった書き方を見たことがある。他にも final であることを変数名で示すような使われ方をしているのも見かけたことがあり、IDE がそれほど進歩していなかった1990年代の、できるだけ目視で見間違えないようにするという工夫の跡が見られる。

実際のところ、Java では変数をスネークケースで書いても言語仕様上は問題ないし、C 言語からの流入者などが Java コードの中でスネークケースを用いている例も見てきた。これらはあくまで人が目視した時に区別がしやすい、というところが狙いであり、IDE による自動補完や自動チェックが発展してきた現在は、定数だからといって必ずしもアッパースネークケースを使わない場合が出てきていると感じる (JavaScript なんかは const の登場でアッパースネークケースが減ったと思う)。

ファイル名も「ハイフン」「スペース」区切りは忌避されてきた

UNIX や Linux 環境で動くシェル (Bash など) についても、コレまで紹介してきた紹介してきたプログラミング言語と同様に、スペースを区切り文字として認識する。さらにシェルスクリプトの場合、コマンドラインオプションを示すのにハイフン記号を使うこともあり、通常作成するファイル名に対しては、長らくスペース文字やハイフン文字を使うことは忌避されてきた。

# コマンドはスペースで区切り、オプションはハイフンから始めるのが常
# だからスペースやハイフンを含むファイルを扱う際はクォートで囲まないとバグを生み、扱いが面倒臭くなる
$ mv -i './my - example note.txt' ../

# 以下のコマンドが意図しない挙動になるのは想像付くはず
$ mv -i ./my - example note.txt ../

この問題は2022年現在の Linux 環境 (Bash など) でも同じく残っているので、シェルスクリプトで操作するファイルに関しては、ファイル名にスペース文字を使わないようにする傾向が強い。

Windows についても、古の MS-DOS や Windows 3.x 系までは、ファイル名は8文字まで、拡張子は3文字まで、という制約があった。この制約のことを「8.3 形式」というそうだ。

「8.3 形式」の場合、MS-DOS のオプション指定はスラッシュで行うためか (CD /? のように)、ハイフンについてはファイル名の中でも使用可能であったようだが、やはり「プログラムで扱う文字列中にハイフン文字が出てくること」はあまり好まれていなかったように思われる。

現在はファイル名の文字数については制限が緩和されているものの、Windows は長らくケースインセンシティブな MS-DOS をベースに発展してきたので、OS 内部的にはファイル名の大文字小文字を区別しない挙動が多かった。最近も正直言ってグチャグチャ、アプリによって対応方針がまちまちである。

GUI での操作が一般的になった現在では、ファイル名にスペースもハイフンも平気で使いがちだが、この辺の「古い感覚」を持ち合わせているかどうか、GUI ではなく CUI での操作を考慮しているかどうか、というところが個々人の好みとして出がちかなーという感じ。

ハイフンケースが登場する場所 : Web

「スペースはトークンを切り出す区切り文字だった」「古のコンピュータは大文字小文字を区別しなかった」という前提から、

「ハイフンは減算記号としてのみ扱いたい」→「関数名や変数名の単語をヒューマンリーダブルに区切るにはアンダースコアを使いましょうか」という流れになったのが、C 言語の登場あたりまで。

一方で、古くは Xerox Alto で使われる Mesa 言語の都合から「キャメルケース」という方法も登場し、Java における Sun の命名規則が分かりやすかったため、キャメルケース・パスカルケースの組み合わせが広まって一般的になっていった、というのが、おおよその流れであることが分かった。

そうすると、「ケバブケース」というのは早々「プログラミング言語中」では使わないモノであるが、ケバブケースが一般的な界隈もある。それは URL・HTML・CSS などの「Web 系」の分野である。

それぞれに異なる事情があるのだが、ココではいくつか根拠となる仕様や標準を紹介する。

まず URL に関して。「ホスト名」「サブドメイン」については、RFC 952・RFC1123 などで、英数字とハイフンとピリオドのみが使用できる・大文字小文字は区別されないということが明記されている。つまりこの時点でスネークケースは禁止だ。コレはホスト名を解決する DNS の仕様にも繋がってきていて、アンダースコアを使ったサブドメインを作ると正しく認識されない問題も発生しうるようである。

つまり、少なくとも example-domain.com だとか sub-domain.example.com といったホスト名、サブドメインの範囲に関しては、ハイフンケースが妥当であり、キャメルケースも DNS 的には区別されないので意味がないということになる。他にも Cookie の仕様により、アンダースコアを含んでいると正しくドメインが認識されないバグが発生したりもするようなので、やはりスネークケースは使ってはいけなくて、ハイフンケースが正しいということになる。

この RFC にならって、サブパス以降のディレクトリ名やファイル名 = 「URL 全体」についても、全て小文字のみ、ハイフンケースで統一しましょうというのが、Google が推奨している内容だ。正確には Google のクローラとしてそのように推奨していて、恐らくはクローラが検索インデックスを作る時に英単語を拾いやすくすることが狙いだと思われる (mypersonalwebsite.com などと書くより my-personal-website.com と書いてもらった方が my・personal・website の3単語を切り出しやすいということ)。

サブパス以降の解釈の仕方は各サーバのミドルウェアの実装によってまちまちで、アンダースコアを含んでいても問題なく認識したり、大文字小文字が区別されていて間違えると 404 になってしまったりと様々なのが実情。そうした「現状の実装」に合わせてしまうと混乱するばかりなので、今後何かシステムを構築する際は、ブラウザのアドレスバーに表示される URL は全て小文字のみ、ハイフンケースに統一するのが良かろうといえる。

ついでに : Git は少なくともブランチ名がハイフンケース推奨

ちなみに、Git Style Guide によると、ブランチ名については小文字のみ・ハイフンケースが推奨されており、スネークケースは NG とされている。

リポジトリ名については言及がないが、GitHub など多くの Git サービスで、リポジトリ名までが URL として登場することを踏まえると、リポジトリ名も小文字のみ、ハイフンケースで書くべきだろう。

コレは Git を利用する際のスタイルガイドであり、Git プロジェクト内で扱うプログラミング言語とは関係のない命名規則である。時々「Python 系のプロジェクトだからリポジトリ名もスネークケースにしたい」とかいう人がいたりするが、例えば PEP に準拠している Poetry が作るプロジェクト雛形は

という構成になっていて、コレが「正しい」のである。そもそも Git と Python は何の関係もなく、それぞれ異なる技術・領域の話なので、Python だから Git 側も同じように…などという発想そのものが間違っている。もっと勉強しましょう。

HTML・CSS はハイフンケース前提

HTML は「マークアップ言語」であり、大文字・小文字を区別しない。以前は古の言語に倣ってか、大文字のみでマークアップされる HTML も散見されたが、現在は基本的に全て小文字で実装されることが多い。

そして、任意の属性名を付けられる data 属性の属性名だったり、URL 中にも登場することになる id 属性の値などにおいては、ハイフンケースが前提であることが分かるだろう。

<!-- リンクすると example.html#section-title という風に URL に現れるので、id 属性値はハイフンケース推奨 -->
<h1 id="section-title">タイトル</h1>

<!-- 任意に命名できる data 属性はハイフンケースで記述する -->
<input id="text-box" type="text" data-recommended-value="1" placeholder="数値を入力してください">

data 属性名は、ハイフンケースで書いておくと、JavaScript 側では自動的にキャメルケースに変換してくれる。

// 前述の <input data-recommended-value="1"> は dataset.recommendedValue でアクセスできるようになっている
const textBoxElement = document.getElementById('text-box');
const dataAttributeValue = textBoxElement.dataset.recommendedValue;  // '1'

CSS についても、最近は calc() 関数の登場で算術記号としてのマイナス - が存在するものの、少なくとも属性値についてはハイフンケースを前提とした機能が提供されている。それは |= という属性セレクタである。

<!-- 次のような言語コードを指定した要素があったとする -->
<div lang="zh-CN">簡体字</div>
<div lang="zh-TW">繁体字</div>

<div lang="ja-JP">日本語</div>

/*
 * "zh" に完全一致するか、"zh-" とハイフンが続く属性値を探索する
 * → zh-CN の要素と zh-TW の要素の2つにスタイルが適用される
 */
div[lang|="zh"] {
  color: red;
}

このように、主に言語コードを想定した機能のようだが、data 属性の値を元にスタイリングしたりする場合にも使えるので、HTML と CSS で記述する属性名や属性値などは小文字のみハイフンケースが原則と考えておくと良いだろう。

CSS クラス名については、アンダースコアとハイフンを併用する「BEM」などの気持ち悪い命名規則も存在するし、jQuery などでゴリゴリに DOM 操作をしていた時代は JS 中心に考えてキャメルケースを好む派閥もいたりした。しかし、それは前述の「Git と Python」のように、「HTML と JS」「CSS と JS」それぞれの言語仕様を混同して考えているモノで、個人的には全く説得力のない意見だとみなしている。

クエリ文字列、POST ボディのキー名はスネークケースが良いと思うが、次点でハイフンケースもアリ

今回色んな文献を見てきた中で、未だ権威的な根拠を見つけられていないのが、クエリ文字列 (Query String・Query Parameter) と、POST 送信時のボディ、平たくいえば「JSON オブジェクトのキー名」はどの記法が良いのか、というところである。

先に結論を書いてしまうと、自分はこれらのパラメータでは小文字のみスネークケースを使うべきだと考えているが、ハイフンケースやキャメルケースを選択しない理由の詳細を書いていく。

クエリ文字列はスネークケースが良いと思う理由

まず、クエリ文字列。コチラは GET リクエスト時のパラメータであり、URL 中にも example-page.html?my_qyery_param=hoge&other_value=fuga という風に登場する。

ID 属性については、example-page.html#my-section というように URL 中にハッシュとして表れるし、HTML 中に属性値として記述するモノであるため、ハイフンケースで書くのが妥当な気がする。

しかし、クエリパラメータについては、ブラウザで表示する場合はアドレスバーに表示されるものの、クエリパラメータを扱うのは誰か、ということを考えると、ちょっと難しいところである。

HTML 自体には、クエリパラメータをパースする仕組みはない。クエリパラメータを受け取ってどうこうするのは必ず JavaScript の世界になるのだ。JavaScript はケースセンシティブで、キャメルケースが多用される言語だ。しかし、URL は前述の RFC でいえば、大文字・小文字が区別されない可能性が高い。そうすると、

ということで、クエリ文字列のキー名なんかにキャメルケースを使うのは危険なのではないか、とも考えられる。まぁ実際のところ自分はクエリ文字列の大文字・小文字が変換されてしまったケースを見たことはないが、「ブラウザのアドレスバーにも表示される」ことを考えると、URL の一部と解釈する実装が存在しそうな気もする。そういった「リスク」を確実に回避しようとすると、JavaScript の中で安全に扱えるのはスネークケースに落ち着くのではないか、という考えだ。

過去に、JS でクエリ文字列を連想配列に変換する方法を紹介している。コレを元に、キー名のケースの違いを考えてみる。

// クエリ文字列は以下のようなワンライナーで連想配列に変換できる
const params = [...new URLSearchParams(location.search)].reduce((acc, pair) => ({...acc, [pair[0]]: pair[1]}), {});

// `?my_qyery_param=hoge&other_value=fuga` というパラメータなら、次のようなオブジェクトになる
// → { my_query_param: 'hoge', other_value: 'fuga' }
const myQueryParamValue = params.my_query_param;  // このようにプロパティ記法でアクセス可能

// `?another-qyery-param=hoge` というハイフンケースのパラメータでもバグりはしない
// → { another-query-param: 'hoge' }
const anotherValue = params['another-query-param'];  // プロパティ記法ではアクセスできず、ブラケット記法が必須になる

// Chrome ブラウザでは少なくとも `?camelParam=hoge` というキャメルケースでも問題はなかった
// → { camelParam: 'hoge' }
const camelValue = params.camelParam;  // JS コード的には一番自然なコードになる

ハイフンケースのキー名はプロパティ記法が使えなくなる、というデメリットがある。キャメルケースはブラウザ等の実装によっては大文字・小文字が維持されるかどうかが不明瞭 (でも JS 側はケースセンシティブなので、万が一キー名の大文字・小文字が変換されていたらプロパティにアクセスできなくなる)、という心理的不安がある。

それらと比べると、スネークケースは「大文字は使わず、全て小文字のスネークケースで送受信する」と決めておけば、JS のプロパティ記法も使えるし、大文字小文字のことを考えずに済む。プロパティアクセス時にスネークケースが登場するのは、JS のコードの中では若干違和感があるものの、一番妥当だと思われる。

…さて、ココまで、ブラウザで開いたページ内の JS コードがクエリパラメータを解釈する場合を想定して書いてきたが、コレがバックエンドの API サーバだったらどうだろう。クエリ文字列を受け取るサーバは Python 製かもしれないし、C#.NET 製かもしれない。そうすると、JS 以外の言語でクエリ文字列をパースした場合に、どういう命名が一番扱いやすいかというと、やっぱりスネークケースが良いのかもしれない。

というのは、サーバサイドを実装するほとんどの言語が「スネークケースを解釈できる C 言語に影響を受けた言語」であるからだ。JavaScript は Java から影響を受けた言語で、Java は C 言語から影響を受けているので、キャメルケースが一般的な中でもスネークケースが使える。Python も C 言語の影響を受けており、JSON を dict に変換した場合なんかにも、キー名がスネークケースだったらアクセスがしやすいだろう。

DB のことまで考えてみると、O/R マッパーにデータを渡しやすいのはやはりスネークケースであろう。というのは、SQL の言語仕様上も、カラム名などはスネークケースが一般的だからだ。MySQL なんかはハイフンが含まれていると上手くデータベースが作れなかったりするので、やはりサーバサイド以降、プログラミング言語が扱う文字列としてはスネークケースが一番どんな環境でも安全といえる。

O/R マッパーによっては、キャメルケースとスネークケースの相互変換をしてくれたりもするが、その場合に問題になるのは略語の扱いだ。例えば user_id は UserId とすべきか UserID とすべきか。input_html は InputHTML とすべきか InputHtml とすべきか。ID や HTML といった文字列の大文字・小文字をいかに変換するかの思想が統制しづらかったりする。

それだったらいっそ、クエリ文字列はクライアントサイド・サーバサイド問わず、様々なプログラミング言語が操作しうるデータだから、小文字のみスネークケースに統一しておいた方が安全といえるのではないだろうか。

自分は基本的に JS (Node.js) でコードを書くが、このあたりは、「RESTful API」の設計指針として特定のプログラミング言語に依存しない命名規則を考えているので、自分が API 設計する時は、クエリ文字列のキー名はスネークケースのみに統一している。

もしスネークケース以外の選択肢を選ぶとしたら、次点はハイフンケース。理由は「小文字のみ」に統一でき、サーバサイド以降でケースインセンシティブな環境が混じっても扱いやすいから。ただ O/R マッパーの実装によってはハイフンを含むカラム名によって SQL が構文エラーになる恐れがあり、ハイフンケースも使いたくはない。大文字小文字が混在するキャメルケースは最後の手段であり、「Java や JavaScript という言語ではキャメルケースが自然に読める記法である」からといって、それだけの理由では自分は絶対に採用しない。

POST ボディも同様の考え方で小文字のみスネークケースが良いと思う

クエリ文字列については、URL 中に表示されてしまうため、ハイフンケースでも良いのか？と考えてしまったが、POST リクエストのボディに関しては、ハイフンケースが良いといえる場面はほぼなく、スネークケース一択といえると思う。

まず、POST 時のリクエストボディは URL としては現れない。そして現代の RESTful な API においては、JSON でデータをやり取りするのがほとんどだ。ということは、「多くの言語で JSON やオブジェクト・連想配列のキー名として扱いやすい命名規則はどれか」と考えると、やっぱり小文字のみスネークケースに落ち着く、というワケである。

JSON ではない、旧来の application/x-www-form-urlencoded の場合はどうやってデータが届くかというと、GET リクエスト時のクエリ文字列っぽく、key1=val1&key2=val2 という風に文字列が結合されるので、コレをパースするサーバサイドのことを考えると、コチラもやっぱり、「ハイフンケースの方が扱いやすい」といった場面は少ないと思われる。

…というワケで、GET でも POST でも考え方は一緒で、プログラムで扱うリクエストデータは、大文字小文字の扱いが発生しないようにキャメルケースは避け、減算記号との勘違いを誘発しないようにハイフンケースも避け、使用するプログラミング言語を問わずに扱いやすいよう、小文字のみスネークケースを採用する、というのが良いと考える。コレが、特定のプログラミング言語に依らない、普遍的な RESTful API の設計方針として良いのではないかと思う。

URL については RFC に従い、HTML と CSS が扱う範疇に関しても、その仕様から「小文字のみハイフンケース」が妥当であるが、その境界線に位置する「クエリ文字列」が若干ややこしくしてくれているところがあるｗ。ただまぁ、こういう検討結果をもって、

というのが、自分が調べた文献から導いた方針である。

ところで : リクエストヘッダのキー名は「パスカル・ハイフンケース」

ところでちょっと気になったのが、リクエストヘッダ。Content-Type とか Content-Length とかをリクエストヘッダに書いたりしたことがあると思う。これらのフィールド名は、RFC2616 や RFC7230 によればケースインセンシティブであり、content-type などと全て小文字で書いても問題はない。しかし大抵の文献では Content-Type のように、ハイフンで区切りつつも、各単語はアッパーキャメルケースのように大文字にされている、変則的な形式である。

この点も、このようになった歴史的経緯などが分かる有用な文献が見つけられなかった。なぜケースインセンシティブだと定義しながら、他所では中々見られない、ケバブケースとパスカルケースの混在のような記法が一般的なのだろうか？

海外には新聞記事のタイトルだとか、書籍のタイトルだとかで使われる「タイトルケース」という記法が存在する。The Quick Brown Fox Jumps over the Lazy Dog という例文を見ると分かりやすいだろう。この表記にもいくつかのスタイルがあるのだが、各単語の1文字目を大文字にする、というのが基本。その中で、文中の of や the は大文字にしないなど細かいルールがあったりする。

推測にはなるが、Request Header なので、新聞などの Headline に使われる記法に倣った…？とか思ったｗ。

なお、PHP など一部の実装では、リクエストヘッダ名はケースセンシティブに扱われてしまい、content-type と書くと認識されず Content-Type と書く必要があったりする (した？) らしい。他にも、HTTP ヘッダのフィールド名には仕様上アンダースコアも使えるようだが、過去にはアンダースコアをハイフンに変換してハイフンケースとして処理するウェブサーバもあったようで、独自ヘッダ名をスネークケースで命名するのは推奨されないところはある。

このように、HTTP リクエストヘッダは「ケースインセンシティブ」「ハイフンもアンスコも OK」という RFC 仕様に対し、「ケースセンシティブに扱ってしまう」「アンスコを許容しない」という仕様に沿わない実装のウェブサーバも多かったりして、なかなか混乱が多い模様。というワケで、リクエストヘッダはとりあえず、慣例的な「ケバブ・パスカルケース (？)」に沿っておくのが安定だろう。

今回は以上

他にも、テキストエディタにおいて「スネークケースの文字列はトリプルクリックで全体を選択できる」「ハイフンケースはトリプルクリックしても単語しか選択できない」といった点で命名規則の優劣を語っている人もいたが、それは何ら RFC や標準仕様に沿った発想ではなく、開発者個人の、後付けの短絡的な思い付きに過ぎない。

自分が得意な一つのプログラミング言語をもって、異なるそれぞれの言語やツールで同じ方式を採用しようとするのも、ゴールデンハンマー病というか、自分の認知資源の節約しか考えてないタイプだなーと思うし、やっぱり RFC や各ツールのベストプラクティスなんかをガン無視してるし、視野が狭い。

Java における大文字小文字の使い分けは、当初は視認性の問題が主で、言語仕様としての強制力はそこまでなかったが、最近は IDE による補完や静的チェックも充実しており、新たな構文も追加されているので、旧来の考え方のままでは通用しない場面も出てくる。他にも例えば Rust 言語では Rust の RFC430 に命名規則がまとまっていたり、Go 言語では大文字始まりにすると Export されるとか、プログラミング言語によってはそうした命名規則が「プラクティスに沿っていない」どころか「コンパイルエラーになる」ような強制力を持っている場合もある。1・2個のプログラミング言語をかじった程度では、この辺のパラダイム切り替えが上手くいかず、どうしても自分が既に知っている言語の知識を流用したくなりがちだ。その言語、そのツール、その「世界」での規則、歴史的経緯や権威の提唱するプラクティスを柔軟に切り替えて、混同しないように努めたい。

Webを支える技術 ーー HTTP，URI，HTML，そしてREST【電子書籍】[ 山本陽平 ]
楽天Kobo電子書籍ストア
価格 : 2827円
Webを支える技術 ―― HTTP，URI，HTML，そしてREST WEB+DB PRESS plus