LASSIC Media らしくメディア

導入：名前の衝突という問題

プログラムを書いていると、変数名や関数名を何度も付ける場面に出くわします。個人が短いスクリプトを書くだけなら大きな問題にはなりにくいものの、規模が大きくなり複数人・複数のファイルで開発するようになると、同じ名前が別々の場所で使われる状況が自然と増えていくものです。

ここでいう「スコープ」は、プロジェクトの作業範囲やOAuth認証の権限範囲といった意味ではありません。プログラムの中で名前がどこまで見える・参照できるかという、言語共通の基礎概念を指す言葉です。本記事では、この名前の可視範囲（スコープ）と、名前の衝突を防ぐための区分けの仕組み（名前空間）に絞って整理していきます。

名前の扱いが無秩序なままだと、次のような事態が起こりやすくなるでしょう。

• 別の担当者が用意した変数を、意図せず上書きしてしまう
• 同じ名前の関数が複数箇所に存在し、どちらが呼ばれているのか分かりにくくなる
• ライブラリを追加した際に、既存のコードと関数名がぶつかりエラーになる

こうした混乱を防ぐために、多くのプログラミング言語は二つの仕組みを用意しています。一つは、名前が有効な範囲を区切る「スコープ」です。もう一つは、関連する名前をまとめて分類し、同じ名前でも所属が違えば区別できるようにする「名前空間」になります。両者は似た言葉に見えますが、扱っている軸が異なるものです。この違いを押さえておくと、コードの設計やレビューの際に見るべきポイントが整理しやすくなるでしょう。

実際の開発現場では、こうした名前の衝突がバグとして表面化するまで気づかれないことも珍しくありません。例えば、あるモジュールで用意した変数が、別のモジュールが読み込まれたタイミングで書き換えられ、思わぬ値になってしまう不具合です。原因を調べると、実は二つの箇所で同じ変数名を使っていた、というケースは開発現場でしばしば耳にする話でしょう。スコープと名前空間は、こうした問題が起きる前に、名前の役割と所属を整理しておくための仕組みだといえます。

スコープとは

スコープとは、ある変数や関数などの名前が、コードのどの範囲から参照できるかを定めるものです。名前は宣言された場所によって、見える範囲がおおむね決まります。

代表的なスコープには、次のような種類があります。

擬似コードで示すと、次のようなイメージです。

function outer {
  let x = 10;          // outer関数のローカル変数

  function inner {
    let y = 20;         // inner関数のローカル変数
    if (x > 5) {
      console.log(x, y); // xもyも参照できる
    }
  }

  console.log(y);        // エラー：yはinnerの外からは見えない
}

この例では、変数yはinner関数の内部で宣言されているため、外側のouter関数からは参照できません。関数の中で宣言した変数は、その関数が終わると役目を終え、外部に影響を及ぼさないというのがローカルスコープの基本的な考え方です。反対に、ファイルの一番外側で宣言した変数はグローバルスコープに属し、プログラムのどこからでも参照できる状態になります。

ブロックスコープは、関数よりもさらに細かい単位でスコープを区切る仕組みです。近年の多くの言語では、if文やループの中括弧の内部だけで有効な変数を宣言できるようになっており、同じ関数内であっても処理のかたまりごとに名前を閉じ込められるようになっています。

また、同じ名前の変数が複数の階層に存在する場合、内側から外側に向かって順に探していき、最初に見つかった宣言が使われるという名前解決の順序も、多くの言語で共通しています。内側のスコープに宣言がなければ、一つ外側のスコープを確認し、それでも見つからなければさらに外側へとさかのぼっていく流れです。この探索の順序を意識しておくと、どの変数が実際に参照されているのかを追いやすくなるでしょう。

スコープの利点と注意

変数の見える範囲をローカルに閉じておくことには、いくつかの利点があります。

• 影響範囲を限定できる：ある関数の中だけで完結する変数であれば、その関数を読むだけで挙動を把握しやすくなります。他の箇所への影響を気にせず修正できる範囲が広がるでしょう。
• デバッグの手がかりが絞りやすい：不具合が起きたときに、疑うべき範囲がその関数やブロックの内部に限定されるため、原因を追いやすくなります。
• 名前の使い回しがしやすくなる：別々の関数であれば、同じ変数名（例えばiやcountなど）を気兼ねなく使えます。

一方で、グローバルスコープに変数を置きすぎると、次第に見通しが悪くなっていきます。どの処理がその変数を読み書きしているのかが追いにくくなり、一部を修正しただけのつもりが、離れた箇所の挙動に影響してしまうことがあるためです。規模の大きなプログラムほど、グローバル変数への依存が増えると変更の影響範囲を把握しづらくなる傾向があります。

あわせて押さえておきたい落とし穴として、次のようなものが挙げられます。

• 変数の巻き上げ（ホイスティング）：一部の言語では、変数の宣言が実際に書いた位置より前にあるかのように扱われる場合があります。宣言前に参照してもエラーにならず、想定と異なる値（未定義など）が返ってくることがあるため、混乱のもとになりやすい挙動です。
• シャドーイング：内側のスコープで外側と同じ名前の変数を宣言すると、内側では外側の変数が一時的に隠れてしまいます。同じ名前のつもりで書いたコードが、実は別の変数を指していたという勘違いにつながりやすい点に注意が必要でしょう。

こうした挙動は言語ごとに細部が異なるため、使用している言語の仕様を踏まえて確認しておくことをおすすめします。ホイスティングやシャドーイングは、書いた本人が気づきにくい種類の不具合につながりやすく、レビューの際にも見落とされがちな観点です。共通して言えるのは、変数はできるだけ狭いスコープに閉じ、グローバルな領域に置く名前は必要最小限にとどめておくという考え方が、保守のしやすさにつながりやすいということです。

名前空間とは

名前空間とは、関連する名前をひとまとまりのグループとして区切り、別のグループとの間で名前が衝突しないようにする仕組みです。スコープが「コードの入れ子構造」に沿って名前の可視範囲を決めるのに対し、名前空間は「論理的な所属」によって名前を分類するという違いがあります。

名前空間という考え方が登場する以前は、名前の衝突を避けるために、関数名の先頭に長い接頭辞を付けて回避するという工夫がよく取られていました。ただし、こうした接頭辞に頼るやり方は、名前が長くなりコードが読みにくくなるうえ、接頭辞自体が別のライブラリと重なってしまう可能性も残ります。名前空間は、こうした接頭辞頼みの工夫を言語やモジュールの機能として整理し、所属をより明確に扱えるようにしたものと捉えることができるでしょう。

多くの言語では、モジュールやパッケージ、あるいは専用のnamespaceという構文を通じて、この仕組みを実現しています。呼び方は言語によって異なりますが、狙いはおおむね共通しています。

これらの仕組みに共通しているのは、名前を「グループ」という単位でまとめ、グループの外に対しては所属を明示しないと参照できないようにする、あるいは所属を明示することで区別できるようにするという発想です。

• あるチームやライブラリが定義した名前を、他のチームやライブラリの名前と分けて管理する
• 同じ名前であっても、所属するグループが異なれば別物として扱う
• 名前を参照する際に、所属を明示することで、どちらの定義を指しているかを明確にする

例えば、名前空間Aとして定義したfooという関数と、名前空間Bとして定義した別のfooという関数があったとします。それぞれ単独では同名でも、参照するときは次のように所属を含めて書けるため、区別がつく形になります。

A.foo;  // 名前空間Aに属するfoo
B.foo;  // 名前空間Bに属するfoo（Aのfooとは別の関数）

スコープと名前空間は、どちらも名前の混乱を防ぐための仕組みですが、役割の軸が異なります。整理すると、次のような違いになります。

両者は対立する概念ではなく、組み合わさって働くものです。関数の内部ではスコープによって変数が閉じられ、モジュールや外部ライブラリとの間では名前空間によって衝突が避けられる、という二段構えになっているとイメージすると分かりやすいでしょう。

実務での関わり

スコープと名前空間の考え方は、規模の大きな開発や複数人が関わるプロジェクト、外部ライブラリを取り込む場面で、特に意識する価値が出てきます。関わる人数やコード量が増えるほど、同じ名前が別々の場所で偶然に使われる可能性も高まっていくためです。

実務では、次のような場面で名前空間の設計が関わってきます。

• 機能ごとにモジュールを分割し、それぞれの内部で使う名前を外部から見えないようにする設計
• 社内共通のライブラリや外部パッケージを取り込む際に、既存のコードと名前が衝突しないよう調整する作業
• 命名規約（プレフィックスの付け方やモジュール名の粒度など）を定め、チーム全体で名前の付け方をそろえておく取り組み

発注やコードレビューの場面では、次のような観点を確認しておくと、後々の手戻りを減らしやすくなります。

• 不要な変数や関数がグローバルスコープに置かれ、グローバルな領域を汚染していないか
• モジュールやパッケージの分割が、機能のまとまりに沿った形になっているか
• 外部ライブラリを追加する際に、名前の衝突が起きないか事前に確認する運用になっているか
• 命名規約が定められ、チーム内で共有・徹底されているか

図にすると、同じ名前fooであっても、所属する名前空間が異なれば別物として扱われる様子は、次のようになります。

ライブラリを積極的に活用する開発ほど、こうした名前の整理が土台になります。設計段階でモジュールの区切り方や命名規約を決めておくと、後から機能を追加したり、外部のパッケージを取り込んだりする際にも、名前の衝突に悩まされにくくなるでしょう。

反対に、こうした整理が後回しにされたまま開発が進むと、機能追加のたびにグローバルな領域へ変数や関数を継ぎ足す形になりやすく、後から手を入れる担当者が影響範囲を把握しにくいコードになっていく傾向があります。設計の初期段階でモジュール分割の方針を決めておくことは、将来の機能追加や担当者の交代を見据えた投資といえるものです。

まとめ

スコープは、変数や関数といった名前がコードのどの範囲から見えるかを決める仕組みです。グローバルスコープ、ローカルスコープ、ブロックスコープといった単位で、名前の可視範囲が整理されています。一方の名前空間は、関連する名前をグループとしてまとめ、別のグループとの間で名前が衝突しないようにする仕組みで、モジュールやパッケージといった論理的な区分によって実現されるものです。

両者は似た言葉でありながら、決めている軸が異なります。スコープはコードの入れ子構造に沿った可視範囲を、名前空間は論理的な所属による区分を担っています。この違いを理解しておくと、変数をどこまで狭く閉じるべきか、モジュールをどう分割すべきかといった設計判断がしやすくなるはずです。規模の大きな開発や複数人での開発、外部ライブラリの活用が増えるほど、この基礎を押さえておく価値は高まっていくでしょう。

相談するメリット

「グローバル変数が増えすぎて影響範囲が把握しにくい」「モジュール分割や命名規約を見直したいが、社内だけでは着手しづらい」といったお悩みがあれば、LASSICにご相談ください。

LASSICでは、ニアショア開発体制を活かし、モジュール設計や命名規約の整備、保守しやすいコード構造への見直しまで、受託開発の一環として対応しています。既存システムのスコープ・名前空間の使われ方を棚卸しするところから、あわせてご相談いただけます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

サービス詳細・お問い合わせはこちら

出典

• Wikipedia「名前空間」
• Wikipedia「スコープ (プログラミング)」
• MDN Web Docs 用語集「スコープ (Scope)」

Tweet