【学習】プロパティはいつ書くべきか：最後でOKな理由

はじめに

構造の作り方（namespace → class → method）が分かったとき、次にこんな疑問が出てきます。

「プロパティはいつ書けばいい？」

書き始めのタイミングで悩む人が多いです。結論から言います。

プロパティは「クラス宣言のいちばん上から先に並べる」のではなく、メソッドの中身を書いていく過程で足していけば大丈夫です。

「最後」とは、namespace やメソッドの枠よりあとという意味です。実際には、メソッドのブロック内を書いていて、まだ存在しないデータ名を使った瞬間にコンパイラがエラーを出すので、そのタイミングでプロパティ（やフィールド）を1つ追加する、という進め方で問題ありません。

「プロパティから書く」とどうなるか

書き始めにプロパティから書こうとすると、こうなります。

class Player
{
    public int hp;        // これは int でいいの？
    public string name;   // stringでいい？
    public float speed;   // floatかdoubleか迷う
    public bool isAlive;  // これ必要？
    // ...

ここで止まります。

「型は何にすればいいの？」
「public にしていいの？」
「全部 private にすべき？」
「どのプロパティが必要なの？」

これらの疑問はすべて、処理を書いてみないと分からないことです。

なぜプロパティが後でいいのか

学習の順番には理由があります。

1. 構造（クラスとメソッドの枠）
      ↓
2. 処理（メソッドの中身・ロジック）
      ↓
3. データ（プロパティ・フィールド）

処理を書いてから「このデータが必要だ」と気づくのが自然な流れです。

プロパティは処理の中で「このデータを保持したい」という必要性が生まれてから追加するものです。

メソッドを書いていくとエラーになる（そのタイミングで追加する）

メソッドの中で hp や Name など、まだクラスに宣言していない名前を書くと、赤い波線やコンパイルエラーになります。

class Player
{
    void TakeDamage(int damage)
    {
        hp -= damage;   // この時点では hp が無い → エラー
    }
}

これは失敗ではなく、手順どおりに進んでいるときに必ず起きることです。「先に全部のプロパティを決めてから処理を書く」のではなく、処理の文脈で必要になった名前が、エラーとして見えるので、その場でプロパティ（またはフィールド）を追加すればよい、という流れです。

class Player
{
    int hp = 100;   // ← エラーを見てから追加
    void TakeDamage(int damage)
    {
        hp -= damage;
    }
}

IntelliSense で「フィールドを生成」などの候補が出る環境なら、それを使っても構いません。大切なのは、処理の中身を書く過程で、必要になったタイミングでデータを足すことです。

この「その場で直す」感覚は、第4回：エラーが出たらどうするかで扱う空クラスや参照と同じ発想につながります。

正しい順番の例

例えば、Add メソッドを実装する場合を考えます。

ステップ①：クラスとメソッドの枠だけ作る

class Sample
{
    void Run()
    {
    }
    int Add(int a, int b)
    {
        return a + b;
    }
}

この段階ではプロパティ（フィールド）はありません。Add メソッドは引数を受け取って返すだけです。

ステップ②：処理を書く

class Sample
{
    void Run()
    {
        int result = Add(10, 20);
        Console.WriteLine(result);
    }
    int Add(int a, int b)
    {
        return a + b;
    }
}

Run メソッドの中で Add を呼び、結果を result に受けています。これで動きます。

ステップ③：必要になったらプロパティを追加する

もし「計算結果を毎回使いたい」という必要性が生まれたら、そこで初めてフィールドを追加します。

class Sample
{
    int total;  // ← 必要だと分かってから追加
    void Run()
    {
        total = Add(10, 20);
        Console.WriteLine(total);
    }
    int Add(int a, int b)
    {
        return a + b;
    }
}

必要になったから追加したという流れです。

NGパターン：「とりあえず public」

学習中によくある失敗パターンです。

class Player
{
    public int hp = 100;       // とりあえず
    public string name = "";   // とりあえず
    public float speed = 5f;   // とりあえず
    public bool isAlive = true; // とりあえず
    public void Move() { }
    public void TakeDamage(int damage) { }
}

「とりあえず」で書いたプロパティが増えると：

どのプロパティが使われているか分からない
処理の流れが追えなくなる
エラーの原因が特定しにくくなる

プロパティを後回しにする3つの理由

理由	説明
必要なものが分からないから	処理を書かないと何が必要か判断できない
型の選択で悩まなくていいから	使う場面が決まってから型を決める方が正確
処理の理解が先だから	「何をするか」を理解してから「何を持つか」を決める
メソッドを書くとエラーが教えてくれるから	未宣言の名前を使った行でエラーになるので、そのタイミングで1つずつ足せばよい

まとめ

プロパティは「必要になったら追加する」のが正しい順番（クラス先頭をいっぺんに埋める必要はない）
メソッド内でまだない名前を使うとエラーになるが、そのタイミングでデータを追加すればよい
書き始めの段階で「何を持つべきか」は分からない
処理を書いてから必要なデータが見えてくる
「とりあえず public」で全部書くと処理の理解が妨げられる

メソッドの中で「まだない名前」を使うとエラーになるのと同様に、存在しないクラスを参照したり、型が合わなかったりするときもエラーが出ます。どれも「その場で形を足して潰す」考え方でつながっています。次の記事で対処の共通パターンをまとめます。

→ 第4回：エラーが出たらどうするか：その場で潰す技術

シリーズ一覧

回	タイトル
ハブ	C#の写経がつらい理由と、正しい学習手順【完全版】
第1回	なぜC#の写経はつらいのか：赤い波線の正体
第2回	正しいC#の書き方：namespace→class→methodの順番
第3回（この記事）	プロパティはいつ書くべきか：最後でOKな理由
第4回	エラーが出たらどうするか：その場で潰す技術
第5回	複数クラスで止まる理由：依存関係を理解する
第6回	Unityで同じことが起きる理由：置き場所という考え方
第7回	プログラミングは構造で考える：写経を超えた先にあるもの