状態チェックが長くなってきたので、メソッド化して読みやすくした話

アプリのUIや表示ロジックを書く中で、
「特定の状態のときだけ値を非表示にする」といった処理ってよくありますよね。

たとえばこんなコード：

if (AppStateMachine.CurrentState == AppState.WaitingForCalibration)
{
    text1 = "-----";
    text2 = "-----";
}

これ自体はシンプルで悪くないんですが、
状態が増えてくるとだんだん見づらくなってきます…。

---

🔀 状態が増えるとどうなるか

たとえば非表示にしたい状態が3つあったとします。するとこうなります：

if (AppStateMachine.CurrentState == AppState.WaitingForCalibration
 || AppStateMachine.CurrentState == AppState.Initializing
 || AppStateMachine.CurrentState == AppState.NoData)
{
    text1 = "-----";
    text2 = "-----";
}

• 条件が長い
• 何をしたいのか読み取りづらい
• ちょっとした変更でも複数行にまたがる

こういうの、メンテが地味に面倒なんですよね…。

---

✅ 解決策：判定をメソッドにまとめる

そこで、表示制御の意図を明確にするために、状態チェックをメソッドに切り出しました。

if (AppStateMachine.ShouldHideMeasurementValues())
{
    text1 = "-----";
    text2 = "-----";
}

中身はこんな感じ：

public static bool ShouldHideMeasurementValues()
{
    return _currentState == AppState.WaitingForCalibration
        || _currentState == AppState.Initializing
        || _currentState == AppState.NoData;
}

これでだいぶスッキリ。
「なぜこのときに非表示にするのか？」が関数名から伝わるようになりました。

---

🔍 書き方の使い分けについて

もちろん、直接状態を比較するほうが読みやすい場面もあります。

if (AppStateMachine.CurrentState == AppState.WaitingForCalibration)

この書き方は、「状態そのものを知りたいとき」にはむしろ分かりやすいです。

---

💡 状態比較とメソッド化、どう使い分ける？

書き方	向いてる場面
CurrentState == AppState.Xxx	状態を明示的に扱いたい処理（状態遷移、分岐など）
ShouldHideMeasurementValues()	表示処理やUIなど、意図や目的が重要なとき

---

✍ まとめ

• 状態が少ないうちは CurrentState == Xxx でOK
• 条件が増えたり、「なにをしたいのか」を伝えたいならメソッド化がおすすめ
• 書き方は使い分け！どちらも場面によって有効

---

📒 おまけ：関数名の付け方

関数名は目的ベースで書くと読みやすいです：

• ShouldHideMeasurementValues() ← 今回の例
• IsReadyToAnalyze()
• NeedsAttention() などなど

「何をしたいのか？」「今どういう状態なのか？」がコードを読んだ瞬間に伝わる名前を目指すと吉です 👦

---

🙌 おわりに

コードって、「動く」だけじゃなくて「読める」も大事ですよね。

今回みたいにちょっとした工夫で、未来の自分やチームの仲間が助かることも多いので、
同じような悩みがある方の参考になればうれしいです！