【ITニュース解説】Beyond `i` and `tmp`: Writing Code for Humans, Inspired by Grace Hopper

プログラミングの世界には、誰もが当たり前のように使っている「お約束」がいくつか存在する。例えば、ループのカウンターにはi, j, kを使い、一時的な値にはtmpやvalを用いるといったものだ。これらはコードを共通言語のように感じさせ、親しみやすくするための工夫として広まってきた。しかし、このような「昔からこうやってきたから」という慣習が、かえってコードの本当の意図を隠してしまうことがある。私たちが求めているはずの「読みやすさ」を、慣習が犠牲にしてしまうとしたらどうだろうか。 この問題意識は決して新しいものではない。プログラミング言語をより使いやすくすることに大きく貢献したパイオニアであるグレース・ホッパー提督は、この点に関して重要な原則を提唱した。「私たちは、人間が理解するためにコードを書き、機械が実行するのはあくまで副次的なことである」と。このホッパーの視点を通して、一般的な慣習を見直し、Pythonを使って、単に慣習に従うだけでなく、本質的に明確なコードを書く方法を探っていく。

まず、ループ変数について考える。一般的な慣習では、for i in range(len(users)):のように、ループのカウンターにi, j, kを使う。これは多くのプログラマーにとって見慣れた書き方だが、読み手には「iとは何だろう？ ああ、インデックスのことか」という心の翻訳作業を強いることになる。私たちが本当に知りたいのは、そのインデックスが指す「ユーザー」そのものだ。ホッパーの原則に従うと、変数はそのデータ構造における役割ではなく、コードの論理における役割に基づいて命名すべきである。例えば、for user in users:と書けば、変数のuserが「ユーザーの一人」であることを直接的に示し、コードの意図が明確になる。これによって、読み手は余計な思考の負担を負うことなく、ループが「ユーザーを処理している」ことを即座に理解できる。もしどうしてもインデックスが必要な場合は、for index, user in enumerate(users):のようにenumerateを使うことで、インデックスと要素の両方を意味のある名前で同時に扱えるようになる。これなら、コードは単なる数字のカウントではなく、ユーザーを処理するという本来の目的に集中できる。

次に、「一時的な」変数についてだ。慣習として、短い期間だけ使われる変数にはtmp, temp, valといった名前がよく使われる。例えば、tmp = calculate_total(items)のように使われる場合だ。しかし、tmpという名前は「一時的なものである」という情報しか伝えず、その変数がなぜ存在し、何を表しているのかについては全く教えてくれない。これは一種のブラックボックスだ。ホッパーの原則では、どんなに短命な変数であっても、必ず目的があると考え、その名前はその目的を明らかにすべきだとされる。例えば、subtotal = calculate_total(items)のようにすれば、subtotalという名前はtmpと同じくらい簡潔でありながら、意味を持つ。「これは割引が適用される前の合計金額である」という情報を読み手に伝え、計算の論理が自己説明的になる。これにより、コードを読んだ人は、その変数が計算の中でどのような役割を果たすのかをすぐに理解できるようになる。

三つ目に、ハンガリアン記法の弊害だ。以前の慣習として、list_employeesやdict_configのように、変数名のプレフィックス（接頭辞）にその変数の型（リスト、辞書など）を付ける「ハンガリアン記法」というものがあった。これは、現代の統合開発環境（IDE）のように型ヒントや型チェックが発達していなかった時代や、静的型付け言語において、変数の型を明確にするために有効な手法だった。しかし、Pythonのような動的型付け言語では、このような記法は単にノイズを増やすだけになりがちだ。現代のIDEは変数の型を教えてくれるし、コードの文脈からも型は推測できることが多い。変数名は、その変数の「型」ではなく、「目的」を伝えるべきだ。ホッパーの原則は、ツールとチームメイトを信頼し、型ではなく概念で名前を付けることを推奨する。例えば、employees = get_employees()というコードがあれば、get_employees()という関数名や、その後のemployees[0]のような使い方から、employeesが従業員のリストであることは容易に推測できる。これによりコードはよりすっきりとし、データ構造の実装詳細ではなく、「従業員を管理する」というビジネスロジックに焦点が当てられるようになる。

四つ目に、ブーリアン変数の落とし穴についてだ。ブーリアン（真偽値）変数には、is_availableやhas_permissionのように、is, has, shouldといったプレフィックスを付ける慣習がある。これは比較的良い慣習とされている。しかし、さらに一歩進めることで、コードの明確さを高めることができる。本当の落とし穴は、なぜその条件が設定されているのかを説明するコメントが必要になるような、複雑な条件式を直接if文に書いてしまうことだ。ホッパーの原則は、コードをまるで普通の文章のように読めるように書くことを提唱する。複雑な条件ロジックは、分かりやすい名前のブーリアン変数に抽出することで、読みやすさが飛躍的に向上する。例えば、product_is_available = product.in_stock and not product.discontinued、user_can_purchase = user.has_permission and user.is_verifiedと記述すれば、その後のif product_is_available and user_can_purchase:という条件文は、まるで完璧な英文のように自然に読めるようになる。さらに重要なのは、各条件が満たされる理由が明確になり、バグの発生を防ぎ、コードの理解を格段に容易にすることである。

グレース・ホッパーの功績は、「私たちは常にこのようにやってきたから」という言葉が、あらゆる言語において最も危険なフレーズであることを私たちに教えてくれる。プログラミングにおける慣習は、便利な出発点となるが、それはコードの明確さの「しもべ」であるべきであり、その「主人」であってはならない。プログラミングにおける真の、そして最も重要な「お約束」は、次にそのコードを読むであろう人間のために書くことだ。たとえそれが半年後の自分自身であったとしても、その人が容易に理解できるコードを書くべきである。だから次にiやtmpを使おうとする時は、一度立ち止まって自問してみてほしい。「この変数は、私が解決しようとしている現実世界の問題において、実際には何を表しているのだろうか？」「この条件文は、まるで簡単な文章のように読めるだろうか？」「次にコードを読む開発者は、このコードが『何を』しているかだけでなく、『なぜ』そうしているのかも、同じくらい簡単に理解できるだろうか？」単に「動くコード」を書くだけでは十分ではない。自分自身で意図を説明してくれるようなコードを書くこと。それこそが真のクリーンコードの精神であり、ホッパー提督にふさわしい基準なのだ。