コーディングトラブルの約70%はif文などでの{}省略
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2007/03/09(金) 14:02:01あとでコードを足さなければならない事態なんていくらでもやってくる。
他人がきちんと中括弧補ってくれるかどうかはわからない。
1行文だろうがなんだろうが
最初から中括弧をつけるクセをつけろ
0359デフォルトの名無しさん
2008/10/09(木) 12:42:52この流れでその前提は、余りに阿呆過ぎる。
最早>351も>353もいないから真意は不明だが。
0360デフォルトの名無しさん
2009/04/08(水) 19:34:440361デフォルトの名無しさん
2009/08/26(水) 18:28:000362デフォルトの名無しさん
2009/08/31(月) 11:56:110363デフォルトの名無しさん
2009/09/01(火) 02:47:110364デフォルトの名無しさん
2009/09/01(火) 07:59:270365デフォルトの名無しさん
2009/09/01(火) 12:07:22そして成長しないまま{}を省略し続けると。
0366デフォルトの名無しさん
2009/09/02(水) 02:31:00詰め込み、使い回せる関数だけを外側に出そうとする癖がつく?
本当に使い回せるかどうかの判断は実は相当のベテランでも
ない限り難しいにも関わらず。
{}を付けない癖がつくと、すべて下請けに回そうというコード
になりがち。最初は調子が良いが硬直なコードになりがちなので
仕様変更時に泣きを見る結果になりやすい?
0367デフォルトの名無しさん
2009/09/02(水) 19:45:17構造もあやふやだろうし、{}無しで使ってコケる。それも勉強だろうけど、
{}を付けて処理範囲を明確にすれば、最低限コケることは無くなる。
{構造化を意識させることもできる(その地点からはだいぶ先の話だけど)。
0368デフォルトの名無しさん
2009/09/03(木) 23:09:26上級者はふつーに省略して、省略するなって主張してるのって、2chの名無しとか
素人くさいプログラム系のブログってイメージ。
0369デフォルトの名無しさん
2009/09/04(金) 02:03:580370デフォルトの名無しさん
2009/09/04(金) 20:36:44if(){
func1();
}
else
func2();
ふつうにインデントしてれば何も間違えよう無いし{}省略で
間違えたことなんて一度もねーぞ。
0371デフォルトの名無しさん
2009/09/04(金) 20:51:54皆さんは気にしなくていいですよ
0372デフォルトの名無しさん
2009/09/04(金) 23:38:11とても思えないんだが。
0373デフォルトの名無しさん
2009/09/05(土) 08:52:10{}省略で間違えることはあまり無い。
ただ、else節以降でインデントを間違えてるソースを見た事は2回ぐらいある。
あれは悩ましいからやめてくれ。
初心者のうちは間違いようの無いシンプルなルールで書いて、
他の部分に頭を使った方がいい。
もちろん天才とベテランは別。
0374デフォルトの名無しさん
2009/09/08(火) 09:41:31バグをバクとtypoするようなレベルの奴が言っても
0375デフォルトの名無しさん
2009/09/08(火) 12:26:480376デフォルトの名無しさん
2009/09/08(火) 14:08:44(_/ (ヽ'ヽ。 (_/ (ヽ'ヽ。 (_/ (ヽ'ヽ。
ヽ ゛д ノ ヽ ゛д ノ ヽ ゛д ノ <三倍に増えるぞな!
ノ ∪ | ノ ∪ | ノ ∪ |
,ゝ、 .ノ ,ゝ、 .ノ ,ゝ、 .ノ
|_( |_( |_(
0377デフォルトの名無しさん
2009/09/08(火) 22:26:47みっともね。
0378デフォルトの名無しさん
2009/09/09(水) 09:35:16手がすべったtypo、意図的なものとして定着したtypoならそうかもしれんが、明らかに違うよな。本人乙。
0379デフォルトの名無しさん
2009/09/09(水) 11:13:43JISカナ配列使いかも知らん。
0380デフォルトの名無しさん
2009/09/09(水) 11:59:17間違いは起こりうると証明してるようなもん。
0381デフォルトの名無しさん
2009/09/09(水) 12:02:32>そもそもコーディング時のミスの話してる時
「{}を省略することによる」という前提外すなよ。
0382デフォルトの名無しさん
2009/09/09(水) 14:42:400383デフォルトの名無しさん
2009/09/10(木) 09:22:190384デフォルトの名無しさん
2009/09/10(木) 11:42:18自分の前に使ってた人がカナロックしっぱなしで
うっかり「トントカイモ」とか入れちゃったとか、そういう被害にでも遭ったのか?
0385デフォルトの名無しさん
2009/09/10(木) 22:26:260386デフォルトの名無しさん
2009/09/12(土) 16:20:260387デフォルトの名無しさん
2009/09/14(月) 04:05:51解説してくれ。
0388最後の二つはNECとNTT
2009/09/14(月) 09:17:47トントカイモ→system
ハニリイト→files
パソ通の時代は、みんな覚えていたもんさw
ミイソの98でミミカ経由で繋いでたからね。
0389デフォルトの名無しさん
2009/09/14(月) 14:20:41リニトカとかスナミとかもやったなあ
0390388
2009/09/14(月) 15:18:380391デフォルトの名無しさん
2009/09/17(木) 11:51:39それより、結局処理追加する必要があると分かった時に挿入したり、
逆に一行でいいと分かった時に整合性のために削除してることが多いのに気付いて
めんどいから最近は {} 非省略派になった。
0392デフォルトの名無しさん
2009/09/17(木) 13:44:44if(hogehoge){
...;
...;
}
とか
if(hogehoge){ ...; }
とか。
ブレース使っても短い処理なら1行で記述できるし省略の必要性は全く感じてない。
0393デフォルトの名無しさん
2009/09/17(木) 13:52:53ときには、条件に一致した場合の処理を同一行に書く、上級糞コードも。
0394デフォルトの名無しさん
2009/09/17(木) 14:04:44もっとマシなコード書けよ。
くっだらねえ。
0395デフォルトの名無しさん
2009/09/17(木) 14:54:09統一感がなかったり、合理性がない書き方をする奴は確かにコード自体も質が悪い傾向にある。
ところでたまに
if (続行条件) {
続行処理...
} else {
終了処理...
}
みたいなのと
if (終了条件) {
終了処理...
}
続行処理...
どっちがいいのか迷うんだけど、(無駄にブロック作りたくないから後者にしてるけど)
こういう制御構文の使い分けのケーススタディみたいなのが
詳しく載ってるサイトとか書籍ってないのかな。
0396デフォルトの名無しさん
2009/09/17(木) 15:18:38ジョークかと思ったら、本気みたい。
0397デフォルトの名無しさん
2009/09/18(金) 09:51:54それだけじゃよく判らんが、無駄にブロックを作りたくないなら
if (! 続行条件) {
終了処理...
}
続行処理...
とするか
if (続行条件) {
} else {
終了処理...
}
続行処理...
としてもいいよね。
0398デフォルトの名無しさん
2009/09/19(土) 12:11:51マイクロソフトならやりかねない
0399デフォルトの名無しさん
2009/09/23(水) 11:58:270400デフォルトの名無しさん
2009/09/24(木) 00:02:47勘違いする人のためには elif が有ってもいいかもね。ダサイけど。
0401デフォルトの名無しさん
2009/09/25(金) 11:04:48少なくとも>395はelse ifの話なんて全然してないわけだが。
0402デフォルトの名無しさん
2009/09/25(金) 14:46:22書かれたコードを問題にしているのではない。
書いた阿呆の無能さを問題にしているのだ。
0403デフォルトの名無しさん
2009/09/27(日) 18:19:52一度間違ってソースが全部整形されてしまって、ヒストリで元に戻そうにも
そのミスをやってしまったのがかなり前だと判明したため泣きながら手作業で修正した
0404デフォルトの名無しさん
2009/09/27(日) 18:31:080405デフォルトの名無しさん
2009/09/28(月) 11:20:30今は必要なときに必要なところだけエディタで整形している。
0406デフォルトの名無しさん
2009/09/28(月) 21:29:020407デフォルトの名無しさん
2009/09/30(水) 15:01:54自分をエディタに合わせる方が楽。
0408デフォルトの名無しさん
2009/11/23(月) 20:43:161. メソッドに正常ルートが不明確な条件付振る舞いがある
2. 特殊ケースすべてに対してガード節( メソッド内で、処理がメインロジックに到達するの
を防ぐためのコード) を使う
double getPayAmount() {
double result;
if (_isDead) result = deadAmount();
else {
if (_isSeparated) result = separatedAmount();
else {
if (_isRetired) result = retiredAmount();
else result = normalPayAmount();
}
}
return result;
}
↓
double getPayAmount() {
if (_isDead) return deadAmount();
if (_isSeparated) return separatedAmount();
if (_isRetired) return retiredAmount();
return normalPayAmount();
}
出口が1 つだけというルールは本当は有益ではありません。
1つにすることでメソッドが明瞭になるならば出口は1 つでいいが、そうでなければ使うべきではない
■ このスレッドは過去ログ倉庫に格納されています