言葉の由来や、用語の持つ意味を知りたい

Question

言葉の由来や、その用語の持つ意味、あるいは語源や使われてきた理由などを知りたいです。

わたしは独学プログラミングなので言語や用語の深いところまで分かりません。
なぜこのような用語が使われているのかとか、業界用語的なものはまったくの無知です。

たまに以下のような用語や作法に出会う事があり、なぜこのように表現するのかとか、業界用語の由来的なものを知りたいと思っています。

もしお分かりになる方は、ぜひともご教示お願い致します。
こういう時によく使うとか、こうなんじゃないかなど推測でも構いません。
ぜひよろしくお願いします。

---

1.
● hoge（ほげ）foo（ふー）

なぜ 「hoge」 や 「foo」 を使うのでしょうか？これは世界共通で使いますか？もし由来なども分かると嬉しいです

---

2.
● APIを「叩く（たたく）」

　「たたく」とはどういう意味ですか？なぜ「たたく」と表現するのでしょうか？

---

3.
●コミットする

　「コミットする」とは、プログラマーがこの言葉を使う時は、どんな時でしょうか？

---

4.
●古い言語について「大文字」だけ、または「小文字と大文字の混在」

　プログラマーの年齢！？によって書き方が違うように思えます。例えば「VALUE、INT、BOOL」など、大文字で書く人、
あるいは「hInst、bRet」など、変数の頭に小文字を使うのはなぜですか？

---

5.
●変数を「短く表現する」

　「Number」→「Num」、「return、result」→「ret」、「function」→「func」

---

6.
●行間を開けない

　たまに古いタイプの言語でコメントとコードの行間をぴったり詰めて書いているのを見かけます。これはなぜですか？
単純に見ずらいとは思うのですが、もしかすると昔はコードが多く詰めて書かざるを得なかったなどがあるのか？？知りたいです。

（例）
//コメントコメントコメントコメントコメントコメント
BOOL InitInstance(HINSTANCE hInst, int nCmdShow)
//コメントコメントコメントコメントコメントコメントコメント
LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

---

7.
●エンジニア と プログラマーの違い

　語源からして職能が違うとは思いますが、エンジニアはプログラマーと同義と思っていますがどうでしょうか？
日本と世界とでは違いはありますか？たとえば地位的な差があったとして、どちらかで呼び間違えた場合、失礼になったりしますか？

---

Answer 1

1. ● hoge（ほげ）foo（ふー）

これらは「ちょっと動作を試すときに適当な名前の変数を付けるのに考える時間が無駄」という思想から、とりあえず使う「太郎」「次郎」「三郎」くらいのニュアンスのものです。日本では「hoge」「fuga」「piyo」、海外では「foo」「bar」「baz」と続くのが一般的です。piyoやbazより先は私は聞いたことないです。hogeが通じるのは日本だけでしょうきっと。

2. ● APIを「叩く（たたく）」

APIに限らず「コマンドを叩く」とか表現しますね。多分気合を入れてEnterキーを叩く様子ではないでしょうか。正しい由来は知りません。
カチャカチャカチャ…ッターン！

3. ●コミットする

エンジニア界隈ではコミットすると言うと「バージョン管理ツールに作業内容を突っ込む」こととほぼイコールです。SVNやgitについて調べるとわかると思います。別にダイエットすることではないです。

4. ●古い言語について「大文字」だけ、または「小文字と大文字の混在」

古い言語と指されているのが何かはわかりませんが、たしかにCOBOLとかBASICは基本大文字だった気がします。古い言語については詳しくないので、ここでは昨今での大文字オンリーの書き方、小文字大文字の混在について説明します。
全部大文字で書くのは「不変のもの」、小文字大文字混じりで書くのは「動的なもの」という、プログラマの中に伝わる暗黙のルールのような「コーディング規約」と呼ばれるものがあります。言語的に縛られているものではないですが、「見る人が区別しやすいように」そのようになっています。もちろんその限りでないこともありますが、たいていの場合このように使い分けられているものと思ってください。ちなみにhInstとかbRetというパターンは「プレフィクス」と呼ばれ、hやbは「変数の型」を表しています(hInstはインスタンスハンドル型、bRetはBoolean型)。

5. ●変数を「短く表現する」

これは主義主張が対立しているものですね。短く書くほうがタイプ量が少なくて済む！と主張する人と、長く書いたほうが意味が確実に相手に伝わる！と主張している人は長らく戦争状態です。私は長く書く派で、タイプ量なんて昨今のIDEを使っていれば数文字打てば補完してくれるのでそんなものは誤差であると思っています。

6. ●行間を開けない

これもまた主義主張が対立しているものです。私は基本行間を詰めて、「処理の意味的な区切り」で行間を1行空けるようにしています。ちなみに昔はプログラマは「書いた行数」でお給料が決まっていたのでむやみに行を空ける人がいたとかいないとか。

7. ●エンジニア と プログラマーの違い

その2つで比較した場合、エンジニアと呼ばれる人は「仕組みを作る人」、プログラマは「仕組みが機械で動くようにする人」だと思います。もちろんエンジニアがプログラミングできないかと言われればそうではないですし、プログラマが何も考えていないかと言うとそうでもないです。ですがどちらかと言うとクリエイティブな表現がエンジニア、事務的なほうがプログラマ、でしょうか。明確なルールはないかと思います。ちなみに「言われた仕様通りにプログラムする人」は「コーダー」と呼びます。一般的かどうかはわかりませんが、クリエイティブさで表現するならこんな感じでしょうか。

エンジニア ＞＝ プログラマ ＞＞＞＞ コーダー

Comments

[manbo]

masaya_ohashiさん

さっそくご教示いただき誠にありがとうございます。
「たたく」はエンターキーの事でしたか！
素人考えで、何をたたいているのかずっと不思議でした。
6番の行数でお給料というのは初耳でした。なるほどそういう事もあったんですね。
分かりやすいご回答ありがとうございます。

[退会済みユーザー]

コミットはDBのコミットがもとだと思うぞ。

[masaya_ohashi]

確かにそっちもありましたねぇ、基本DBのコミット周りはフレームワークで一度書いてしまったら手を付けなかったので存在を忘れていました…

[退会済みユーザー]

「言語」の場合、古いものだと「UNIX」とか、「アセンブリ言語」とか、「機械語」とかまでさかのぼりますからねえ…。
しかも、未だにどれも現役で使われていたりするし…。
今はある意味プログラミング言語戦国時代、という状態ですからねえ。

あと、「行間を開けるかどうか」について、古い人でないと分からないことを追記しておきますね。

昔、大型コンピュータでプログラム処理する場合、プログラムに「1個のスペース」とか、「1行の行間」とかが入ると、それだけでその分「処理時間に影響する」とか、「プログラムがまともに動かなくなる」という時代があったんですよ…。
その為、プログラミングは今より大変だったんです。
(私もこれで泣きましたよ…。)
後は、エディタに補完機能が無かったので、「ソースコードの行数が多い＝労力がかかる=給料大」という構図も成立していました。

今は、スペースや行間はコンパイラが適切に処理してくれるため、エラーにならない限りは空けようが問題となりませんから。

ちなみに、私は「一行開ける派」です。追加処理やコメントがしやすくなりますので。

[manbo]

tmkey01さん、プログラムの量が給料になってる時代がやはり存在したんですね。そういえば小学生のころ、作文で原稿用紙を何枚使うかで争ってる時代があったことをいま思い出しました。だいたい10枚とかいくのは会話形式多めで、1行開けとかしてて、ずるいとか言ってましたね。
それより、アセンブリがいまも現役で使われているとは衝撃です。鬼畜ですな。たしか、ゲーム・ドラクエの初期コードはアセンブリで書いてたとかを聞いた事があります。それに比べたらいまはIT土方とか言ってられませんな。

[zigutabi]

変数を短くするというものに関して補足ですが、誤字脱字を防ぐ面もありました。コードを記述する時、例に挙げるなら、「Number」を「Numbar」と書き間違えたりです。英語は発音と文字との一貫性が弱い傾向にあるため、当のイギリス英語学者ですら、その支離滅裂を皮肉ったジョークがあるぐらいです。つまり長い変数ですと、誤った綴りで記述する恐れがあったからです。
しかし現在では、Linux標準エディタの「vi」ですら参照してくれていますので、長さは大した問題ではなく、より法則性に従った変数名が使用可能です。10文字よりも20文字の方が表現の自由度が上がるので、より法則性に沿った変数ができます（変数名が4文字までだと、法則もくそもない）。そのため、よりよい変数名は、より法則に則ったものがよく、それに沿ったものであれば、長くても短くても問題ないという流れになっています。

[manbo]

zigutabiさん　なるほどですね。誤字を防ぐというのは理にかなってますね。じぶんも難しい単語は避けてる気がします。法則性はコード量が多くなったらいいかもですね。そういうのも気にしてたのですね。自分だけかもしれませんが、法則性ではないですが、字面（じづら）は気にしてます。L、I、J、Fは小文字にすると、「l、i、j、f」で、単語の前後で使用するとコピペがしにくいとか、間違えやすいみたいな事がありそういう場合は、意味の同じ単語に変えたり、幅の広い文字を入れたりしてました。そういえばオッサンコードでよくみるのが変数のあたまに「＿（アンダーバー）」を入れたりするのも見かけますね。個人的には、これはキライなのですが（意味があるのか、ただ被らないために使ってるのか不明なので）このあたりはどうなんでしょうかねー。

Answer 2

1. ● hoge（ほげ）foo（ふー）

メタ構文変数ですね。起源は不明ですが、foo/barは世界（英語圏）共通、hoge/hugaは国内のみです。

1. ● APIを「叩く（たたく）」
2. ●コミットする

叩く = 実行する/呼び出すといった感じでしょうか。
コミット = 狭義ではDBなどのトランザクションを確定させる意味がありますが、口に出して使ったことはありません。
他にもいろいろあります→不思議の国のSE用語

一般的な用語や動詞が業界内では特別な意味を持つことは他の業界でもよくありますね。面白いです。
動詞/不動産業界用語

「大文字」だけ

年齢は関係ありません。言語にもよりますが、型名や定数などは大文字のみで表記することが多いです。
あ、大文字小文字を区別しない言語を使い慣れた世代ならありえるかも。

hInst,bRet

ハンガリアン記法です。

1. ●変数を「短く表現する」

好みの問題だと思います。
単純にタイプ量を減らす目的と、変数（関数）名が長いと目がチカチカするので短くすることがあります。

1. ●行間を開けない

古いBASICなどインタプリタ系言語だとコードが短いほど速く実行されるので行間を詰めて書くのもありだったです。
読みづらいのでまともなプログラマで今実践している人はいないと思います。

1. ●エンジニア と プログラマーの違い

エンジニア 機械、電気、建築なども含めた技術者 なのでプログラマも含めたより広い概念ですね。

Comments

[manbo]

can110さん

さっそくご回答いただき誠にありがとうございます。
明快な回答をいただき感謝です。
6番の行間あけると遅い言語もあるんですね。なるほどそういう歴史があったんですね。
お教えいただき誠にありがとうございます。

Answer 3

こんにちは。

推測混じりですが回答してみます。

1. ● hoge（ほげ）foo（ふー）

メタ構文変数なんて大げさな名前がついてますが、このWikipediaの記事は分かりやすいと思います。

1. ● APIを「叩く（たたく）」

個人的には「モグラ叩きっぽい」のでなんとなくしっくりきます。
的確に叩かないと点数にならない。（言うことを聞かない。）

1. ●コミットする

これはそのまんまでは？ バージョン管理ソフトやデータベースのコマンドの名前です。「登録する」や「決定する」的なイメージで捉えてますが、もう少し違ったニュアンスも含んでいそうです。あまり深く考えたことは無いですが。

1. ●古い言語について「大文字」だけ、または「小文字と大文字の混在」

マクロの名前は全部大文字にするという習慣は比較的普及している習慣と思います。絶対的と言うわけではないです。COBOLやFORTRANの世界ではまた別かも知れません。離れて久しいので現状は把握していません。

例に上げられた混在はハンガリアン記法です。最近であまり使われませんがが、識別子を見ただけで識別子の重要な特性を判別できるように使えばなかなか良い記法と私は思います。（ハンガリアン記法を使わない人の方が多いです。）

1. ●変数を「短く表現する」

タイプが面倒とか、長すぎる識別子はよく無いとかでしょうか。
昔のFORTRANは識別子名は最大6文字でそれ以上付けても判別されない等の制約がありました。（流石に今のFORTRANにそんな制約はないと思いますが。）それを引きずっている人は、つい短くするかも。

1. ●行間を開けない

たぶん書いた人の好みかと。
改行を節約するくらいならコメントをそもそも書かないだろうと思います。

1. ●エンジニア と プログラマーの違い

個人的な理解ですが、数学に拒否感を持つ人をエンジニアと呼ぶことには違和感を感じます。でも、数学がからっきしの優秀な職人さんはいくらでもいると思いますし、そのようなプログラマーも少なくないと思います。

Comments

[manbo]

Chironianさん

早速ご回答いただき誠にありがとうございます。また詳細な回答感謝いたします。

大文字や変数の記法は、やはり言語の歴史的な背景があったんですね。
非常にためになりました。

お教えいただき誠にありがとうございます。

Answer 4

1. foo/bar は欧米由来で共通、hoge は日本特有ですね。代名詞のようなものです。

何かしらの説明の際によく出てくる名前としては、暗号における「Alice」と「Bob」は定番ですね。

1. キーボードに「Enter」キーがあります。これを「叩く」ことでコマンドが実行されます。ここから転じて、コマンドを実行することを「コマンドを叩く」という呼び方をするようになり、それが一般化して、コマンド以外でも使われるようになりました。

似たものとしては「（リクエストを）投げる」あたりでしょうか。本来の英語としては「送る」になるのですが、なぜか野球のボールのように投げる、受けるということがあります。
あと忘れてはいけない「殺す」もかな。異常動作をしているプロセスを止めることを「殺す」とはよく言います。まあ UNIX でのプロセス強制停止コマンド（実際にはもう少しいろんなことができますが）がそのものずばり「kill」なのですけれども。

1. もともとはDBの用語で、「一連の変更を確定する」という意味です。ここから転じて、「変更したものを確定させる」、すなわち「個人の作業結果を全員に展開する」という形で使われる場合があります。

2. 古いシステムだとそもそも英小文字が使えなかったというのもあります。現在の言語ではそんなことはありませんが、例えば予約語は大文字で、そうでないものは小文字で、という使い分けをすることもあります（SQLとか）。これはソースコードを見たときに分かりやすくするためのテクニックの一つです。

3. これも古いシステムだと、変数名の長さに制限があったのです。例えばパソコン黎明期のBASICですと、変数名が2文字までというのもありました。現在では変数名の長さ制限はほとんどありませんが、これもコードを見たときにあまりに冗長な長さだとみにくい（加えてタイプミスの危険もある）ので、ある程度省略することが多いです。

4. 昔の考え方で、プログラムの規模を「ステップ」や「ライン」という数え方をします。空行は無視しないといけないわけですが、それを嫌ってそもそも空行を入れない、という考え方になるわけです。

5. プログラマーはエンジニアの部分集合、ですね。ただプログラマーといったときに、実はコーダー（coder。単にコードに展開するだけの人）という場合もあるのですが。

Comments

[manbo]

tacsheavenさん

早速ご回答いただき誠にありがとうございます。
なるほどですね。SQL系から由来している用語が多いんですね。
あと、kill でもそうですがプログラムやマシンを擬人化して表現するのもよく使うみたいですね。食わせるとか。そういう背景を知らなかったので、すごくためになりました。

変数やラインおよびステップの考え方もはじめてしりました。
なるほどですね、あまり意識していませんでしたが、昔の遅いパソコンとかなら1行コードを読むのも大変そうなのでラインみたいな考えで考えていたのかもしれませんね。
お教えいただき誠にありがとうございます。

Answer 5

1番はメタ構文変数でどうぞ

3番はRDBでのコミットは定義されていますが、一般的にコミットといえば契約をしたり目標設定を約束したりするときの用語ですね

4番はハンガリアン記法やキャメルケースで検索してください

6番は空行を許さない言語もあるのでそのせいだとは思いますが、「あいてないと見づらい」のは質問者さんの主観であって、「あいていると見づらい」という意図かもしれません

7番はエンジニアは技術者ですから一概にプログラマと同列には語れないでしょう。基本的にプログラマはプログラミングに業務が特化していると考えればいいのではないでしょうか？
企画とかデザイナが分化シている場合は、よりプログラムよりの仕事ということ。

Comments

[manbo]

yambejpさん

早速ご回答いただき誠にありがとうございます。
4番は、ハンガリアン記法というんですね。初めてしりました。
6番は、行間を許さない言語もあるんですね。こちらも初めてしました。
お教えいただき誠にありがとうございます。

Answer 6

以前こんな記事を読んだことがあります。

・不思議の国のSE用語
https://qiita.com/t_nakayama0714/items/478a8ed3a9ae143ad854

こんな記事もあったので貼っておきます。

・hoge, hogehogeの由来、foo,bar の語源
http://blog.dacelo.info/net/entry-662.html

個人的にもあまり長い名前は嫌いです。
でも短過ぎて意味が分からないのも嫌なので、短くて意味の分かる絶妙なところがいいですよね。

Comments

[manbo]

yuki-saitoさん

早速のご回答ありがとう誠にありがとうございます。
業界用語こんなにあったんですね。Qiit 全部読んでしまいました。
なるほどそういう意味だったのか。というのが多くありました。
お教えいただき誠にありがとうございます。

[yuki-saito]

いえいえ！少しでもお役に立ててよかったです＾＾

Answer 7

昔の処理系だとメモリが貴重だったので、変数名は短く、改行は極力入れない（BASICでは：で区切ってマルチステートメント推奨とかｗ）なんて事が当たり前でした。

Comments

[manbo]

tsuntsunさん

ご回答いただき誠にありがとうございます。
コードのメモリまで気にする時代があったんですね。
いまの感覚で育ってるので、まったく実感はありませんが、古い文献などを読むとやたらメモリが食う事を心配しているのを見かけて、たかだか数メガのメモリで、メモリ消費がどうの..というのがあり、はじめはまったく理解出来ませんでした。もっともローコストで駆動できるのはわるくないとは思いますが。
わたしが最初に使ったPCはMacですが、HDが６ギガでメモリは256MB、当時は画期的でしたが、いまからするとスマホ以下ですね。

Answer 8

面白かったのはこれ。

https://qiita.com/t_nakayama0714/items/478a8ed3a9ae143ad854

分かる範囲だと

１　ただの慣例。英語圏では違うらしい。
４　プログラミング言語によって文化圏があって・・とかの話になる。
https://qiita.com/yimajo/items/a3fac0026c07ec538fc2
５　定番のは短くするのはありだけど・・　IDEを使う、今時は、変に短くしなくてもいいような。

Comments

[manbo]

kiichi54321さん

早速のご返答いただき誠にありがとうございます。
ヨーダ記法なるものもあるんですね！はじめてしりました。
お教えいただきありがとうございます。

Answer 9

1. ●行間を開けない

Windows以前の、例えばMS-DOSなどでは、画面が25行（多くて30行程度）しかなく、行間をあけると見通しが悪くなるということがありました。

行間を詰めるオッサンがいたら、その名残かも知れません。

Comments

[manbo]

fuzzballさん

ご回答いただき誠にありがとうございます。
２５行しか表示できないとは衝撃です。いまの時代には考えられないですねー。たしかにそのせいかもしれないですね。
比較的古い言語で、C言語などのソースがまさに詰め詰めなものが多く、
オッサンが書いたであろう感があります。
貴重な情報ありがとうございます。

Answer 10

1. ●古い言語について「大文字」だけ、または「小文字と大文字の混在」

そもそも古い処理系では、大文字と小文字が区別できなかったのです。

その昔、ソースコードは「コーディングシート」と呼ばれる専用の用紙に記入し、
これをキーパンチャーに渡して「紙カード」に穴をパンチしてもらっていました。
「紙カード」1枚は、コーディングシートの1行に相当し、0〜9、A〜Z、記号類を示す穴を開けるのです。
この「紙カード」をカードリーダにセットして、一気に読み込ませることによって、ソースファイルに変換されていました。
こういう仕組なので、文字の種類に制限があったのです。
それで、大文字と小文字を区別できない時代がありました。

カーニハンとプローガーの古典「ソフトウェア作法」という本があります。

http://www.kyoritsu-pub.co.jp/bookdetail/9784320021426

この本の中で、ソースコードを小文字で印字すると読みやすいことがわかったので、そうすることにする、という話題が出てきます。
そして、この時代にはスクリーンエディタが登場していたのだと思いますが、小文字で書いたRatfor (Ratinal FORTRAN)のコードをFORTRANのコードに変換する、という話題が出てきます。

Comments

[manbo]

chokojoriさん

ご回答いただき誠にありがとうございます。
なんと、大文字・小文字の区別が出来ない時代があったのですね。
それは知りませんでした。
しかも紙カード時代にまでさかのぼるんですね。
実物は見たことありませんが、紙カードってなんか雰囲気いいですね。
マークシートみたいな感じなんですかね。なるほどです。
貴重な情報ありがとうございます。