- ベストアンサー
C#のswitch文で見やすく、編集しやすく、ミスを減らすコツはありますか？
- C#のswitch文での改行や一括編集に悩んでいる場合、以下の方法が有効です。
- 1. 外部関数を利用して一括編集する 2. 数字ではなく文字列を利用する 3. 引数の数を制限して外部関数を作成する
- これらの方法を組み合わせることで、見やすく、編集しやすく、ミスを減らすことができます。また、自分の経験や設計に基づいた書き方をすることも助けになります。
- その他（プログラミング・開発）
- 回答数3
- ありがとう数5
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
>> 1switch内に50程のcase～break文を並べています。 これはダメでしょう。どう工夫しても分かりにくいと思います。 >>もっと解かり易く、編集し易く、ミスを起こし難い書き方って あるでしょうか？ 50程のcase文が必要になるロジックというか、アルゴリズムを見直す必要があると思えます。 私の場合は、以下のようなことを考えます。 これは別にC#でなくてもいいわけですけどね。 １）複雑な入力パターン、さまざまな組み合わせが考えられるデータがあるとき ・構文解析で対応。（Yacc/Lexみたいなの）。 ・ロジックでなく、データ区分と処理の対応テーブルで記述。 ２）以前の状態が、次の状態に影響して処理が変わるとき ・状態遷移図を作成し、ステートマシンで対応。 ３）処理・機能が多すぎるとき ・関数だけでなく、クラスとかプロジェクトで分割する なお、作成するプログラムの処理が複雑になると、テストが大変になります。 C#にある単体テストのテンプレートでテストプロジェクトを作成したほうがいいと思います。
その他の回答 (2)
- chachaboxx
- ベストアンサー率23% (412/1777)
少なくとも変数毎とかでcase文を分けるのは難しいのでしょうか？それが無理なら配列に落とし込むとか…。 やはり具体例がないと検討が難しいです。
お礼
＞配列に落とし込むとか…。 最初はたった１つの機能追加だったはずが、 亜種、応用、更なる追加改良高機能版と増えてあれよあれよと・・。 後で見返すと配列を使って短く纏められる部分が数割あると気付くも 個別機能も散在してて、それまで纏める設計をして新たなコードを書くと 余計混乱しそうだからそのまんま なんて事もありました。 (設計ミスのバグが怖く。) もっと先を見通して設計できる様になると もっとお利巧な解かり易い書き方ができるのかもしれません。 私はあまり頭が良くないので機能を細分化すると 何か別の追加をする時にどう考えてもマズい所に記述し始める事があるので 機能単位で強引に１つに纏めて作ってしまうのも こうなってしまっている原因なんだと気付かされました。 何か所もこうなっている現状は身から出た錆ですね。 具体例を示せなくてすみません。ご回答ありがとうございます。
- oboroxx
- ベストアンサー率40% (317/792)
具体的にどういう書き方をしているかを載せると回答がつきやすいかと思います。
お礼
case～break文が50前後になってる部分がもう４つ程あり それぞれ役割や特徴が違うので あらゆるケースでもっとお利巧な書き方が出来たならと思いましたが やはり載せた方が回答しやすいのですね。すみません。 ご助言ありがとうございます。
お礼
専門的な情報、ありがとうございます、 今回は ＞さまざまな組み合わせが考えられるデータがあるとき これなのですが、 頂いた助言がアマチュアであまり頭も良くない私には難しく 少し調べて情報を読んでみたのですが、理解にかなり日数を要しそうです。 ３重条件程度のif文ですらすぐ設計ミスを起こし始める私は 全体の流れを極力単純になる様に作ってミスを予防してしまい、 こうした ＞どう工夫しても分かりにくいと思います。 的なcase文だらけになってしまっています。（既に色々な形式で４か所程。） 考えてみると、機能追加が組み合わせ爆発的な事を起こし始めて とりあえず作って動作テストして上手く動いて見返してみると、 1/3くらいは配列で処理できたんじゃないかと気づく事もあります。 動かしてみて結果が芳しくなくて 旧版を復旧用に残しつつ、新版を追加し亜種を追加しなんて事もあるので。 もっと先を見通した設計ができていればこうはならなかったのかも。 ともあれアート系の一方通行、一過的な組み合わせの多さなので 後を引く影響するデータは殆どないので何とかなりそうです。 色々な情報を教えて下さってありがとうございます。 プロの方々は設計段階からとてもスマートなんだろうと感じました。