コーディングトラブルの約70％はif文などでの{}省略

1 名前：デフォルトの名無しさん mailto:sage [2007/03/09(金) 14:02:01 ] 自分は1行しか書かないつもりでも あとでコードを足さなければならない事態なんていくらでもやってくる。 他人がきちんと中括弧補ってくれるかどうかはわからない。 1行文だろうがなんだろうが 最初から中括弧をつけるクセをつけろ 245 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 13:51:37 ] おまえはソース整形について誤った観念を抱いているのではないか 246 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 13:52:38 ] ソーッスねぇ 247 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:27:11 ] ソース整形したらテスト全部やり直しなんだけどそれついてはどうなの？ 248 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:29:25 ] >>247 なんで？ 249 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:33:05 ] >>248 あ？遊びでやってんじゃねーんだぞ 250 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:34:46 ] >>247 kwsk 251 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:37:04 ] バイナリがかわんなきゃよくね？ or テストケース再実行すりゃいいじゃん 好きなほうで 252 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:40:18 ] テストする前に整形すればいいだけじゃん 253 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:41:43 ] リポジトリにコミットするとき、自動的にソース整形すりゃよくね？も追加 254 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:45:04 ] >>247は自動化したテストですらとんでもなく時間を食う ちょー大規模プロジェクトをやってるんだろう。 255 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:49:30 ] >>251 ＞バイナリがかわんなきゃよくね？ これは納得できる ＞テストケース再実行すりゃいいじゃん 手動のテストケースもあるから無理 仮に全自動であったとしても時間無駄にしてんじゃねーよ >>252 ソース整形しただけの個所までテストするのが時間の無駄 >>253 改行した瞬間に自動的にソース整形するVBが最適解か……orz 256 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:53:35 ] やはりpythonが・・・ 257 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:54:49 ] >>255 時間かかるテストは、夜走らせとけよ エディタorIDE ↓ リポジトリ(コミット時にソース整形) ↓ CI(夜間に自動ビルド＋テスト) これ大抵の言語でいけるだろ。 258 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 16:57:26 ] バイナリが変わるようなコード変換はもはや整形じゃないと思う 259 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 01:12:11 ] >>175 そんなの^(unsigned)*[int|char|short|float|double] [a-Z]+[0-9|a-Z]*\(とかで検索すればいいんじゃね？ 260 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 01:20:04 ] 無理やりこうやればできるとかいう話じゃなくってさ。 viでは検索が日常的なカーソル移動手段のひとつなんだよ。 261 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 01:34:57 ] >>259 ぜんぜんだめ。おはなしにならない。 262 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 01:51:22 ] C言語は文脈自由文法だから正規表現で完璧にマッチさせるのは不可能 263 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 05:35:27 ] >>262 こういう話疎いので、初心者にも解るように解説してください。 264 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 07:02:14 ] >>263 コンパイラの本でも嫁 265 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 11:30:39 ] 突然舞い上がったようなレスだな。>>262は そもそもどのレスに依存するのだろう。 266 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 11:33:56 ] 259のあたりだろ。 267 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 11:41:31 ] >>265が>>262を全く理解できなかったということだけはわかった。 268 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 11:50:27 ] まあ規約ガチガチなのはそのせいだしな 269 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 13:40:30 ] 正規表現に疎い俺に>>173はどういう正規表現を書いているのか教えて欲しい。 270 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 13:49:32 ] そこらじゅうに未定義・未規定・処理系依存が ぽっかり口をあけているC言語のどの辺がガチガチ？ 271 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 14:23:15 ] コーディング規約でガチガチにするって意味だよ 272 名前：263 mailto:sage [2007/03/18(日) 18:26:20 ] そんな連関、聞いたこと無いけどな。 273 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 19:16:41 ] >>263 かっこが自由に無制限に入れ子に出来るパターンは 正規表現じゃ理論上無理らしいよ 274 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 20:28:25 ] 正規文法と文脈自由文法でぐぐってみ 275 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 20:33:57 ] 正規文法は a is b のルール． 線形構造しか表現できない． A→B→C A is B. B is C. 文脈自由文法は a is b and c のルール． 木構造を表現できる． A┬B 　└C┬D 　　　 └E A is B and C. C is D and E. そういうこっちゃ． 276 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 21:01:57 ] だかPerlとかの変態拡張性器表現ならきっと・・・ 277 名前：デフォルトの名無しさん mailto:sage [2007/03/18(日) 21:11:13 ] Perlのは正規表現の中でPerlのコードを評価できたりするからある意味万能 278 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:02:33 ] つまりゲストのお客さんが自由に参加すると収拾がつかなくなるので、 レギュラーのメンツだけでやってくれ、というわけですね。 279 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 05:52:30 ] 結構前の話題だが 俺は例えば if なら if(式) 文; 文が一行で、かつこの行が長くならない場合だけ { } を使わずに書くかなぁ。 if(式) 　　文; と書くぐらいならブレースを使ってる。 280 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 07:18:05 ] 条件文がすげー長かったら？ やっぱ１行でもブロックにする？ 281 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 07:27:01 ] 条件式を関数なりマクロなりに分けて良い感じの名前を付ければおけ。 そういう時ローカル関数使える言語だといいんだけどな。 282 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:29:05 ] ローカル関数は欲しいねえ・・ 283 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:35:21 ] C++;なら関数内で定義したクラス/構造体のメソッドで代用出来るけどな 284 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:44:43 ] 無理やりそんなことしても読みにくくなるだけだろ。 読みやすくすることが目的なのに。 285 名前：279 mailto:sage [2007/03/19(月) 20:21:25 ] >280 うん。条件が長い時もブレースにする。 もしくは条件式の閉じ括弧を実行文の行に持ってくる。 これなら俺は間違えない。集団ならやらんけど。 if( 　　条件式 ) 実行文; BASICで育ったんで一行IF／ブロックIFが基本、 長い時はブロック化するかこうしてたからなー。 IF 〜 _ THEN 実行文 286 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 13:47:00 ] 自分所のコーディングルールは、 if (式) 文1つ ; if (式) { 複数の文 } のいずれか片方のみ可。 287 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 14:34:40 ] ルール作るなら、常にブロック使えやコラにした方が良くね？ 288 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 14:35:55 ] ガチガチだと読みにくくなるよ・・・ 289 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 14:49:39 ] if (式) { 　・・・ } これに統一すると美しい 290 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 14:58:54 ] 主観 291 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 06:53:45 ] >>289 自分には美しく見えない。 変数のスコープのために、 { 何か { 何か } 何か } という書き方をする場合があるので、 if (式) { 何か } という書き方を許してしまうと、{ が現われたとき、 if (式) { 何か } という可能性を考えて、前方向をチェックしなくてはならない。 if (式) { 何か } というように同じ行に書くように強制すれば、見てすぐにわかる。 if (式) と { が生き別れになってしまうこともない。 292 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 11:19:49 ] そんなのは、常に整形ツール使えって事でいいじゃないか。 そのルールが気に入らない場合は、自分が読む時に整形しなおせばいい。 そして、読み終わったら元に戻すと。 293 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 11:36:07 ] よっぽどものすごい書き方してなきゃだいたい読めるし、 書くときはまわりに合わせりゃそれでいいじゃないの。 こんなのが原因でトラブるやつは他の原因でもっとトラブるよ。 294 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 12:55:21 ] >>291 つ[c++ or c99] 295 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 14:17:17 ] TCLではブレース次行じゃダメなんだよな 296 名前：デフォルトの名無しさん mailto:sage [2007/04/11(水) 22:35:26 ] >>295 そうなのか。 あれは、それぞれがシェルコマンドみたいなもんだからな。 297 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 19:54:03 ] Tclは改行した時括弧の中じゃなかったら そこでバッサリ文末になるからな 298 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 20:55:47 ] Rubyは、改行したところまでで文が成立する場合は次の行は別の文扱いだな。 二項演算式の途中とか対応するカッコを閉じる前のような、文が未完結である ことがわかる場合は途中改行ができる。完結しているように見える場合は、 ¥を付けて明示的に継続する必要がある。 299 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 23:55:43 ] セミコロンが文の終わり、にしときゃ良かったと思うんだけど なんでそんなにも ; なくしたかったのかな？ 300 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 00:57:43 ] 毎回行末記号書くよりも、必要な時だけ継続記号使った方が手間がかからないという思想だろう。 301 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 01:16:58 ] >299 俺は逆に 何でわざわざ毎回行末を書かなきゃいけないんだ？ 行末は普通文末だろ？ と思うぞ。 結局、普段使ってる言語の影響が強いんだと思う。 Lisperは文末どころか文の始まりまで毎回書くんだもんな…凄いと思う。 302 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 09:50:40 ] Ruby慣れると、C書くとき早速セミコロンを忘れる。 無いほうが自然なんだな、と実感する 303 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 10:13:04 ] 文脈によらずに継続行書くときは常に\つける方が好み。 304 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 11:38:37 ] おまいらFORTRANやCOBOLの時代に逆戻りだな・・・ 305 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 14:28:13 ] >304 むしろ、その時代はカラム制限があったから セミコロン文末の方が利点が多かったろうに ある程度のカラムが扱えるなら継続行のみ明示で良いと思うぞ どうせそんな滅茶苦茶長い行書かないし …ああ、C言語は使うAPIによっちゃ長い行が普通になるのか 306 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 19:18:25 ] >>301 Lisperにはカッコは見えていないし意識して入力もしてないｗ 307 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 19:56:09 ] >306 そういうモノなのかｗ 他言語の人（俺含）から見れば大量の括弧の方が目につくんだがな〜 308 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 20:56:19 ] >>307 begin endが目につくpascalとか :-が目につくprologとか {}が目につくCとか <>が目につくXMLとか 309 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 21:57:00 ] インデントしてたらそんなに目に付くもんでもないんじゃない？ 310 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 01:53:45 ] セミコロンなしで行末で文末としてしまうと、 class hoge { どわーーー} という具合に1行に書かないといけなくなりますぞ。 311 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 09:42:14 ] どわーーーでなぜか和んだ。 312 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 09:43:53 ] >310 そういう言語は ・閉じ括弧が少ない場合はブロックが継続する ・構文でブロックを示すからendが来るまでブロックが継続する のどちらかを備えてるだろ普通。 Tclは前者。 BASICやCOBOLは後者。 Rubyは両方使ってるな。 Pythonはインデントでブロックを示すんだっけ？ 313 名前：デフォルトの名無しさん mailto:sage [2007/04/14(土) 12:12:36 ] Pythonはインデントでブロックを表してて、両方だな。 314 名前：デフォルトの名無しさん mailto:sage [2007/04/16(月) 22:57:37 ] 途中から良スレになってる気がした 315 名前：デフォルトの名無しさん mailto:sage [2007/04/17(火) 04:31:02 ] 気のせいだった 316 名前：デフォルトの名無しさん mailto:age [2007/08/31(金) 11:46:07 ] age 317 名前：デフォルトの名無しさん [2007/09/01(土) 15:23:25 ] かの有名なカーニハン先生も省略するべきでないと仰っているよ。 318 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 15:33:26 ] 蟹飯がナンボのもんじゃーい！ 319 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 17:16:33 ] >>317 K&R、省略しまくりじゃん。 320 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 06:09:15 ] 俺はC→JAVA→C++→C#と勉強してきたから コードブロックよりもセミコロンがない言語が苦手だな 321 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 18:34:19 ] セミコロンは文の区切りです。 322 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 21:58:20 ] 同じセミコロンでもデリミタとして使う言語とターミネータとして使う言語があるのよん。 323 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 23:07:25 ] Pascalは文の最後はピリオドだったな。 324 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 00:46:44 ] pascal は ○ if a then b else c; × if a then b; else c; (コンパイルエラー) Cはどっちも大丈夫 325 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 01:18:28 ] Cはどっちも怒られそうだぞ 326 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 13:06:03 ] カッコが付かないな 327 名前：デフォルトの名無しさん mailto:sage [2007/12/31(月) 03:42:45 ] Pascalの場合、elseはif文の一部で セミコロン付けると、そこでif文が終わるから 「文頭にelseはおかしい」って言われるんだよね。 328 名前：デフォルトの名無しさん mailto:sage [2008/03/05(水) 17:00:17 ] c でも else は if 文の一部。 ; が文同士のセパレータではなく文の終端記号でしかないから、 b; が 1 文となって問題にならない、ってこと。 329 名前：デフォルトの名無しさん mailto:sage [2008/03/15(土) 16:13:12 ] >>323 プログラムの最後だろ？ 330 名前：デフォルトの名無しさん mailto:sage [2008/05/04(日) 13:30:52 ] >>1 COBOLのIF文の歴史を知らないんだな。 331 名前：デフォルトの名無しさん mailto:sage [2008/05/06(火) 17:30:21 ] 内容（意味）によらず形式だけで決める >>1の考え方が危険なだけ 332 名前：デフォルトの名無しさん [2008/05/06(火) 17:42:39 ] 人いたんだ。 333 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 14:44:13 ] >>331 形式で決められるものは、決めればいい。 その分、考えないといけないことに頭のリソースを配分しようぜ。 334 名前：デフォルトの名無しさん mailto:sage [2008/06/29(日) 01:35:51 ] ブラを付ける自由もあれば、付けない自由もある。 女性はブラジャーの着用を義務付けるという法律が 制定できないのと同じ。 ブラは時には非常に邪魔になる。 形式では決めることができないものは意外に多い。 335 名前：デフォルトの名無しさん mailto:sage [2008/06/29(日) 02:50:06 ] そもそも、 Windowsのメモ帳にたくさん毛が生えたようなテキストエディタを使ってコードを書く という時点で、おかしいだろ。 336 名前：デフォルトの名無しさん mailto:sage [2008/06/30(月) 18:35:16 ] C#なら言語仕様で{}を強制してたとしても不思議ではないね switch内のbreakは強制だっけ 337 名前：デフォルトの名無しさん mailto:sage [2008/06/30(月) 22:41:09 ] {} を強制するなら elseif キーワードが必要 338 名前：デフォルトの名無しさん mailto:sage [2008/07/01(火) 03:21:06 ] ブラを強制するのなら、elseの禁止も合わせてやったほうが良いかも？ よくね〜よw。 なるべくブラ着用。elseの多用は可愛気がないぜ。といったところ。 339 名前：デフォルトの名無しさん mailto:sage [2008/07/01(火) 04:43:44 ] コーディングするためのユーザインタフェースが、 事故を未然に防ぐべく何かするのが第一だろ いつまでも 紙に鉛筆でプログラムを書くレベルに留まるな 340 名前：デフォルトの名無しさん mailto:sage [2008/07/27(日) 00:00:15 ] >337 なぜに? 341 名前：デフォルトの名無しさん mailto:sage [2008/07/27(日) 02:59:30 ] elseifがないと if () { } else { 　if () { 　} else { 　　if () { 　　} else { 　　　if () { 　　　} else { 　　　} 　　} 　} } みたいにどんどんネストが深くなる。 342 名前：デフォルトの名無しさん mailto:sage [2008/07/27(日) 03:00:38 ] {} を省略できるなら if () { } else if () { } else if () { } else if () { } else { } みたいに書けるんだけど 343 名前：デフォルトの名無しさん mailto:sage [2008/07/27(日) 03:06:05 ] 強制する←→省略不可だからそういうのも認めないって話じゃねーの。 344 名前：デフォルトの名無しさん mailto:sage [2008/07/27(日) 03:27:46 ] というか、>>1の主張を強制するのならelse ifという慣用表現も禁止で >>341みたいにきちんとif文をネストするような表現とすることを 強制するべき。 >>342式を禁止するというか非推奨にするのは、それなりに根拠がある。 多くの場合、>>342の形式の場合、ロジックが練れていなく、 バグが多い割に修正が難しいから。経験的に言って>>341式のほう が、バグも少なくなり、バグが出ても修正しやすいような気がする。 結論的に言えば>>342式を禁止するのは一定の意味を持つが >>1を強制するのはやり過ぎかも。 345 名前：デフォルトの名無しさん mailto:sage [2008/07/27(日) 04:11:17 ] >>342禁止ですら、行き過ぎという感があるのに >>1強制なんてあり得ない 346 名前：デフォルトの名無しさん mailto:sage [2008/07/27(日) 13:36:09 ] なる。 それなら俺は {} 強制で else if 容認かな。 自分のバグ元としては {}なしのif より 比較に = 使っちゃう方が多いけど。 だから、エディタで[^><=]=[^=] を赤くなるようにしてる。 347 名前：デフォルトの名無しさん mailto:sage [2008/07/28(月) 15:32:25 ] caseで 348 名前：デフォルトの名無しさん mailto:sage [2008/07/28(月) 17:42:41 ] 多くの場合、経験的に言って、根拠があると言っているわりに>>344は主観推論しか言っていない気がする。 349 名前：デフォルトの名無しさん mailto:sage [2008/07/28(月) 21:13:28 ] case式が強力な言語ならいいんだけどCだと定数との比較しかできない 350 名前：デフォルトの名無しさん mailto:sage [2008/08/04(月) 12:32:49 ] >>342のようなコードってさ、 if (A) { い } else if (B) { ろ } else if (C) { は } else { に } ってさ、 if (A) { い } if (!A && B) { ろ } if (!A && !B && C) {は} if (!A && !B && !C) {に} ということなんだけど、その条件が分散して書かれているから、わかりにくいのよね。 ただのswitch-case的な使い方だと誤解して順序を変えてしまうと、意味が変ってしまう。 351 名前：デフォルトの名無しさん mailto:sage [2008/10/01(水) 23:41:42 ] if(id == typeA && ){} else if (id == typeB &&){} って書く奴いるけどなんでswitch文使わないの バカなのねぇバカなの？ 352 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 09:16:07 ] >>351 妙な && が気になるが、if で書けば ・コードの行数が少なくて済むので見やすい ・スコープがしっかり認識できて良い ・シンタックスハイラトや自動インデントなど IDE によっては switch の対応が微妙 ・if の方がコンパイラが最適化しやすい条件になっている とかとか。分かってて書いている人なら、別に良いと思うけど？ 353 名前：デフォルトの名無しさん mailto:sage [2008/10/02(木) 22:17:54 ] if(id == typeA) if(id == typeB) と if(id == typeA) else if(id == typeB) 同じ意味だよね？ 354 名前：デフォルトの名無しさん mailto:sage [2008/10/03(金) 01:40:46 ] >>353 if (id == typeA) { ... id = typeHoge; } の場合は？ 355 名前：デフォルトの名無しさん mailto:sage [2008/10/06(月) 12:06:12 ] >>353 idがconstなら同じ。そうでないなら、>354の可能性がある。 例えば、この関数では全く同じ。 void func(const int id) { if (id == typeA) { funcA(); } if (id == typeB) { funcB(); } } 356 名前：デフォルトの名無しさん mailto:sage [2008/10/06(月) 12:18:01 ] つか、同じじゃないように見えるんだけど？ if(id == typeA) if(id == typeB) って、インデント付けると if(id == typeA) 　if(id == typeB) だよな？　更に括弧も付けると if(id == typeA) { 　if(id == typeB) { 　} } だよな？ 357 名前：デフォルトの名無しさん mailto:sage [2008/10/06(月) 13:00:09 ] >>356 >353が>351を踏まえて書いたかどうかだな。 >353が>351を踏まえずに>356の意味で書いたのだとしたら、 if (id == typeA) if (id == typeB) は(typeAとtypeBが等しいと言う無謀な前提を仮定しない限り) if (0)と同じになってしまう。 358 名前：デフォルトの名無しさん mailto:sage [2008/10/07(火) 18:07:30 ] べつに無謀な前提ではないんじゃないか typeA != typeBでもid == typeAかつid == typeBだったりすると怖いけど 359 名前：デフォルトの名無しさん mailto:sage [2008/10/09(木) 12:42:52 ] >>358 この流れでその前提は、余りに阿呆過ぎる。 最早>351も>353もいないから真意は不明だが。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef