- 締切済み
バグ修正箇所が多すぎて、しかも修正しても直らなくて
バグ修正箇所が多すぎて、しかも修正しても直らなくて困ってます。みなさんならこんな時どうしてますか? プログラミングの文法などを勉強したので、最近Androidアプリの開発に向けてプログラムの作成に取り掛かっています。 とはいえ、教科書に載っているソースコードをそのままEclipseに書き写しているだけです。 それなのに訂正箇所がたくさん出て困っています。(例は下に記載します) 周りにプログラミングが得意な友人がいるわけでもなく、自力でも解決できずに困っています。 毎度、知恵袋などで質問するという手もあるのかもしれませんが、もし皆様が同じような立場にある場合どのような解決手段をとりますか? こういうケースに対応したサイト?みたいなのがあればおしえていただきたいです。 どんな意見でも歓迎します。 是非よろしくお願いします。 例; 1)ソースコード通りに記載しています(これに関しては何度も見直しております) 2)訂正内容通りに訂正したのに、また訂正が入る? 2に関してですが、 『この行で見つかった複数の注釈: - 要素タイプ "RelativeLayout" の後に属性指定 ">" ま たは "/>" のいずれかがなければなりません。 - エラー: Error parsing XML: not well-formed 』 という文章がでて、『/>』で記載し直したのにまたエラーがでる・・・といった具合です。 構文としては <TextView ・ ・ 中略 ・ ・ /> といった感じです。
- みんなの回答 (10)
- 専門家の回答
みんなの回答
- bajutsu
- ベストアンサー率20% (139/693)
>1)ソースコード通りに記載しています(これに関しては何度も見直しております) じゃあ、きっと教科書が間違っているんだね。 >2)訂正内容通りに訂正したのに、また訂正が入る? それやったら、だんだん「ソースコード通り」じゃなくなっていくと思いますけど。 純粋に、基礎が足りてないだけだと思う。 何が原因で、そのエラーがでているのかを本質的に理解できてない。 エラーだと言われている部分が、実はエラーの原因じゃないってことはよくある。 いくら丸写しだからって、いきなり大きいプログラムの ソースを写してもダメ。 少しずつ大きくしていくべき。 そのまま数をこなしていけば、いつかはコツがつかめるんじゃないかな?
- pi31415
- ベストアンサー率0% (0/0)
Eclipse を使ったこともアプリ開発もしたことがありませんが、ご参考までに。 どこに問題があるのか特定する一つの方法は、なるべくソースコードをシンプルな短い形にしてコンパイルすることです。ある程度ソースを理解する必要はありますが、うまく行ったら少しずつコードを追加して行きます。万能のデバッグ方法ではありませんが、問題箇所の特定には有効な場合があります。 教科書丸写しもひとつの有効な勉強方法だと思います。仮に教科書丸写しだから動くはず、という前提に立てば、コーディング「以外」の部分に原因がある場合もあります。例えば「Eclipseの設定が不適切」「全角空白がソースコードに紛れていた」「エディタの設定が見たこともない文字コードになっていた」「指定したライブラリがない」… そうした目に見えない部分が悪さをしている場合もあります。致命的っぽいエラーの原因が、すごく下らないことだったりします。
- Tacosan
- ベストアンサー率23% (3656/15482)
ちなみに, なんだけど, 意外と 「ソースコード通りに記載しています(これに関しては何度も見直しております)」 は役に立たない. 「自分が打ち間違えているかもしれない」と思いながら入力する人は少ないわけで, つまりたいていの人は「自分は正しく打ち込んだ」と心のどこかで思っちゃうわけです. で, この「思い込み」によるバイアスがかかるので, 見つけられないときは何回見直しても見つけられない. 実際, 「自分では何度見てもわからないのに他人が見ると一瞬で気づく」なんてのは珍しいことじゃない.
- Tasuke22
- ベストアンサー率33% (1799/5383)
調子に乗って何千行かのコードを一挙に書き、完璧だ! と思い、コンパイルしたら数えきれないエラーが出て冷や汗がドッと出る経験は、ま、一度ではないです。 だってさ、書いたコードの行数より、エラー数の方が多いって…がっかり この場合、エラーは複合しています。 まず幾つかの単純なエラーを探し出し、同じパターンの箇所を探してざっと修正してからまたエラーを出し直します。 一気に自分で良いと思っていたのに違っていたので、今度はコンパイラの手を何度も借ります。 戦う相手は、自分の考え違いと知識不足です。 ここで自分の欠点が明示されている訳ですから、それを潰すことにより完璧な自分を目指す訳です。 例え納期が迫っている大仕事でも、自分が理解してコントロールする以外に完成は無いです。 理解とは今まで自分の知らなかった世界観を感じ取ることです。 悪いですが、教科書を写したのにとか、何度もエラーが出るとか、いうのは「愚痴・泣き言」の部類です。 それによって自分が知らなかったことがまた一つ分かった、という喜びにならないと進歩はないでしょう。
- wormhole
- ベストアンサー率28% (1626/5665)
修正してもなおらない、ということは適切に対処できてない(修正したつもりになってるだけ)って事では? 何が問題なのかきちんと把握してますか? まずはそれができないことには適切な対処も行えません。 また何らかのエラーメッセージが出るバグはまだ比較的簡単な方です。 難しいバグはエラーメッセージなんて出ません。
- nosamajin
- ベストアンサー率23% (80/342)
他の回答者さんも仰ってますが、まずは自分で検証してみるのです。 その際、全体から問題点を検証するのでなく、エラーが出てきた部分の前後から問題点を探すのです。 それでもどうしても見つからない、分からないのならこういう質問サイトで問うのは恥ずかしいことでも、間違いでもありません。 ただし、質問するにはちゃんとルールがあります。 ・ソースは長くてもきちんと全文を載せる、途中を端折らない。 ソースの途中が抜けてると、抜けた部分に原因があった場合に答えに困ります。 ・エラーが出る場合は具体的なエラーメッセージ、コードも併せて載せる エラーのメッセージから要因を推測できる場合もあります。 ・どうしたいのか、どういう問題点があるのかを具体的に記す 曖昧なままだと判断ができない場合があります。 ・プログラミング言語と開発環境、どういうものを相手にしているかをを記す 言語がハッキリしないと答えられないケースがあります。 また、開発環境に問題がある場合もあるのでそれも併せて記した方が親切というものです。 これらがないと質問を答えるにしても答えられなかったり、質問者の希望から外れた答えが返ってくることになりかねません。 それにこれらは質問をする側としての最低限のマナーです。
- kmee
- ベストアンサー率55% (1857/3366)
> 1)ソースコード通りに記載しています(これに関しては何度も見直しております) 残念ですが、それだけではだめなケースもあります。 誤植があって、プログラムが間違っている場合もあります。 文法の勉強をしたのなら、そのプログラムが間違っていないか、御自身で調べてください。 「ソースコード通りに記載したかどうか」 ではなく、 「自分が理解している文法と照らし合わせて、今ここにあるプログラムが正しいかどうか」 を考えます。 「正しいはず」と思って見ると、間違いを見落すものです。 Error parsing XML: not well-formed ということは、文法が間違っている可能性が高いです。 やりがちなのが 半角で書かないといけないところを全角で書いてしまう 大文字小文字の間違い 単純なスペルミス 余計なスペースがある/必要なスペースが無い タグや引用符の対応が取れていない
- TooManyBugs
- ベストアンサー率27% (1472/5321)
バグ云々の前に勉強のしかたが最悪ですね。 文法を学習する前にプログラミングの作法(サクホウ、サホウの両方)を学ぶべきですね。 教科書のコピーでは動くわけ無いし身にもつきません。
- k_kota
- ベストアンサー率19% (434/2186)
まず、理解して下さい。 コピーすれば動く、っていうのであれば、そもそも出来上がってるものを使えばいいんです。 何をしてるのか、何がおかしいのかを理解すれば、自分で解決できるようになります。 もしくはもっと小さい問題から始めて下さい。 基本ができてからじゃないですかね。
- maiko0318
- ベストアンサー率21% (1483/6969)
エラーが出ると言いながら、<中略>されてしまったのでは協力のしようがないんだけど。