エラーの出ないコードのバグ取り

VisualStuioなどで、エラーとでるのは、あくまでも、構文上の間違いのみです。

変数名が、違う、無い、括弧のつじつまが合わない、関数が無い・・・

などなど。

実際にプログラムがきちんと、動作するかどうかは、それぞれのプログラムの１行１行にかかれた、動作が期待通りになっているか？ということが重要です。
そうゆう意味で、「どのようにバグ取りを？」という質問に対しての、基本の答えは、

プログラム１行１行が、期待した動作をしているかどうか確認

という事をしていく作業となります。

変数の範囲は正しいか、範囲外の値になったときの処理はできているか？
判定文は間違えていないか？

などなど。

よって、if文などで分岐が入れば、それだけ確認するパターンが増えてきますし、ユーザー入力などがある場合には、あらゆる入力値の想定をする必要がでてきます。

さて、実際に現場ではこんな事をいちいちコードを眺めていては仕事が終わらないので（でも、昔はラインプリンタで出力したコードを蛍光ペンで塗って、カバレッジ検査とかしてたな、、、また、ある程度のプログラムは書ける想定という事で）ある程度をまとまったブロックとして、テストを行うことが普通です。
いわゆる、テストケースを作成して、限定部分のコードが正しく動作しているかどうかを確認します。単体テストとか現場ではいったりします。いわゆる部品が正しく動作することの確認です。
部品がきちんと動作するなら、それを組み立てても（プログラム全体）きちんと、動作するよね（って実際にはそんなに簡単ではないですが）って事で、組み立てて全体のテスト（現場では結合テストと申します）を行っていきます。

とは言う物の、主様は、プロではないので、上記のようなテストケースを作成して云々は無理でしょうから、、、

迷路プログラムとの事で、どこか、どのようにおかしいのかわかりませんが、
まずは、おかしくなる原因となりそうな部分の、コードを、動作確認することとなるでしょう。

コンパイラのエラーでは発見できませんので、コードと睨めっこして、デバッグトレースとか、ステップ実行などの手順をつかって、予想外の分岐をしていないか、とか、想定外の値を持っていないかなどを、確認していくのが、最初では。

こんにちは。

そのような時は、自分で作ったつもりの動作と実際のプログラムの動作に相違があります。
その相違の原因を見つけることがポイントです。

お手軽なデバッグとしては、プログラムの要所要所にブレーク・ポイントを設置して、そこで停止した時に各変数の値を確認し、自分の想定と一致しているかどうか見ます。
一致していないポイントが見つかったら、そこより前に実行した部分に「相違の原因」がある筈ですね。
それより前に実行されるところにブレーク・ポイントを設置して同じことを繰り返すことで、「相違の原因」を見つけることができるケースが多いです。

>やはり1行1行確認していくのがバグ取りに必要なんですね。
少しはしょったやり方だと・・・
問題が出ている箇所（ファイル、関数、クラスなど）にブレークポイントをかける。
変数等を確認してそこでおかしければ、範囲を半分にして再度ブレークポイントをかけて検証する。
そこで問題があれば、そこ以前で問題があるので後半は確認しなくてよい。
そこまでが正常ならば、そこ以降に問題があるので前半は確認しなくてよい。
再度確認範囲を半分にして同様に行う。
・・・ようは２分検索の要領ですｄ＾＾