変数名は「AIにレビューさせろ」Part0(初心者の方へ)

老兵は死なず、AIと踊る

変数名は「AIにレビューさせろ」Part1を公開したのですが、同時にAIから
「これは初心者向けの記事ではないのでは?」
と散々、指摘を受けたので初心者とスクールで教えようとしている方向けに補足を行います。どちらが最初でも構いませんが、初心者の方は本記事を最初に読んだ方がよいかもしれません。

初心者の方

 例えばですが、Google C++ スタイルガイドや、Linux Kernel 2.6 Documentation- CodingStyle を参照してみてください。変数名の記載の項目になります。
 何を言っているかわからないかと思います。それが答えです。

という、哲学的な問答はやめてストレートに言いますと、「まったくの初心者の方は、まずはプログラミングの書き方を学習するべきであり、コーディングスタイル(変数の命名だけでなく、あるべきコードの書き方の基準)は、後回しにしてもかまわない」ということになります。つまり今は考えなくてよい(もし気になるのならAIに聞け)ということになります。

それでも、気になる方はもう一度Google C++スタイルガイドの「命名規則」を読みましょう。引用しますと、

命名に関するスタイルルールはかなり恣意的なものです
・あなたにとってわかりやすいと感じるかどうかに関わらず、「ルールはルール」と考えるようにしてください。

ということです。これの意味するところを大げさにかくと、「変数名は「AIにレビューさせろ」Part1」の記事になります。
加えて、日本人に対する補足を行います。(通訳案内士の観点になりますが)、日本人というのは「言われなくても規律を守る」民族のようで、一方で欧米(というか民主主義の国の人は)、「自由が基本、必要ならルールを作る」という文化的な違いがあります。主にアメリカからくるルールを日本人に当てはめると、必要以上に日本人が守りすぎるという傾向があるので注意しましょう。という話です。

初心者から脱しようという方

 上記の2つのスタイルガイドをみて、「言っていることは解る」という人はもう、命名規則については卒業ということになります。
「これでは不安」だという方は、一つ卒業試験をしましょう。上記の2つのスタイルは真逆のことを言っている部分がありますがどれでしょうか?

私が見つけた正解の1つは、
Linux Kernel 2.6のコーディングスタイルは、変数名の省略を許容しており、Google C++の方は許容していないということがあります。
(もっともどちらのスタイルもループカウンタは i でよいとしています)。
私の観点(理解)になりますが、これらの違いを補足すると、カーネルは基盤ソフトウェアで、Googleが作ろうとしているものはアプリケーションということも言えます。
コーディングの文化というか、作成しているもののレイヤーが異なります。
例を挙げると、変数の値を交換する swap関数 というものがありますが、Linuxの方は、swap関数を作る方、Googleの方は、swap関数を使う方ということです。

swap関数を C言語風に 書くと

void swap( int *a, int *b) {
 int t = *a;
 *a = *b;
 *b = t;
}

となるかと思います。ここで、a,b,tと出ましたが、これに対して「変数名が、意味のない1文字だろ!」という人は(0ではないかと思うが)私の周りではいません。逆にここで変数名に対してとやかく言う人とは距離をとった方がよいです。(実は変数名以外には問題があります)。

一方で、Googleの方は、swap関数を使う側、例えば、

 swap( oldMachineStatus, newMachineStatus);

と言ったコードにフォーカスを当てているということになるかと思います。

言っていることは解るが釈然としない(初心者の方)

 コードコンプリートやリーダブルコードなど実績のある書籍を読むことをお勧めします。
「1文字変数はダメ。booleanは○○。」と言ったような断片的な情報ではなく、「なぜこのように命名すると良いのか?」についてできるだけ主観を抑える努力を用いて書かれているでしょう。
また、上記のようなスタイルガイドも併せて読むことを勧めします。書籍やガイドによって矛盾点が見つかります。それに対して『自分はどうするか?』と自問してみましょう。

2026年現在確認できる多くのコーディングスタイルでは、ループカウンタには i でよいとしていますが、意味のある名前にしましょうという書籍もあるようです。「○○にこう書いてある」ではなく、あなたの正解を見つけてみましょう。

「能書きはいいからお前はどうしているんだ?」という方

 (Grokの指摘を受けての追記)私自身ですが、アマチュア時代を入れると40年以上プログラミングをやっており、使った言語も、BASIC、アセンブラからC/C++、Java、perl, php, Ruby、python, ADPと多岐にわたるので、「これ」と言った基準はないです。と言っても傾向はあるのでご紹介します。基本的にlinuxのコーディングガイドが近いかもしれませんが、業務アプリも作成するので混ざっています。下記を見てもらえますと私が「1文字変数はNG」、「booleanはis/has」と言われると反発する理由が良くわかるかと思います。

  • 慣例、ルールがあればそれに従う。自分で作る場合は英語で名称を考える。
  • 名前付けの優先順位
    グローバル変数、メンバ変数、引数、ローカル変数の順で優先順位が下がる(適当な名前でよい)
    グローバル関数名、クラス名、メンバ関数名の順で優先順位が下がる
    ※名前空間は今のところ使用していないが、徐々に意識するようにしたい。
  • 変数名は名詞が基本、もちろん内容によって形容詞、動詞を使うこともある。
  • 関数名、メソッド名は動詞が基本、以下同様
  • クラス名は、名詞が基本、以下同様
  • 1文字2文字変数については、ローカル変数で慣用的に使うことがある
    a, b, c ・・・抽象的な値を表現するとき
    v1, v2, v3 も同様に抽象的な値を表現するとき
    c, cnt ・・・ ループカウンタ
    f, flg フラグ
    i, j, k, l, m ・・・ループインデックス
    n ・・・ (next)の略
    p, q ・・・ ポインタ
    s ・・・ 合計
    t ・・・ テンポラリ変数、時間(秒)
    k / v ・・・ (マップの)key value
    u ・・・ ユーザID
    r ・・・ 戻り値
    x, y, z ・・・ 座標
  • 略称、非略称
    DBのカラム名、グローバル変数、グローバル関数、クラス名のようにグローバル性が高い名称は非略称、その他は適宜略称を使う
  • 単語の区切り
    複数の単語を区切るときの作法として、キャメルケースを使うか(区切りで大文字にする)、スネークケース(アンダーバー’_’で区切る)かがある。
    モダンな言語(Java以降)はキャメルケース
    アセンブラ,C,C++は、スネークケース
    グローバル変数、グローバル関数、クラス名はキャメルケース、ローカル変数、メンバ変数はスネークケースと混ぜて使うこともある。
    略称変数の場合、そのまま結合することやプレフィックス、ポストフィックスとして使うこともある。
     nsatatus
     namep
  • 業務アプリの例はPart2を見てもらえればと思います。

実践

さらに、実際のコードがどうなっているかを調べることも重要です。
以下、Linux kernel 6.18.3 で適当に選んだファイル(acct.c)からの変数名(と引数名)を出現順で10個を列挙します。
acct
sbuf
p
ns
res
pin
work
acct
file
name

私には大変馴染み深い名称ですが、皆様どうでしょうか?
これだけだと何なので、同プロジェクトから適当に選んだpythonのファイル(check-perf-trace.py)からの変数名(引数名)を10個ほど列挙します。

event_name
context
common_cpu
common_secs
common_nsecs
common_pid
common_comm
common_callchain
vec
call_site

理解できるかはともかく、分かりやすい名前になっているかと思います。

老兵は死なず、AIと踊る

変数は「箱」か「名札」か?― 初心者教育から束縛モデルまでを考える

 以前、「変数は箱か名札か?」で動画を上げたのですが、あまりアクセスはなかったのですが、最近少しアクセスがあり、改めて見たら面白かったので、もう少し突っ込んでまとめてみました。

プログラミング教育の現場では、今も昔も「変数とは何か?」が最初のハードルです。
伝統的には「変数は値を入れる」と説明されますが、
最近では「変数はオブジェクトに貼られた名札(ラベル)だ」と主張する声も聞かれます。

一見、単なる比喩の違いのように見えますが、
この議論の背後には、プログラミング言語の理論と設計思想の根深い違いがあります。
ここでは、初心者教育から理論的背景、そして実用上の含意までを整理してみます。


Ⅰ. 初心者教育での「箱」モデルの意義

最初に登場するのが、もっとも直感的な「箱」モデルです。

変数とは、値を入れておく箱である。

a = 1
b = a
a = 2

このとき、a の中身を 2 に変えると、b の値はそのまま 1。
学習者は「箱に入れた値を取り出して使う」イメージで簡単に理解できます。

C や C++ のように、メモリ上の領域が実際に割り当てられる言語では、
この比喩はきわめて正確であり、教育的にも有効です。


Ⅱ. 「名札」モデルの登場と混乱

一方で、Python や JavaScript では、変数の実体がやや異なります。
これらの言語では、変数はオブジェクトへの参照を持つ仕組みであり、
代入は「名札を貼り替える」動作に近いのです。

変数は、オブジェクトに貼る名札である。

a = [1, 2, 3]
b = a
a[0] = 9

ここで b を出力すると [9, 2, 3]
箱モデルでは説明しづらく、「名札モデル」の方が合うように見えます。

しかし、注意すべきはこの比喩も完全ではないという点です。
配列の各要素 a[0] にまで「名札」を持ち込むと、
今度は配列の連続性やメモリ構造のイメージが崩れてしまいます。
結果として、初心者をさらに混乱させることもあるのです。


Ⅲ. C/C++が示す「共存モデル」

C や C++ では、値型と参照型(ポインタ型)が共存しています。

int a = 1;
int &r = a;

このとき ra の別名であり、どちらを変更しても同じ領域が変化します。
つまり C++ は、「箱」と「名札」の両方の性質を明示的に区別できる言語です。

教育的にはこの構造が非常に有益で、
物理的なメモリ構造と論理的な参照概念の橋渡しを学ぶことができます。

ただし、ポインタや参照はプログラミングの初心者にとっては難しい概念である。


Ⅳ. 関数型言語における「束縛モデル」

さらに理論的な世界へ進むと、
「変数は値を入れるものではなく、“値(あるいは式)に束縛される名前”だ」
という考え方が登場します。

束縛(binding)=変数と式の対応を定めること。

Haskell などの関数型言語では再代入ができず、
変数は一度束縛されたら変更できません。

x = 1
y = x + 2

このとき xy は「箱」ではなく「式の定義名」です。
評価は遅延的に行われ、必要になるまで実際の値が求められません。

この仕組みは理論的には非常に美しく、
純粋関数・副作用の排除・数学的推論のしやすさといった利点をもたらします。


Ⅴ. 束縛モデルの強みと限界

束縛モデルの最大の利点は、式そのものをオブジェクトとして扱える点です。
たとえば、自動微分やDSL(ドメイン固有言語)の分野では、
式構造を保持して解析・変換する必要があります。

しかしその一方で、束縛モデルには現実的な制約もあります。

項目 束縛モデル(遅延評価) 参照モデル(即時評価)
抽象性 高い 低いが直感的
実装効率 低い(オーバーヘッドあり) 高い
デバッグ 難しい(評価タイミング不明) 容易
メモリ予測 困難 明確

結果として、実用言語の多くは参照モデルを基本にし、
必要な箇所だけ束縛的な振る舞いを導入する
設計を採用しています。


Ⅵ. 束縛モデルが主流にならなかった理由

    1. パフォーマンスとメモリ効率の問題
      遅延評価や式構造の保持にはコストがかかる。

    1. 最適化の困難さ
      コンパイラが静的解析しにくく、最適化しづらい。

    1. デバッグや可視化が難しい
      どの時点で評価されたかが分かりづらい。

    1. 実際に必要なケースが限られている
      自動微分やDSLなど一部領域に限定される。


Ⅶ. 現代的アプローチ:必要な部分だけ「束縛的」に

今日では、C# の Expression<T>
Python の sympy / jax
C++ の Expression Template など、
必要な箇所だけ束縛モデル的挙動を模倣する仕組みが採用されています。

つまり、
「束縛モデル全体を採用するのではなく、
その一部を道具として使う」
という方向に落ち着いています。


Ⅷ. 教育的まとめ:段階的理解のすすめ

学習段階 目標 モデル 教育上の重点
初級 値の代入と操作の直感的理解 箱モデル シンプルな心象で理解する
プロ(中級) メモリと参照の関係を理解 箱+参照モデル オブジェクト共有・ポインタ・参照
研究レベル 抽象的な束縛・遅延評価・純粋関数 束縛モデル 数理的抽象化・関数をデータとして扱う


Ⅸ. 結論:「名札」は“箱”を超えるものではない

「名札」や「束縛」という比喩は、
実行環境や抽象化の観点を説明する一つの手段に過ぎません。

しかし、それを「箱より優れている」と主張するのは誤りです。
比喩はあくまで教育のためのツールであり、
言語設計の本質はメモリ・参照・評価戦略の選択にあります。

実務的な観点から見れば、
「箱モデル+参照の理解」で十分に事足り、
束縛モデルは特定分野での理論的・実験的意義を持つに留まります。


最後に:比喩の目的を取り違えない

変数を「箱」と呼ぶのも、「名札」と呼ぶのも、
プログラミングという抽象世界を理解するための足がかりに過ぎません。

重要なのは「どの比喩を使うか」ではなく、
その比喩がどの抽象化層を説明しているのかを意識することです。

プログラミング教育において本当に求められるのは、
比喩をめぐる正しさの議論ではなく、
学習者が言語の階層構造(値 → 参照 → 束縛)を自然に昇っていけるように導くこと
なのかもしれません。


この文章は、ChatGPTとの共同作業により作られています。

「staticおじさん」現象とは何だったのか

オブジェクト指向再考 連載目次

―「クソコード」批判に姿を変えたネット社会の同調圧力―

前回、「クソコード」という言葉がバズワード化していることについて触れました。
今回は、少し歴史をさかのぼって「staticおじさん」現象を振り返りながら、
“コードの正しさ”がどのようにして社会的な信仰に変わっていったのかを考えてみたいと思います。


「staticおじさん」というレッテル

「staticおじさん」という言葉を聞いたことがある方も多いでしょう。
2010年代初頭、オブジェクト指向が声高に唱えられていた時代、
C言語的な書き方――たとえばstatic関数やグローバル変数――を使い続けるベテランエンジニアを
揶揄するために生まれたネットスラングです。

当時、オブジェクト指向は“正しい設計思想”として教育現場でも現場でも広まり、
メソッド呼び出しこそが美徳であり、static(関数)を使うことは“時代遅れ”だとされていました。
しかし今振り返ると、彼ら(staticおじさん)が使っていた手法の多くは、
単なる無知ではなく、実務的な妥協や効率化の知恵だったように思えます。
プロジェクトの制約、納期、パフォーマンス、チーム構成――
そうした現実の制約を理解したうえで“あえて”選ばれた手段であったことも少なくありません。


「信仰」としてのオブジェクト指向

オブジェクト指向の時代には、「staticを使うのは悪」という単純な善悪構造が形成されました。
その背景には、エンジニア教育や資格試験、ネット上の設計論争などを通じて
「OOPこそが唯一の正解」とされる雰囲気があったのです。

この構図は宗教的です。
人々は“正しい設計”を信じることで安心し、
他者の異なるやり方を排除することで、自分の信仰を強化していきました。
それは技術的な議論というよりも、
「自分が正しい側にいる」という心理的な安定を得るための行為でもあったのかもしれません。


繰り返される「同調の構造」

staticおじさんを笑っていた人々が、
いま“クソコード狩り”をしているとしたら、
それは同じ構造の繰り返しです。

かつて“staticおじさん”を嘲笑していた人々の中には、
いま現場を離れてしまった人も少なくありません。
壮大なオブジェクト指向の実験の果てに、
多くのプロジェクトが炎上し、多くの人が疲弊しました。
その中で「失敗の原因は古いやり方にある」として、
staticを使う人々が“悪役”として語られたのです。

時が流れ、オブジェクト指向の幻想が薄れた今、
新たな“敵”として登場したのが「クソコード」でした。
コードの品質を語ること自体は重要ですが、
他者のコードを嘲笑し、排除しようとするその姿勢は、
十年前の“staticおじさん狩り”とまったく同じ構造をしています。

人を揶揄する文化は定期的に生まれ、やがて消えていきます。
そのたびに誰かが傷つき、誰も幸福にはならない。
そこに残るのは、「正しさ」を求めすぎた社会の冷たさだけです。


「正解主義」とどう向き合うか

この現象の根には、「正解を求める文化」があります。
多くのエンジニアは、「何が正しいのか」を明確にしたいと願います。
しかし、プログラミングという行為の本質は、
常に“仮の正解”を探りながら進む試行錯誤の連続にあります。

「わからないままにしておく」ことを許せない風潮は、
議論を貧しくし、思考を停止させます。
結果として、「○○はクソ」「△△は正義」という単純化が進み、
技術が信仰へと変わっていくのです。


次回予告

次回は、こうした「正解主義」の文化がどのようにしてプログラミング教育や職場文化に根を下ろしていったのかを掘り下げ、
「正しさ」と「自由な思考」のバランスを考えてみたいと思います。


この文章は、ChatGPTとの共同作業により作られています。

ハイパーバイザが実行されていないため仮想マシンが起動できません。(ページファイルなしも疑え)

かなり久々のWindowsネタですが、ちょっとはまって他に記述がないので書いておきます。
要はタイトル通りなのですが、ページファイルなしのときにHyper-Vがおかしくなるという話です。

Windows Server 2019をセットアップしHyper-Vをインストールして、業務用のソフトが入ったWindows10をゲストとして動かしていたのですが、ある時
『ハイパーバイザが実行されていないため仮想マシンが起動できません。』
と言われててゲストマシンが起動しなくなりました。

BIOSの設定で仮想環境の設定(Intel-VTやらAMDのSVM)をONにする
ハイパーバイザが起動できない「アプリケーションでエラーが発生しました」

やら

BIOSのいわゆるDEPサポート(Intel XD, AMD NXビット)
Windows Server 2008 または Windows Server 2008 R2 のエラー: ハイパーバイザーが実行されていないため、仮想マシンを起動できませんでした

を確認したのですがきちんと設定さていました。

で何気に色々チェックをしましたところページファイルをなしにしていました。ので元に戻す(OS管理にする)と無事に起動しました。

第72回富士登山競争

昨年の5月に英検・TOEICを受けて以来、主に勉強のスケジュールが合わずに受験を控えていまして、来年の1月は英検の受験をしたいと思っているところです。という訳で書くネタがないなーと思っていたのですが、そういえば富士登山競争に出たので、それでも書こうかと思います。

通訳案内士として昨年から富士山に登っているのですが、登山中はもちろん登山ガイドさんが同行するのであくまでも通訳で登るのですが、それでも基本的な体力は必要だろうと、レースにエントリーしました。

レースは山頂コースと5合目コースがあるのですが、山頂コースはいきなりエントリーができずに5合目コースをエントリーしました。

コースは吉田市役所から浅間神社から馬返しに入るいわゆる吉田ルートで5合目を目指します。馬返し迄は約12Kmそこから5合目までは約4Kmになります。制限時間があり、馬返しまでは2時間、5合目までは3時間半でゴールしなければなりません。

今年は、馬返しまでが1時間55分、5合目が3時間50分で、残念ながら既定時間内にゴールできませんでした。来年は3時間半を切るようにしたいですが、一番手っ取り早い方法は体重を今から10Kg程落とすことのようで、来年に向けて体重を落としたいと思います。

<2025年10月追記>どうも、この記事のアクセス数が多いので現状報告ですが、コロナ過の影響でこの年を最後に富士登山をやっていません。コロナ後も富士登山はまだですね。歳をとったので体力的にきついものがありますが、還暦までにはもう一度挑戦しようかとも思います。