今回、カードゲームを作ってみて繰り返しの部分で

bool game_end;//ゲーム終了か

//カード
bool card_list[4][13];

なぜか、勝手にgame_endが書き換えられるということでデバッガで追いかけていると
添字が１個多くてメモリ破壊してました。

for(knd=0;knd<4;knd++){
for(num=0;num<14;num++){
//カード使用してないフラグを立てる
card_list[knd][num]=false;
}
}
配列の不正アクセスで配列の上に書いてあるので関係ないと思ってました。
怖いですね、これが大規模とかで起きると怖いですね、定数とかで書き変えておいたほうがいいと思いました。

配列のループミスはたまにやりますよね。
しかも気がつきづらいw

最近はループでまわしたりする者やあとから配列の数が、かわる者は定数にするように心がけてます。
エラーが出てくれるときはいいんですがね…でないときがね…

お互い気を付けましょうね、

この程度のバグなら、きちんと書いていれば、規模がどうあれ、致命的な事にはならないと思いますよ。

マジックナンバーをマクロ定義するのは常套手段です。　これは、人はタイプミスするものである。　１４や１３など、例えタイプミスしてもコンパイラがトラップできない。
そして変更が生じた時に修正が面倒である。　というのが主な理由です。


ちなみに、こういう、プログラムが正常な場合取りうる事は理論的にあり得ない数値（異常値）の場合は、ａｓｓｅｒｔ を仕掛けておくのが大人のマナーですよ。


可能な限り、バグやエラーはコンパイル時に分かるようにするべきです。
それが無理な場合は、ａｓｓｅｒｔ で対処します。
それでも無理な場合は、近くのコンビニで気合いを購入します。


ちなみに、if(hoge == 10) を if(10 == hoge) と書くようにするのは大嫌いです。

パコネコさん、コメントありがとうございます。
次の日記のブラックジャックのプログラムなのですが、
テストみたいな感じで定数化はしてませんでした。
テストでも定数化するように気をつけないと。

へろりんさん、コメントありがとうございます。
可能な限り、バグやエラーはコンパイル時に分かるようにするべきです。
＞＞これってプログラム設計から始まることですよね？

ａｓｓｅｒｔですか、テスト以前に考えてませんでした。
判定する部分より前に置きますね。

コンビニで気合いって売ってるんですか、すごいですね。私は栄養ドリンクくらいならあると思いますね。

私もif(10 == hoge)と書くようにするのは嫌いです。バグとか関係なく。