07/03/19 20:17:50
>>839
素朴な疑問だが、
「入れる前」でチェックしているのなら、
「入れた後」でチェックする意味あるの？
想定外の経路(直接Accessとかでレコード作成とか)が無い限りは
普通Input側で整合性取れば後は無視しない？
いや、マジで素朴な疑問なんだよ。
俺なら想定外の経路を許可する事をしないモノで。。。
891:仕様書無しさん
07/03/19 20:20:19
想定外の経路を許可してなくてもどっかのバカが入れるんだよ
仕様書にきちっと書いてあっても間違った試験データ投入してうだうだと言ってくる
892:仕様書無しさん
07/03/19 20:21:50
>>890
updateのときとか？
# 入れるときに入るかなぁ？
入力側と出力側を別人が作っている場合は、
まあ表示前にチェックってのはアリと言えばアリ。
893:仕様書無しさん
07/03/19 21:46:41
>>890
19000000はNULLのことです、とか言われたらどうする？
894:仕様書無しさん
07/03/19 21:51:56
>>890
そういう考えが「サニタイズすればいい」ってところに通じるんじゃないのか？
想定外のデータが嫌なら、DBに制約つけるなりなんなりしてくれ。
そうすれば、構造が変わらない限りは平気になる。
895:仕様書無しさん
07/03/19 22:43:03
Dim 消しフラグ
Dim 消し消しフラグ
（中略）
'------------------------------------
' 小細工
'------------------------------------
End Sub
896:仕様書無しさん
07/03/19 23:20:18
勝手にCSVつくってインポートしたがる奴はどこの世界にもいるもんだよ
897:仕様書無しさん
07/03/20 00:50:49
それはダメなのか？
898:仕様書無しさん
07/03/20 16:32:48
>>897
勝手に作ったCSVデータを勝手にインポートした挙句データの整合性が取れなくなり、
ソフトに不具合が発生したらデータ作成した本人（もしくは指示した人間）が
「データベースが壊れた！バグだ！！修正しる！！！」
と騒いで無料サポートをさせるってパターンが『よく』あるから
>>896のグチになるわけだ。
その対策が>>890みたいな意見になるわけだけど、そうすると今度は
「データを入れたいのに受け付けない！バグだ！！修正しる！！！」となって
最初に戻る。
899:898
07/03/20 16:37:15
ｽﾏｿ、上の890は894の間違い
900:仕様書無しさん
07/03/20 17:30:20
「勝手に作ったCSV」なんて恐ろしいものの入力許すなよ。
入力チェック側も「カンマ区切りのテキスト」しか想定してない場合が多いんだから…orz
もちろん何のエスケープもなしで。
901:仕様書無しさん
07/03/20 18:52:20
>>900
importの話だよ
902:仕様書無しさん
07/03/20 19:42:09
>>898
そんな馬鹿の相手はしないに限る。
903:８９０
07/03/20 19:45:01
なんか、色々有るんね。
みんなの苦労が良くわかったよ。
おれは幸せなんだね。
ごめんね＞みんな
904:仕様書無しさん
07/03/21 04:48:34
その時出来る対処はその時やっておいた方があとで
記憶を取り戻してからやるより結果的に時間の節約になるから
やったほうがいいね。
やる時間がないなら、せめて警告コメントくらいは入れておくもんだよ。
905:仕様書無しさん
07/03/21 08:04:20
catch(Exception e) {
// Exceptionをcatchしたらthrowする
throw e;
}
906:仕様書無しさん
07/03/21 08:30:54
逆に入力チェック完璧って前提だから、出力の際にチェックしなくていいっていうのは
どういう仕事なのか気になる。
907:仕様書無しさん
07/03/21 09:46:47
余裕の無いプロジェクトだとありがち。
908:仕様書無しさん
07/03/21 09:47:56
え？
出力時にチェックいるの?
909:仕様書無しさん
07/03/21 10:22:20
常識的に考えて入力チェックしたものを出力時再度チェックする必要ないぞ？
910:仕様書無しさん
07/03/21 10:30:24
どういうシステムなのかにもよるが
それは認識が甘いと言わざるを得ない
911:仕様書無しさん
07/03/21 10:36:38
入力時に正しいデータだったのに、出力するときに不正なデータになってたら、ただのバグだと思うが。。。
912:仕様書無しさん
07/03/21 10:40:10
>>911
つまり、ただのバグを検知できる、という指摘もありだな。
913:仕様書無しさん
07/03/21 10:41:25
>>911みたいな人ってswitchのcaseが仕様上の選択肢すべてを
網羅しているときにはdefaultを書かないんだろうな。
914:仕様書無しさん
07/03/21 10:50:49
いや、バグの検出と、入力のチェックを区別つけないで議論してるヤツとかダメだろ。。。
915:仕様書無しさん
07/03/21 10:52:45
defaultに到達したらバグだろう普通にｗ
その場合バグ解析コードだろdefaultは
916:仕様書無しさん
07/03/21 10:55:26
2chでよくいる、「バグがあっても動いてしまうコード」をいい書き方だって固く信じてるやつって、
バグ検出と入力時のチェックを概念的に混同してるんだと思われ。
917:仕様書無しさん
07/03/21 11:29:22
バグの検出と入力のチェックの区別がつけられない奴って
アサーションも碌に使えないんだろうなきっと。
918:仕様書無しさん
07/03/21 11:49:42
データなんて保存中に壊れることもよくある
919:仕様書無しさん
07/03/21 11:50:13
「assert で停止するのはデバッグ時のみ」であることを曲解すると
「リリース時はそのまま動き続けるのが正しい」となる。
…気持ちは解らんでもない。
920:仕様書無しさん
07/03/21 12:01:39
この前、VB4からVB6に移植する仕事をやったけど、全サブルーチンにエラーハンドラがつけてあって、
多くは、Beepを鳴らして、ログにエラー番号みたいのを書き出して、そのまま処理を続行になってた。
現場じゃ、画面が明らかにおかしくなってるようなバグ以外は、そのまま操作を続行しちゃうんだろうなぁ。
921:仕様書無しさん
07/03/21 13:35:25
入力時のチェックは厳重・厳密に行い、出力時のチェックはゼロ。。。。
マスタ登録部はチェックが多重だが、読み出し部は「マスターが正」だから
チェックも糞もない。データとマスタとのチェックは厳密だろうけど。
これくらいしか思いつかない。
922:仕様書無しさん
07/03/21 15:20:06
日付・時間が
char(6)Char(8)
とか勘弁してください。
比較が面倒です
923:仕様書無しさん
07/03/21 15:44:52
西暦・和暦変換するクラスの名前が
WestanYearとなってる。笑い殺すつもりかよ
924:仕様書無しさん
07/03/21 16:02:11
Seireki2Warekiだろ
925:仕様書無しさん
07/03/21 16:05:02
CalenderConversがいいんでないか？
926:仕様書無しさん
07/03/21 16:10:46
28時とか入っててびびった(char(4)で2800）
というか仕様書に書いてもないのにそれが正常とか言わんでくれ・・・
927:仕様書無しさん
07/03/21 16:14:53
>924
あるあるｗｗ
928:仕様書無しさん
07/03/21 16:26:38
>>926
テーブルの制約で不可にするのが当たり前だろう
929:仕様書無しさん
07/03/21 16:31:20
>>28時とか入っててびびった(char(4)で2800）
char(4)だと99時99分でオーバーフローになります、
もっと桁をとりましょう
930:仕様書無しさん
07/03/21 16:46:01
>>922
正確には「時間」ではなくて「時刻」ではないかと。
多くの言語やDBで混同されているみたいだが。
>>929
四徹程度でオーバーフローしてしまうとは情けない・・・か。
931:仕様書無しさん
07/03/21 16:52:56
>>930
VC(MFC)、C#, Oracleは区別あるな。
ほかのでもあるんじゃね?
932:仕様書無しさん
07/03/21 16:54:32
>>905
それはよくやる。というか、結果的にそうなることが多い。
#if DEBUG で括ったMessageBoxをいれてるだけのとことか。
似たようなことをやろうとして、↓のようにするやつもいるが…。
catch(Exception e) {
// Exceptionをcatchしたらthrowする
new throw Exception();
}
933:仕様書無しさん
07/03/21 17:14:29
C++だとthrow; だけでcatchした例外を投げたよね。
934:仕様書無しさん
07/03/21 17:47:53
エラーをきちんとハンドリングできれてばどこのスタックでキャッチ行っても構わないが
mainからシステムへ落とすのだけは勘弁してくれｗ
935:仕様書無しさん
07/03/21 18:28:13
設計書なしでいきなりソースコードだけ渡されて
「直してね」と言われたときは殺意を覚えたな。
936:仕様書無しさん
07/03/21 18:31:33
古いC++プログラムでよくある話
937:仕様書無しさん
07/03/21 18:32:33
設計書なしでいきなりmdbだけ渡されて
「VBに移植してね」と言われたときは殺意を覚えたな。
938:仕様書無しさん
07/03/21 18:37:20
既存物理設計→既存論理設計→新規論理設計→新規物理設計
を行えって言ってるんだよｗ
939:仕様書無しさん
07/03/21 20:54:58
>>916
On Error Resume Next に関する恐ろしい話の一つくらいは聞いたことがあろう
940:仕様書無しさん
07/03/21 21:01:51
バグがあったぐらいで毎回止まってたら仕事にならない
941:仕様書無しさん
07/03/21 21:39:58
餌が美味しくない。
942:仕様書無しさん
07/03/21 23:23:14
例外はトップレベルで拾えって規定されたプロジェクトも有ったな。
単にメッセージボックスでエラー文字列表示してるだけだったがｗ
943:仕様書無しさん
07/03/22 00:04:29
>>942
隠蔽するよりずっとマシだ。
944:仕様書無しさん
07/03/22 00:12:01
On Error Goto ErrorHandling
ErrorHandling:
MsgBox "エラーが発生しました。以下に連絡してください" & vbCrLf & _
"090-xxxx-xxxx"
945:仕様書無しさん
07/03/22 00:16:24
連絡場所が書いてあるだけ良心的だろ
946:仕様書無しさん
07/03/22 00:39:27
入出力チェックが完璧かどうかどうやって調べるのか。
947:仕様書無しさん
07/03/22 10:27:57
>>945
>>944の連絡先番号が正当であるかチェックしないと請求詐欺にあうぞ。
948:仕様書無しさん
07/03/22 13:29:29
>>942
レベルがまちまちな作業者が多数作業する場合には苦肉の策としてそうするな
949:仕様書無しさん
07/03/23 00:13:47
バイナリエディタで電話番号を書き換えるやつがいそうだ
950:仕様書無しさん
07/03/23 07:44:01
納品時に、嫌いな上司の携帯番号を設定ファイルに記述するんだろ？
あれ、違ったっけ？
951:仕様書無しさん
07/03/24 23:07:32
２０MHｚで動くRISCマイコンで
数ミリひたすらNopする時間稼ぎループを発見したとき・・・。
952:仕様書無しさん
07/03/24 23:29:24
RISCのNOPってコンパイラがこっそり入れたりするんだよな。
953:仕様書無しさん
07/03/24 23:48:06
>>951
組み込みではよくある事じゃない？
チップの初期化待ちとか
954:仕様書無しさん
07/03/26 05:20:14
空ループは最適化すると消えるからタイマーを使うのが常道では？
955:仕様書無しさん
07/03/26 05:35:31
つvolatileの活用
volatile int i;
while(i<N) i++;
C言語の話だが
956:仕様書無しさん
07/03/26 06:46:27
で、処理が間に合わないと御託が。
957:仕様書無しさん
07/03/26 10:28:07
組み込みじゃリリースで最適化ナシは当たり前なんだが。
958:仕様書無しさん
07/03/26 22:07:09
タイマーなんか最初は動いてないし
959:仕様書無しさん
07/03/26 22:18:42
印刷したソースにやきそばソースぶっかけられたこと
960:仕様書無しさん
07/03/26 22:52:51
スパゲッティならぬソバコード
961:仕様書無しさん
07/03/26 23:55:55
ASP.NETやってて
<HTML>
<HEAD>
<THML>
</HEAD>
<BODY>
</THML>
</BODY>
</HTML>
当然解析エラーになるわけだが
見た瞬間目の前が真っ暗になった。
なんでこんなものが長々と放置されてたんだorz
962:仕様書無しさん
07/03/27 00:28:22
どこからどうみても何をしたいのか分からない
963:仕様書無しさん
07/03/27 01:17:10
クソのようなHTMLとCGIの塊にAjax云々の泥沼をアレな俺ならばなんとなく理解できる。
明日は客に見せるらしいが、ようやくパースエラー出なくなったことを喜んでもらおう。
964:仕様書無しさん
07/03/27 07:56:08
>>963
Ajaxとかかっこつけてるけど、実際はJavaScript埋め込んだだけだろう。
Ajaxと名前変えただけで流行らせようとする拙さに泣けてくるｗ
965:仕様書無しさん
07/03/27 11:03:35
>>964
Ajax云々と言っておけば余計な工数と金がとれるんだよ。
そんくらいわかれボケ。
966:仕様書無しさん
07/03/27 13:13:35
アジャエックスですという営業がいたらおもしろそーなのに
さすがにとぅくぴっぷはいてもコレはいねーのかなぁ
967:仕様書無しさん
07/03/27 13:20:06
最初アヤックスと読んでしまったサッカーファンの営業ならいたなぁ。
968:仕様書無しさん
07/03/27 13:25:47
エイジャックスくらいなら居そうだ。
969:仕様書無しさん
07/03/27 13:28:29
>>968
970:仕様書無しさん
07/03/27 15:09:55
>>968
971:仕様書無しさん
07/03/27 15:10:53
ｱﾆｼﾞｬｯｸｽ……
∧＿∧
∧＿∧ （´<_｀ ） ねーよw
（ ´_ゝ`） / ⌒i
／ ＼ | |
/ /￣￣￣￣/ |
＿_(__ﾆつ/ ﾌﾞﾙﾏ / .| .|＿＿＿＿
＼/＿＿＿＿/ （u ⊃
972:仕様書無しさん
07/03/27 15:36:04
アッージャックス
973:仕様書無しさん
07/03/27 15:40:48
アジャクロス
Web2.0の必殺技か何かです
974:仕様書無しさん
07/03/27 21:59:56
AjaxもWeb2.0も俺たちに金を落としてくれる
素晴らしい言葉です。
975:仕様書無しさん
07/03/27 22:02:52
>>973
アジャコングの必殺技にしか見えない。
976:仕様書無しさん
07/03/27 22:18:30
あじぇいあっくす
977:仕様書無しさん
07/03/28 02:27:47
>>968