Q&A
Unityに限らないと思いますが、設計（やること）が固まっていないのにいきなりコードを書くからです。最初に紙にやることを手で書いて羅列して、整理してからコーディングにかかってはいかがですか。
プログラミングをしていて
条件文の条件が増えると脳内でうまく処理できずに手が止まってしまう時があり
とりあえず手を動かして書いたコードで動いても、なんで動いているのか理解できないといった状況になることがあります。
C#
1 void Update() 2 { 3 inputL = Input.GetAxisRaw("L_Trigger") != 0 ? true : false; 4 inputR = Input.GetAxisRaw("R_Trigger") != 0 ? true : false; 5 6 if (inputL == true && inputR == false) 7 { 8 pushTri = true; 9 } 10 if (inputR == true && inputL == false) 11 { 12 pushTri = true; 13 } 14 }
C#
1 void Move() 2 { 3 float leftTri = Input.GetAxisRaw("L_Trigger") * Time.fixedDeltaTime; 4 float rightTri = Input.GetAxisRaw("R_Trigger") * Time.fixedDeltaTime; 5 float speed = moveSpeed * Time.fixedDeltaTime; 6 7 float bikeSpeed = Mathf.Abs(rb.velocity.x);//絶対値を返す, 速度制限の値 8 9 if (leftTri != 0 && pushTri == true && bikeSpeed < maxSpeed) 10 { 11 rb.AddForce(transform.forward * speed, ForceMode.Acceleration); 12 StartCoroutine("PushOn"); 13 } 14 15 if (rightTri != 0 && pushTri == true && bikeSpeed < maxSpeed) 16 { 17 rb.AddForce(transform.forward * speed, ForceMode.Acceleration); 18 StartCoroutine("PushOn"); 19 }
簡単に考える方法や、頭の中で整理する方法とかあれば教えてほしいです。
case文や構文を使うこともありますが、やはり脳内で理解できていないので
混乱してやる気が無くなることがあります。
面倒ですがコメントをちゃんと書くというのも割と大事です。
しばらく経つと何をやっていたのか忘れてしまうってこともありますからね。
多分、後で読んだら分からないという問題よりも、そもそも最初に書く時点で混乱して手が停まる、と言う悩みなのでしょうね。日本語のコメントを先に書くことで、ある程度設計を表すこともできますが、冗長になりがちです。
> とりあえず手を動かして
とりあえずと言う時点で間違いなのでは、と言う気がします。一般的にはやることが脳内で決まってから手を動かします。コード上の試行錯誤はあるかもしれませんが。
とりあえずコピペをやめたらいいと思います。完全に理解してないものを適当にいじりながら積み重ねると、そのうち重ねられなくなります。
コピペファースト（＜そんな単語は無いが）な開発方法だったとしたら、確かにもう思考の順番が違いますね。
条件文の条件を増やさないようにするのも1つの手だと思います
Move()なら
float bikeSpeed = Mathf.Abs(rb.velocity.x);
if (bikeSpeed >= maxSpeed) { return; } <= この時点でreturnさせれば下の条件式から1つ条件を消せます
なるほど、とりあえずコード書く前に一度紙や表で設計してみることにします
ありがとうございました
回答7件
0
条件分岐が錯綜状態になっていてアタマが追いつかないときは「表引き」が使えないか考えてみるのがいいんじゃないかと思います。
こう云うイメージ
| 変数1 | 変数2 | 変数3 | 呼び出す処理 |
|---|---|---|---|
| True | True | 0以上 | func_a() |
| True | True | 0未満 | func_b() |
| True | False | 0以上 | func_a() |
| True | False | 0未満 | func_a() |
| False | True | 0以上 | func_b() |
| False | True | 0未満 | func_c() |
| False | False | 0以上 | func_d() |
| False | False | 0未満 | func_a() |
呼び出す先を関数にまとめておいて呼び出す形にすれば、割と簡単にコードに落とせそうな気がします。
投稿2020/10/22 07:37
総合スコア13671
0
正直どんな言葉を期待しているのかわかりませんが、こういう質問をされる方は「あなたには向いてないからプログラミングやめたら？」という答えを貰ったら納得してやめるんでしょうか？
条件文の条件が増えると脳内でうまく処理できずに手が止まってしまう時があり
じゃあちゃんと仕様書を書きましょう、としか言えません。
仕様的に複雑な条件はどうやったって複雑でしかないので、ベン図を書いたりマトリックス表を作ったりして「脳内で処理」だけに頼らないようにすれば良いだけです。
なんで脳内で全部できると思ってるんですか？
投稿2020/10/22 07:05
総合スコア8949
無為に攻撃的な表現をするなら回答をしないほうが良いと思います.
私も回答というよりも批判な気がしています
すごいプログラマーがいて、理路整然としゃべっているようにコーディングされる方が
いらっしゃります。 あとからコードを読み返すのもわかりやすいし、そもそも矛盾とか
バグが入りにくいです。
どうすればしゃべるようにコーディングできるかは回答できないのですが、
訓練なんだと思います（ごめんなさい回答になってなくて） 頑張ってください
そういうの面倒なんで絡んでこないでください。
持論を展開したいならツイッターでやって。
>Oyakappaさん
分かりやすいコーディングができることと、仕様書を書くことは相反しません。またその人が如何に優れたプログラマーだろうと、100万行を超える大規模なシステムで、仕様書も書かずに喋るようにプログラミングしていたことが分かった日には私は会社を辞める覚悟をすると思います。
0
ベストアンサー
コード書きながら考えるのではなく、考えてからコードを書くこと
せめてフローチャートくらいは手書きレベルでいいので書いておくべきですね
設計せずにいきなりコード書くということ、まず現場ではありえませんし、
現場じゃないからいきなりコード書いていいとか言うわけではないです。
チュートリアルとかやってるならまだいいとして、そうでないなら考えるのが先。
Howはあと。What/Whyが先。
投稿2020/10/22 07:09
総合スコア80852
0
テスト書くと良いですよ。
投稿2020/10/22 07:53
退会済みユーザー
総合スコア0
0
C#は専門外ではありますが、
プログラミング全般で言える話だと思うので、回答です。
簡単に考える方法や、頭の中で整理する方法とかあれば教えてほしいです。
王道やセオリーといったものは存在するかもしれないですが、
最終的には、自分に合った方法を自分で探すしかないと言えるかと思います。
というわけで、独断と偏見で回答いたします。
どこを通っているか、を、実行しながら確認する
プログラミングをやる上では、これを把握していくことが、
ほとんどを占めるかと思います。
どこを通っているかさえ分かれば、全体把握も自然とできますし、
通ってる箇所でエラーなりデータの不整合が起きているのであれば、
そこで対応できるからです。
なので、エラーなどが出た場合、
コンソール（言語や環境別で存在する、ログの表示）をうまく使い、真っ先に、どこで起きているのか、原因なのかを突き止めます。
とにかく、頭で考える前に実行してみる
ぶっちゃけ、プロでも、ソースコードを目で見てその場で理解ってのは正直難しいです。
なので、頭でパンクするくらいなら、迷わず実行してください。
でないと、いつまでもわからないままで進まなくなります。
なので、上記同様、ログを使って、データや箇所を表示する前提で、
まずはとにかく実行しましょう。
基本の構文・メソッドなどを覚えていく。知らないものは調べる
基本構文やメソッドは、最初から全部なんては把握できないと思うので、
出たとこででもいいので、調べて覚えましょう。
なぜかというと、ユーザー定義構文なのか、組み込みなのか、の見極めがスムーズになるからです。
それができれば、けっこうコードの把握が非常に進めやすくなります。
以上、三点が大事かと思います。
頭の中で全部理解しようとせず、とにかく、実行しながら理解していきましょう。
投稿2020/10/22 07:16
総合スコア9528
0
if (inputL == true && inputR == false)
if (inputL && ! inputR)
でいいやん
あとはとにかく何をどうしてるのか、をコメントで書いとく、ぐらいですねー
投稿2020/10/22 06:59
編集2020/10/22 07:04
総合スコア87784
低評価はしていませんが、気になったので。
> if (inputL && ! inputR)
質問中に変数宣言がないため、該当の変数がnull許容型の場合、
「== true」や「== false」のような判定は必要です。
質問だけでは判断できないため、不適切かと。
どちらも != 0 で bool になっている上に過剰に bool に変換しているので大丈夫です。あと MonoBehavior が bool に暗黙変換される話だと思いますが、bool に変換されるので == true や == false は不要です。また null 許容体は Nullable<T> を指します。
低評価の理由はこの回答が的外れだからというのと、リファクタリング自体雑だからですね。
> どちらも != 0 で bool になっている上に過剰に bool に変換しているので大丈夫です
「bool? inputL」のような宣言がされている可能性を想定しています。
null許容値型、Nullable<bool>の場合、boolの値は質問中のように代入できます。
代入はできますが、型としてはboolでないため、ifの際、そのままでは使用できません。
なので、変数宣言が見えない状況においては、要不要は判断できないという意味です。
質問文を読んでください。
> inputL = Input.GetAxisRaw("L_Trigger") != 0 ? true : false;
どう見ても bool です。bool? の可能性はありません。
> どう見ても bool です。bool? の可能性はありません。
すみません、質問中のコードは完全ではなく、
「inputL」、「inputR」、「pushTri」の変数宣言がないため、型は不明であるという認識です。
該当箇所のコードだけでは「bool」もしくは「bool?」のどちらであるか、また、
どちらでもないのか判断できません。
仮に「bool inputL」や「var inputL」となっているのであれば、boolであるというのは理解できます。
該当の変数の型が、boolであるとどこから判断したのでしょうか。
例として以下のような場合、「== true」は必要です。
class Hoge
{
bool? inputL = null;
void Update()
{
inputL = true;
if (inputL == true)
{
}
}
}
Input.GetAxisRaw("L_Trigger") が 0 でなければ true で、0 ならば false です。
null の可能性はありません。
> Input.GetAxisRaw("L_Trigger") が 0 でなければ true で、0 ならば false です。
null の可能性はありません。
inputLに代入される値が「true/false」のどちらかであることは理解しております。
そのことと、inputLの型がboolであることは別であると思いますがいかがでしょうか。
先ほどのコメントにも書きましたが「bool? inputL = null;」という宣言がされていた場合、
boolの値でで代入できても、型としてはboolではないため、「true/false/null」による判定が必要です。
変数として「true/false」しか入っていないことが明らかであっても、暗黙的な変換は行われないため、判定が必要です。
「== true」や「== false」が不要、とするならば「inputL」の型がboolである必要がありますが、
質問中からはそれが私は判断できませんでした。
「inputLの型がboolである」とどのように判断されましたか。
これはサンプルコードでしょう？
それならば、書き込みのみできる読み取り不可のプロパティの可能性など、コンパイルできないコードの可能性も疑わなくてはいけませんね。クラスの宣言がないので、構造体かもしれませんし、ローカル関数かもしれません。その場合、呼び出しされない可能性もありますね。Input がどんなオブジェクトかも示されていないし、GetAxisRaw も int を返すとは限りません。そうすると、この判定自体無意味なので全部削除した方が良いことになります。
> これはサンプルコードでしょう？
はい、その通りです。
わからない箇所であるため、不要であるか判断できない、という主張です。
一番最初のコメントとしても、少なくともこの修正であれば「inputL」や「inputR」がbool型(もしくは「true/false」演算子のオーバーロード)であればという前提があるべきだと思っております。
使われ方から恐らくbool型だろうと、思っているので、低評価はしておりません。
：追記
「あとはとにかく何をどうしてるのか、をコメントで書いとく、ぐらいですねー」という、
編集後のコメントのため、その段階で、一応質問には答えていると判断しました。
ではたとえば条件文が増えた時に頭がパンクしてしまう主旨を説明するためのサンプルコードで次のような式が成り立つ可能性も考えなければならないということですか？
if (inputL == true && inputL == 1)
> ではたとえば条件文が増えた時に頭がパンクしてしまう主旨を説明するためのサンプルコードで次のような式が成り立つ可能性も考えなければならないということですか？
>
> if (inputL == true && inputL == 1)
すみません、どこからその式が出てきたのか、理解できませんでした。
理解できませんでしたが、回答に必要であると思うなら考えなければならないのではないでしょうか。
こちらの回答であれば、「== true」や「== false」は不要という内容が含まれているため、
これらの比較が必要である可能性は考慮すべきではないでしょうか。
「あとはとにかく何をどうしてるのか、をコメントで書いとく、ぐらいですねー」という内容だけでしたら、
考える必要はないでしょう。
サンプルコードなど話は逸れましたが、Zuishinさまの仰られる通り、
「どう見ても bool です。bool? の可能性はありません。」ということであれば、
「== true」や「== false」は不要というのは理解できます。
私は変数宣言がないため、boolの値が代入可能な型である、ということしかわかりませんでした。
bool?など、暗黙的な変換がされるためboolの値が代入可能かつ、
「== true」や「== false」が必要ということもあると考えました。
必要ですか。架空のサンプルに質問者が本題に関係ない罠をそこまで仕込んでいると考えないといけないとは大変ですね。
> 必要ですか。架空のサンプルにそこまでの罠が潜んでいると考えないといけないとは大変ですね。
最初のコメントの通りですが、低評価はせず、気になったから指摘した内容です。
もし、何らかのC#言語仕様や、Unityの独自仕様により、
「== true」や「== false」は不要であることが明らかである、というのであれば、
指摘自体が誤りであるため、教えていただければ幸いです。
架空のサンプルについてそこまで考えていない、というのであれば、失礼いたしました。
ここに bool? を仕込む理由がありますか？
> ここに bool? を仕込む理由がありますか？
質問の内容からは判断できないと思いますが。
それが「== true」や「== false」は不要であることが明らかであることにつながりますか？
サンプル、つまりたとえ話でここに本題と全く無関係な bool? を仕込む可能性まで考えなければならないと言うことですよね？
> サンプル、つまりたとえ話でここに本題と全く無関係な bool? を仕込む可能性まで考えなければならないと言うことですよね？
本題と全く無関係ですので、こちらの質問の回答において、触れる必要も考える必要もないとは思います。
なので低評価はせず、気になった点として「必要だから書いてある」という可能性についてコメントしました。
bool? を仕込む理由など、話は逸れましたが、
何らかの仕様により、「== true」や「== false」は不要であることが明らかであるならば、
指摘自体が誤りであるため、教えていただければ幸いです。
bool であれば不要です。bool? を仕込む意味がわかりません。
> bool であれば不要です。bool? を仕込む意味がわかりません。
はい、boolであれば不要なのはわかります。
仕込む意味については、仕込む理由同様に、質問の内容からは判断できないです。
何らかの仕様により、「== true」や「== false」は不要であることが明らかであるならば、
指摘自体が誤りであるため、教えていただければと思っておりました。
「必要だから書いてある」という可能性について、
理由・意味がわからないから、無視するのであれば、
私の指摘自体が無視されるものであると思います。
お手間を取らせてしまい申し訳ございませんでした。
質問の内容から確定できない事項は山のようにあり、私が昨日書いた式もその一つです。
サンプルであれば、特別な記述もなく、本題にも関係なく省略されている部分は、最も一般的なものを想定するのが適当であろうと思います。
> if (inputL && ! inputR)
>
> でいいやん
この記述の本質は、bool に関して過剰な記述が多いので、整理すればわかりやすくなるのではないかという提案だと思います。
それに関しては、私も同じように思いました。
ただ、それだけではおっしゃる通り言葉が足りない中途半端な提案なので役に立つ回答までになっておらず、評価しておりません。
しかし、そこで bool? どうこういう話になるのは、それもいささか過剰な想定で、質問や回答の本質から外れたものと思います。
元はと言えば私が MonoBehavior の話と勘違いしたことから始まったことではありますが、的外れな回答の更に的外れな所への突っ込みに思えます。
もしこれがサンプルではなく実際に問題を抱えたコードであったなら、リファクタリングの具体的なアドバイスとして詳細を確かめることなくコードをいじるのは不適当というのは、まさにおっしゃる通りと同意します。実装を尋ね、コンパイルエラーを確認し、出力を確かめるべきでしょう。
> サンプルであれば、特別な記述もなく、本題にも関係なく省略されている部分は、最も一般的なものを想定するのが適当であろうと思います。
はい、仰る通りです。
「条件文が増えた時に脳がパンクしてしまう」という質問からすれば、
「必要だから書いてある」という可能性を指摘すること自体が過剰な想定で、
本質から外れておりました。
ありがとうございました。
あなたの回答
tips
プレビュー
