適切な変数の定義位置とは

Question

～～何らかのコードブロック
...
..
.
int a;
～～aを使う何らかのコードブロック

int a;
～～何らかのコードブロック（aは使用しない）
...
..
.
～～aを使う何らかのコードブロック

このコードの例では適切な変数の定義位置は、
変数aが使用されるすぐ前（つまり上のコード）らしいのですが、
なぜですか？変数のスコープが大きいと読み手が不安になると
本で読んだのですが理由がわかりません。

使われているところだけ読み取れると思うのですが・・・

Answer 1

何らかのコードブロック（aは使用しない）

そのコードを書いたときは『aは使用しない』という約束が守られたとしても、
開発に携わる他人、および未来の自分がその約束に従う保証はありません。

『ともすれば、aが書き換えられているのではないか？』
なにかバグが発生した際に、毎回そのような心配をしなければいけないのです。

ただし

aが定数ならば、const修飾をすることで上記の懸念を回避することが出来ます。
プログラムの内容によっては見通しが良くなる場合もあるでしょう。

const int a = 42;

～～何らかのコードブロック（aは使用できるが、書き換えられない）

～～aを使う何らかのコードブロック

本当に見通しが良くなるかどうかは、状況に依ります。
そのときは気軽にコーディングできたとしても、それが読みやすいコードになるとは限りませんので。

Answer 2

不安になるかどうかは人それぞれですが、大きな理由は二つあると思います。

一つは、読む側の理由として、変数の定義位置と使う位置が離れていると可読性が下がるということです。
関数の頭で定義されている変数がどこでどう使われているのかは、いちいちソースを追っていかないと判りませんし(結局使われていなかったりすることも)、ある場所で使われている変数がどのように定義されているか確認するにはソースを戻らなければなりません。途中でスコープが変わって同じ名前で異なる定義をしている可能性も考えられます。

もう一つは、書く側の理由として、使う場所で定義するのが自然だからです。
関数を実装する際、使う変数を最初に決めてからコードを書き始める、などということはまずしません。コードを書きながら使う変数を考えます。そうなると、自然と使う場所で定義したくなります。もし関数の頭でまとめて定義しなければならないとなると、コードを書きながら変数が必要になるたびにいちいち関数の頭に戻って定義を追加し、また元の場所に戻って続きを書く、ということになりますが、それはとても面倒ですし思考が中断されることにもなります。

Answer 3

一つのスコープに変数が何十とか何百個もある、という状況を想定してみましょう。
いろいろな問題が発生することがわかると思います。

• どれを使えば良いのかわからない
• どうしてここではこれを、あっちではあれを使っているのかわからない
• どの時点でどれがどんな値になっているかわからない
• 名前が似ているとかで間違った変数を使ってしまう
• ある変数がどこで必要なのかわかりづらくなる（ごちゃごちゃっと値を格納して、ン百行下で一回だけ使うとか、嫌らしいパターンもありそう・・・）

まだまだあると思いますが、端的に言えばプログラムを正確に把握するコストがとても高くなってしまいます。

プログラム全体で使うものは上の方に定義しておいて、特定の処理で使ったら用済みになる変数はスコープの中に定義することで、各変数の意図も多少はっきりしますし、トラブルの温床も潰せます。

Answer 4

こんにちは。

変数のスコープが大きいと読み手が不安になると

本で読んだのですが理由がわかりません。

例えば、その変数aを使う処理を修正する事になり、aをdouble型へ変更する必要があると仮定します。
そのaが当該処理だけでのみ使われているのであれば、安心して変更できます。
変数aのスコープを必要最小限にしておけば、その狭いスコープ内だけを確認すれば当該処理のみで使われていることを確認できるので手間が少ないです。
また、無駄にスコープが広いと変数定義（変数名を考えて定義文を書く）をサボって流用してしまうこともあります。この場合、doubleへ変更したいところと流用してしまったところがあり、流用した方は変更したくありません。結果、改造する方の変数aを新たに別途定義し、当該処理のaを使っているコードを全て修正しないといけません。「無駄な」手間がかかります。（意外に頻発するのですよ、これ。）

ですので、私は次のようなコードを書くことも多いです。

int main()
{
    {
        int a=aの最初の値を決定する関数();
        // aを使う処理
    }
}

慣れるとずいぶん気が楽になりますよ。

他にも、aのスコープが広いと、間違って変更したり参照したりすることも発生し得ます。コンパイラが検出できないバグの発生確率が上がるという意味です。スコープが狭ければ、スコープ外で間違ってアクセスしてもコンパイラがエラーにしますので事前にチェックできます。これによりプログラムの信頼性が上がります。

とはいえ、大抵の場合はデバッグ時点で検出できると思います。でも、たまたまテストにも通ってしまうと、もうその変数aを触ることができません。長い期間の間にはそうやって「ゴミ」が溜まっていきます。「この変数はゴミと思うけど再テストの手間を考えると削除できない」って嫌なものです。

Answer 5

推測ですが、コードのメンテナンス性を上げる
という目的でこのような話になっているのでは?

つまり、変数定義は最初にまとめてやっておき、
定義箇所を探すという労力や勘違いを少なくする、と。

ただ、昨今は関数化して短いルーチンの組み合わせで
処理を実現することが多いと思いますので、
そんなに気にすることもないんじゃないのかなあ。
(スコープ的な意味で)

もちろん、システムの作り次第でどのような方法が
ベストなのかは変わってきますよね。