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

1 名前：デフォルトの名無しさん mailto:sage [2007/03/09(金) 14:02:01 ] 自分は1行しか書かないつもりでも あとでコードを足さなければならない事態なんていくらでもやってくる。 他人がきちんと中括弧補ってくれるかどうかはわからない。 1行文だろうがなんだろうが 最初から中括弧をつけるクセをつけろ 111 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 04:39:32 ] >>109 漏れはけっこう使う。 int n; { 　// 一時的な変数なんかも使って n を初期化するコード } // n を使うコード とか。 書いてみて思ったより長かったらそのまま別の関数にするけど。 112 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 04:56:00 ] >>107 そういう職場ってそのうち慣れますか？ それともとっとと逃げ出すのが正解ですか？ 113 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 05:00:10 ] >>112 そこに骨を埋めるつもりならがんばって慣れないと。 いずれ他所へ行くつもりなら慣れちゃったら後が大変そう。 114 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 05:08:38 ] ……後者を選ぶことにします 115 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 05:55:22 ] >>110 そうしたくなったときというのは、 そこで関数を分けるべき時だと思っているので、 ほとんどの場合は括りだして別の関数に仕立て上げちゃう。 もちろんほんのちょっとスコープを限定したいというときは、 その限りでないけど。 116 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 05:58:01 ] >>107 それをやっているところはコボラーが仕切っていると考えてほぼ間違いないです。 あいつらオブジェクトがどうのとかいう以前に関数をわける利点とか、 もっと以前にわかりやすい名前をつけるとかスコープとかいうことを知らん。 117 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 06:34:15 ] このスレおもすれえ 118 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 06:36:52 ] >116 しょうがないじゃん、COBOLの仕様にはグローバル変数と 引数の無いサブルーチンしか無いんだから… 119 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 07:01:39 ] うざい上司にはインデントで訴えかけるに限る hoge.each do |foo, bar| 　　　　　　　　　　fuga 　　　　 　piyo 　　　　hogera 　　　end 　　　　　　piyo hoge.to_a.each do |foo,bar| 　 　　　　　foo 　poi;　　　bar;　　　poi qwe;　　　　　　　　　　　end 120 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 08:11:08 ] >>94 >>108 30年以上前かららしいから、そんなところでしょう。 COBOLで IF CC EQUAL DD PERFORM YY ELSE PERFORM ZZ. の名残だと思う。 テスト、デバックがこの方がやりやすいからというのが積極的な理由。 ただしbreakする時が大変。 121 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 10:11:27 ] www.mono-project.com/Coding_Guidelines#Where_to_put_braces 2つ目のgoodがbadだぜ 122 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:04:17 ] Coding Guideline であって Coding Convention じゃないんだな。 それくらい大きなオープンソースプロジェクトともなると、規約にしたところで従わない奴が続出するんだろうな。 123 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:09:05 ] 厳密にやろうとするなら、コミット前にチェックして(subversionなら pre-commitフック、CVSだとcommitinfoか?)、従ってなければコミット させないなんてトコもありそう。 124 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:18:09 ] そこまでして関数名はf+数字を強制とかイヤすぎるなｗ 125 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:31:50 ] JavaやC++で省略する奴とは仕事しない 126 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:36:39 ] C++は省略しても普通だよね。 127 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:38:07 ] if(flag) break; 128 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:40:31 ] if(x) 　　　　/* 何らかの処理 */; って書くとうっかりしやすいけど、 if(x) /* 何らかの処理 */; って必ず一行に収める習慣にすれば大丈夫な気がする。 129 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:47:07 ] if(x) 何らかの処理1; 何らかの処理2; と書く人がでてきちゃう。 130 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:48:34 ] そもそもブロックなしのifに一行追加して、ブロック付け忘れてハマったなんて経験がない。 131 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:51:29 ] 御意 132 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 12:58:06 ] >>129 「;」で区切って一行にいくつも文を書く人にはお勧めできない。 133 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 13:28:01 ] if(cond) i = f(), j = g(); 自分一人の開発ならこういうこともする。 読み間違えるとかありえない。 134 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 13:29:32 ] 無能コーダーにぐだぐだコーディング規則を語られるのウザいから ソースはIDEが自動整形してくれ。 135 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 13:45:22 ] 括弧も自動で付けてくれるコードフォーマッタある？ 136 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 13:45:33 ] >>130 if(cond) { hoge(); fuga(); } を if(cond) hoge(); にしようとした形跡のあるコードで if(cond) hoge(); fugafuga(); と、インデントそのままでブレースだけとられたコードではめられた事がある。 じっさいにはもうちょっと長いんだけど。 137 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 13:47:01 ] if(cond) { 　　hoge(); 　　fuga(); } と if(cond) 　　hoge(); fugafuga(); にしようとしたコードで if(cond) 　　hoge(); 　　fugafuga(); とね（ちくせう空白つめんな） 138 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 13:49:17 ] >>135 ない 139 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 13:52:23 ] お前ら省略って言うけど、Cの場合本来ifの文法は if( 条件 ) 文; だよな？ でもこれだけじゃ機能不足で、複数の文を置きたいから{ }でブロックにするんだよな？ 由来とかはどうでもいいし俺も{ }は必ずつける派だけどな？ 140 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 14:22:20 ] >>139 確かに。 でもなんて表現したらいいんだろ？ 141 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 14:29:26 ] 実績ある有名なソフトでも、普通に省略してあるんで、品質には関係ない部分だとは思うけどな。 142 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 14:44:58 ] >>139 惜しい if (式) 文 だ。最後にセミコロンはいらない。 143 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 14:58:45 ] >>141 そもそも品質はテストによって担保するものでコーディングスタイルに依存するものではない。 ただ、よいコーディングスタイルであればミスを未然に防ぎやすいというだけのこと。 144 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 15:03:38 ] そもそもスレタイの70%の根拠は何だ! 145 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 15:12:06 ] >>144 そんなんどうせ >>1 の経験からのなんとなくだろ。 そんなのいちいち気にしてたら負けだ。 146 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 15:18:05 ] だけど、 if(condition) f1(); f2(); というコードに if(condition) f1(); f3(); f2(); なんて付け加えるプログラマっているか? 147 名前：146 mailto:sage [2007/03/10(土) 15:20:34 ] タブでなくスペースで送ってしまった。 >>146 は無かったことに。 148 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 15:20:36 ] >>146 なにがいいたいのかよくわからん。必要応じて &nbsp; を使ってくれんか？ 149 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 15:27:40 ] >>143 だから、{}を省略してもミスとは関係ないって判断してるんだろ? 有名ソフトで{}を省略するスタイルの人たちは。 150 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 15:33:07 ] 一人の天才で組んでるならともかく馬鹿と仕事するときは 馬鹿のレベルに合わせなきゃいけないんだよ 151 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 15:34:10 ] >>149 有名ソフトでそうしているからっていう判断はあんまり感心せんな。 152 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 15:36:50 ] >>150 短期的にはそれは認めるけど、今のこの業界は馬鹿を馬鹿のまま放置しすぎ。 153 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 16:05:16 ] 向上心が無いからバカ 154 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 16:23:46 ] >>151 自分の経験も加えて。 2chのななしよりの意見より、実際に成果を出してるやつのスタイルのほうが参考になる。 155 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 16:27:33 ] 有名ソフトや書籍でも、省略する派としない派がある。 ようは、たいして重要じゃないってことだろ。 156 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 17:48:19 ] う〜ん、おそらくループ変数なんかのためでしょうし、 そのほうが安全そうですが、そういうソースは見たことないです。 157 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 19:51:17 ] >>1が70％の確率で{}省略でトラブルという告白スレ 158 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 23:43:29 ] >>155 逆だろ 派閥が分かれるってことは懸案事項だってこと 159 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 23:48:25 ] 結論 コーディング規則を語るのは最下層の乞食コーダだけ。 160 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 00:08:58 ] 奴隷につなぐ鎖の強度を語るのはいずれ管理へ回る前途ある者 それを理解できない159は、奴隷以下の乞食か動物 161 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 00:15:19 ] 奴隷をつなぐ鎖なんて強度が十分であれば何を持ってきてもいい。 管理者はカタログから選んで持ってくればいいだけのこと。 鎖を再生産する管理者はバカ。 つながれてる鎖を自慢をする奴隷はマヌケ。 162 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 01:16:33 ] 何の比喩なのか、わかったようでわからないレスだな。 163 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 01:18:14 ] わからないならレスしなくていいよ。 164 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 01:20:33 ] 逆切れするくらいなら比喩なんか書くなよ 165 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 01:46:15 ] だそうだ。気をつけろよ>>160 166 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 02:01:40 ] >>165は>>160か。そんなにくやしかったのか？ 167 名前：160 mailto:sage [2007/03/11(日) 02:06:05 ] 悔しくなんてねーよ、バーカ 168 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 02:16:36 ] 本物の160だけど、160以外のレスはつけてないけどね。 逆切れしたのはどいつだか知りたい。 あと、>>160の理由もね 169 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 02:17:55 ] ＞あと、>>160の理由もね まちがえた、 あと、>>165-166の理由もね 170 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 02:27:14 ] 160必死だなｗｗｗｗ 171 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 03:58:07 ] だから｛｝でくくっておけばよかったんだ 172 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 05:47:17 ] int hoge ( void ){ } みたいなのもやめてほしいな。 173 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 05:52:03 ] 括弧はともかく int と hoge の間の改行は正規表現で定義と使用が区別できるので vi 使いには便利。 174 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 08:34:51 ] 正規表現なら別に改行でなくてもいいんでは。 175 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 08:48:19 ] >>174 vi使ってるときに、 /hoge で普通に検索 /^hoge で定義を検索 ていうことね。 176 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 11:34:46 ] IDE使えよ乞食 177 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 14:13:56 ] 現実には戻りの型の方が関数名より長い事も多々あるからな。 intみたいな極端に短い物以外は改行で統一した方が見やすい。 178 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 14:21:09 ] いやそんなにないだろ 179 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 14:27:25 ] constもポインタも構造体もクラスもテンプレートも出てこないんですか。 APIやらライブラリ使ってりゃ長い名前の構造体なんていくらでもあるだろうに。 180 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:24:51 ] 構造体なんか返すなよ 181 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:46:03 ] いくら長くても改行するほどじゃないな というか、返す型情報まで含めてワンセットだから改行したくないなあ 182 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:49:24 ] BSD系のカーネルのソースなんかは改行する事になってるね。 style(9)あたりに書いてある。 183 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:19:02 ] >>180 ３２ビット値２つとか３つの組は結構返すよ 184 名前：デフォルトの名無しさん [2007/03/11(日) 18:50:28 ] >>158 どっちか片方に収束しないってことは、どっちでも大差ないんだよ。 どっちかが明らかによかったら、片方のスタイルは廃れてるだろ。 185 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:54:17 ] >>180はC使い 186 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:56:33 ] 構造体自体を返さなくても、それを指すポインタ返せば記述は長くなりますやん。 187 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:59:02 ] >>185 C++でも同じだろ。 (スマートポインタで返すって手も使えるけど) 188 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 19:01:56 ] >>175 そんなん普通にコメントアウトでラベルつけときゃいいだけやん 189 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 19:03:41 ] >>188 意味わからん 190 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 19:30:28 ] >>189 int aho() /* teigi */ とかかな。 aho(); /* shiyou */ 全部に書く気なんじゃない？ 191 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 20:13:31 ] lint用のコメントみたいだなｗ 192 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 20:30:30 ] >>1 プログラマは信号は守るべきだが 小石を取り除くかどうかはプログラマしだいだ 尊敬するプログラマのソースを読め 193 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 20:35:44 ] >>192 尊敬するプログラマはみんな省略してませんでした 194 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 20:41:49 ] 漏れその昔、ビル･アトキンソンをめちゃくちゃ尊敬してたが、 C系のコードは書いてたのかどうか知らん。 195 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 23:10:46 ] defineで閉じてるのは軽くいらっとさせるね if () { ... #if 1 } else #endif ... } GNU関連は関数なんかもこれで閉じてくるよね 196 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 23:22:54 ] >>195 仕事でそんなコード書いてるヤツ見たら、思わずはり倒しちゃいそう。 197 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 00:32:13 ] return_type func_name( 　arg_type arg ) { } はダメダメってことですね。 198 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 01:23:06 ] >>197 なんで？ 199 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 01:47:52 ] つ >>172 >>177 200 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 02:07:20 ] >>197 俺はよくそのスタイルで書く衝動にかられるけど、 引数リストの行末がカンマで統一できないのが 嫌でいつも思いとどまる。 201 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:01:41 ] > 引数リストの行末がカンマで統一 そ、最後ね arg_type1 arg1, arg_type2 arg2, arg_type3 arg3 最後のarg3だけカンマなしでないとエラー。よく引っかかる。 配列の初期化子は最後のカンマOKなのにね。 202 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 14:22:14 ] >>187 C++ 使ってると C の頃の感覚が麻痺して 抵抗なく string 返したりもできるようになる筈ｗ 203 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 15:09:03 ] オーバーヘッドなんて高が知れてるし、参照もポインタも使わずに 構造体やクラスを平気で返しちゃうぜ 204 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:35:18 ] C++クックブックって本は、コンテナクラスは 全部引数でやり取りしてた。 205 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:53:09 ] 何でスレ伸びてるの？ 206 名前：デフォルトの名無しさん [2007/03/12(月) 23:23:25 ] >>76 それおまえさんが強要して出させたんじゃないか？ 207 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 00:04:04 ] >>206 スレタイの数字の話じゃねえの？ 208 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 01:41:45 ] ぶら下がりelseに起因するbug発生回数は一回 その他の中括弧の省略に起因するbug発生回数は零回 209 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 02:09:20 ] どんな書き方をしてもバグを生み出さないソースを書けばいいだけ どんなにファクターがありそうでも最終的にそこに原因を求めるのは結局責任転嫁だ 210 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 02:10:42 ] 読みやすい書き方はそれだけでバグの抑制になる 211 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 05:57:35 ] インクリメントとかシンプルな処理なら｛｝なんて使わなくても 使うのは数行に渡る見込みがあるか後々まで残す部分くらいだな 212 名前：デフォルトの名無しさん [2007/03/13(火) 08:01:55 ] やはりbegin〜endの勝利だな 213 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:26:05 ] Python最強ということで 214 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:35:13 ] schemeもええで 215 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:48:34 ] ソレより、 && || をif文中で使ってる場合の方が多いように思うけどな 特に俺が書いた時に無かったのに後から何気なく追加されたような場合、たいてい間違ってるゾ！ 216 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 11:02:09 ] 70%はそっちの方だね。 217 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 11:08:56 ] まだ && ||を２行に別けて書く人はミスが少ない気がする if( ( hoge == hage ) && ( hige ) ){ } みたいに 218 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 11:12:50 ] こういうのは程度の問題で、複雑な式は分けて書いた方が理解しすいだろうが、 シンプルな式まで徹底して分ける事に決めちゃったりしたら、かえってコードの意図がわかりにくくなると思う。 {}の省略についても同様。 219 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 11:39:36 ] if修飾子が使える言語(PerlやRuby)だと、やることが1つなら修飾子にして おいて、増えたら複文支配のifに書き換える、という使い分けが出来るな。 220 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 13:07:20 ] むしろ後置ifが使えるなら、 前置ifでの単文修飾は不可能にすべきじゃなかろうか。 221 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 13:16:18 ] perlはそうだね。 222 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 14:06:40 ] 俺はPBP6.2の通りに後置ifはnext, last, redo, return, goto, die, croak, throwでのみ使うようにしてる。 メンテ不要な書き捨てプログラムはこの限りでないがw 223 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:45:43 ] if文より型の変換とか値入れてない変数とかの方がやばい気がする。 224 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:46:14 ] 全ての分岐をgoto文で書いてやる 225 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 23:02:08 ] gotoが必要なのは多重ループを抜けるときだけだよな。 226 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 23:14:43 ] ttp://gedo-style.net/g/?v=361721&d=d.jpg 227 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 00:27:29 ] 多重ループは関数化で対処 228 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 04:07:30 ] gotoはエラー処理と字句解析のハードコード。 229 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 04:48:53 ] if() { ; } ↑これは異端か？ 230 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 05:29:00 ] 異端もクソも、なぜ if() の中を ! で否定しないよ 231 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 06:53:59 ] 頭ごなしに否定するのはよくない 232 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 10:31:18 ] ケツで否定してやる。 { ; } unless hoge; 233 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 10:41:26 ] { } を付けたら女の子にもてるようになりました 234 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 17:09:17 ] スーパー括弧閉じ 235 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 17:26:03 ] 括弧閉じはコッカって言わないか？ 236 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 19:21:20 ] 通じるけど恥ずかしいから自分では言わない。 237 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 16:12:21 ] >>235 それは局所的にしか通じないだろう。 238 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 16:57:00 ] sh 系だとそんなだよな。 esac ってなんだろと。 239 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 17:06:36 ] fi はまあ想像つくけどなｗ 240 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 22:54:36 ] 言語規格の中で if() ; 形を if() { ; } の省略形であるとしている 言語はどんなものがありますか。 241 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:11:15 ] そんなのあるのか？ 242 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 13:24:53 ] お前らエディタのソース整形機能とか使ったことなさそうだな 243 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 13:25:18 ] COBOLにそんな機能ねーよ 244 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 13:43:26 ] ソース整形が必要なほどのクソコードに出会ったら とりあえず腹をくくることにしている。 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