foo, bar, Alice, Bob はどこから来たのか - 技術書のサンプル名の由来

4 分で読めます
雑学プログラミング技術書

この記事は約 6 分で読めます。

プログラマーなら誰もが見たことのある名前たち

技術書を開くと、サンプルコードに必ずと言っていいほど登場する名前があります。変数名の foo と bar、暗号の説明に出てくる Alice と Bob。これらの名前は世界中の技術書で共通して使われていますが、なぜこの名前なのか考えたことはあるでしょうか。

それぞれの名前には歴史的な由来があり、知っておくと技術書を読むのが少し楽しくなります。

foo と bar の由来

foo と bar の語源については、IETF が 2001 年に公開した RFC 3092「Etymology of "Foo"」がまとまった考証を残しています。bar と組で使う foobar は、第二次世界大戦期のアメリカ陸軍のスラング FUBAR (もはや原形をとどめないほど滅茶苦茶) が変形したものだと語られることが多いのですが、RFC 3092 はむしろ逆で、FUBAR のほうが foo から派生したものである可能性が高いと述べています。

foo 単独の用例はもっと古く、1930 年代から 1950 年代初めにかけて描かれたビル・ホルマンの漫画「Smokey Stover」に繰り返し登場します。プログラミング文化への流入経路としてよく挙げられるのは MIT の Tech Model Railroad Club (TMRC) で、RFC 3092 は、TMRC で編まれた 1959 年の「Dictionary of the TMRC Language」に Foo の項目があったという会員の証言を伝えています。

いずれにせよ、foo と bar は「意味のない仮の名前」として定着しました。変数名に意味を持たせたくないとき、つまり「この変数の名前は本質ではない」と示したいときに使われます。3 つ目が必要なときは baz が登場し、foo, bar, baz の 3 点セットが完成します。

Alice と Bob の由来

Alice と Bob の起源は明確です。1978 年、Ron Rivest、Adi Shamir、Leonard Adleman の 3 人が発表した RSA 暗号の論文で、通信の当事者を Alice と Bob と名付けたのが始まりです。

それ以前の暗号論文では、通信者を A と B のような記号で表していました。この 2 人がなぜ Alice と Bob になったのかを示す記録は残っておらず、映画「Bob & Carol & Ted & Alice」の登場人物から採ったのではないかという見方があります。ただ、記号ではなく人物として役割を追えることの効果は大きく、以降の暗号論文でも Alice と Bob が標準的に使われるようになりました。

Alice と Bob の仲間たち

暗号の世界では、Alice と Bob 以外にも多くの登場人物がいます。それぞれにアルファベット順の名前と明確な役割が割り当てられています。

Charlie (または Carol) は 3 人目の通信者です。Alice と Bob の 2 者間通信に 3 人目が加わるシナリオで登場します。Dave は 4 人目の通信者で、さらに複雑なプロトコルの説明に使われます。

特に重要なのは Eve と Mallory です。Eve は "eavesdropper" (盗聴者) の頭文字から来ており、通信を傍受する受動的な攻撃者を表します。Mallory は "malicious" (悪意のある) から来ており、通信内容を改ざんする能動的な攻撃者を表します。Eve は聞くだけ、Mallory は書き換えもする。この区別は暗号プロトコルの安全性を議論する上で重要です。

他にも、Trent (trusted arbitrator、信頼できる仲裁者)、Grace (政府機関の代表。標準やプロトコルに弱点を仕込む側として登場します) など、状況に応じた登場人物が定義されています。

日本の技術書の「太郎」と「花子」

日本の技術書では、サンプルに「太郎」「花子」がよく使われます。これは日本語の「名無しの権兵衛」に相当する、代表的な仮名です。

もっとも、日本語のサンプルでも「ユーザー A」「ユーザー B」のような記号や、「田中さん」「鈴木さん」のような苗字が使われることは多く、「太郎」「花子」が唯一の選択肢というわけではありません。名前の付け方は書き手の好みや、その本が想定する読者によって変わります。

hoge と fuga は日本独自

日本のプログラマーが foo/bar の代わりに使う hoge と fuga は、日本独自のメタ構文変数です。英語圏のプログラマーには通じません。

hoge の由来は諸説ありますが、1980 年代の日本のパソコン通信文化から広まったとされています。「ほげ」という響きの脱力感が、「意味のない仮の値」というニュアンスにぴったりだったのかもしれません。3 つ目が必要なときは piyo が使われ、hoge, fuga, piyo の 3 点セットになります。

Lorem ipsum の由来

技術書に限らず、デザインのモックアップでよく見かける "Lorem ipsum dolor sit amet..." というダミーテキスト。これは古代ローマの政治家キケロが紀元前 45 年頃に書いた哲学書「善と悪の究極について」(De Finibus Bonorum et Malorum) の一節を改変したものです。

現在よく使われている版は、1966 年に Letraset が発売した文字転写シートの見本文に由来します。1960 年代後半から組版の現場で使われ、DTP (デスクトップパブリッシング) の普及とともに世界中に広まりました。原文のラテン語を意図的に崩してあるため、ラテン語として読んでも意味は通りません。

42 が「答え」として使われる理由

技術書やコード例で、サンプルの数値として 42 がやたらと登場することに気づいたことはないでしょうか。これはダグラス・アダムズの SF 小説「銀河ヒッチハイク・ガイド」(1979 年) に由来します。

作中で、超高性能コンピューター「ディープ・ソート」が「生命、宇宙、そして万物についての究極の疑問の答え」を 750 万年かけて計算した結果が 42 でした。この設定がプログラマー文化に深く浸透し、「とりあえず何か数値が必要なとき」に 42 を使う慣習が生まれました。

プログラミングの歴史に関する書籍を読むと、こうした文化的背景がさらに深く理解できます。

Hello, World! の起源

プログラミングを学ぶとき、最初に書くプログラムは「Hello, World!」と表示するものです。この伝統は、1978 年に出版された Brian Kernighan と Dennis Ritchie の共著「The C Programming Language」(通称 K&R 本) に遡ります。

ただし、Kernighan は 1974 年の Bell Labs 内部文書「Programming in C: A Tutorial」で既に "hello, world" を使っており、さらに遡ると 1972 年の B 言語の入門文書「A Tutorial Introduction to the Language B」に同じ例が見つかります。K&R 本の爆発的な普及により、Hello, World! はプログラミング入門の象徴として世界中に定着しました。

関連記事

まとめ

技術書のサンプル名には、それぞれ興味深い歴史があります。foo/bar は戦前の漫画や MIT のハッカー文化に、Alice/Bob は RSA 暗号論文に、hoge/fuga は日本のパソコン通信文化にたどりつきます。Lorem ipsum は古代ローマのキケロに遡り、42 は SF 小説から、Hello, World! は K&R 本から広まりました。これらの由来を知っていると、技術書を読むときに「ああ、ここにも歴史があるんだな」と、ちょっとした楽しみが増えます。

共有:Xはてブ

この記事は役に立ちましたか?

関連用語

関連記事

ソフトウェア開発の歴史を変えた 5 冊の技術書

アルゴリズムの学問化からコードの可読性革命まで、ソフトウェア開発の方向性を決定づけた 5 冊の技術書を、時代背景とエピソードとともに紹介します。

プログラミングの本には何が書いてあるのか

プログラミングの本を開いたことがない人に向けて、実際にどんなことが書いてあるのかを紹介します。コードだけでなく、考え方や設計の話も載っています。

O'Reilly の表紙が動物の理由 - 技術書の装丁デザインの秘密

O'Reilly の動物表紙はなぜ始まったのか。表紙の動物の選び方、技術書のフォントや判型が読みやすさに与える影響など、装丁デザインの裏話を紹介します。

「日本語で読める技術書は 1 割」は本当か - 技術書の翻訳事情

英語圏で出版される技術書のうち、日本語に翻訳されるのはごく一部です。この情報格差の実態と、格差を埋めるための現実的なアプローチを考えます。

本屋のプログラミングコーナーの歩き方

本屋のプログラミング書コーナーに行くと、棚いっぱいの本に圧倒されます。どこを見ればいいか、どう選べばいいかを初心者向けに案内します。

30 代エンジニアが読書で取り戻す「設計の言語化力」

経験年数は十分なのに設計意図を言葉にできない。30 代エンジニアが直面する「暗黙知の壁」を、技術書の読書で突破する方法を解説します。