ケアレスミスの割合が高いのか低いのは判らないのですが、低い方が良いのは自明です。
大山鳴動してねずみ一匹のように、潰したバグは"."と","のTypoだったり、 end if の位置間違いだったという話は山とあります。
DBがらみでは,文字型を数値型として比較して該当データを引っ張らないことに気づかず、泥沼にはまることもよく聞く話。
例
月次イベントを定義しているテーブルがあります。
1月:初出式
1月:消防訓練
1月:従業員定期健診
2月:株主総会
:::
このテーブルの月の部分を integer項目でとっています
月次イベントテーブルを引用するのは 行事スケジュールテーブルでします。
引用する側の元データの日付欄はyyyyMMdd 形式(文字列)で定義しています。
流れとして、元データyyyyMMdd のMMの部分を抜き出し、月次イベントの月とリンクすることになります。
一方は文字型,一方はInt型なのですが、そこを見落として
sqlを substring(元データ,5,2)=月次イベント.月
と書いて結果として、データを引っ張らないという騒ぎが、FAQのように定期的に起こったりします。(1～9月の時)
sqlを cast(substring(元データ,5,2) as int)=月次イベント.月
とすれば処理は可能なのですが、バグ予防にはなっいません。
月次イベント の月は、呼ぶ側の月の値は "01"から"12"の形式であると判っているならば Intにするのはよくないと考えるのです。
文字列で 2桁で0埋めして格納しておけば、アプリ側で数値変換の処理が不要になります。
テストケースも少なくなっていいことだらけと思うのです。「char項目よりinteger項目のほうが効率が良い」と宣わる人もいますが、些細な差です。それが原因でバグッタほうが遥かにコストがかかります。
ソースを記述するとでバグが増えます。 バグのないプログラムはコードを書かないことです。
ソースの記述を少なくする項目設計やDB設計は大事なことだと考えてています。