トップページ⇒tech
408コメント99KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2007/03/09(金) 14:02:01
自分は1行しか書かないつもりでも
あとでコードを足さなければならない事態なんていくらでもやってくる。
他人がきちんと中括弧補ってくれるかどうかはわからない。

1行文だろうがなんだろうが
最初から中括弧をつけるクセをつけろ
0332デフォルトの名無しさん2008/05/06(火) 17:42:39
人いたんだ。
0333デフォルトの名無しさん2008/06/25(水) 14:44:13
>>331
形式で決められるものは、決めればいい。
その分、考えないといけないことに頭のリソースを配分しようぜ。
0334デフォルトの名無しさん2008/06/29(日) 01:35:51
ブラを付ける自由もあれば、付けない自由もある。
女性はブラジャーの着用を義務付けるという法律が
制定できないのと同じ。
ブラは時には非常に邪魔になる。
形式では決めることができないものは意外に多い。
0335デフォルトの名無しさん2008/06/29(日) 02:50:06
そもそも、
Windowsのメモ帳にたくさん毛が生えたようなテキストエディタを使ってコードを書く
という時点で、おかしいだろ。
0336デフォルトの名無しさん2008/06/30(月) 18:35:16
C#なら言語仕様で{}を強制してたとしても不思議ではないね
switch内のbreakは強制だっけ
0337デフォルトの名無しさん2008/06/30(月) 22:41:09
{} を強制するなら elseif キーワードが必要
0338デフォルトの名無しさん2008/07/01(火) 03:21:06
ブラを強制するのなら、elseの禁止も合わせてやったほうが良いかも？

よくね〜よw。
なるべくブラ着用。elseの多用は可愛気がないぜ。といったところ。
0339デフォルトの名無しさん2008/07/01(火) 04:43:44
コーディングするためのユーザインタフェースが、
事故を未然に防ぐべく何かするのが第一だろ

いつまでも
紙に鉛筆でプログラムを書くレベルに留まるな
0340デフォルトの名無しさん2008/07/27(日) 00:00:15
>337
なぜに?
0341デフォルトの名無しさん2008/07/27(日) 02:59:30
elseifがないと
if () {
} else {
　if () {
　} else {
　　if () {
　　} else {
　　　if () {
　　　} else {
　　　}
　　}
　}
}
みたいにどんどんネストが深くなる。
0342デフォルトの名無しさん2008/07/27(日) 03:00:38
{} を省略できるなら
if () {
} else if () {
} else if () {
} else if () {
} else {
}
みたいに書けるんだけど
0343デフォルトの名無しさん2008/07/27(日) 03:06:05
強制する←→省略不可だからそういうのも認めないって話じゃねーの。
0344デフォルトの名無しさん2008/07/27(日) 03:27:46
というか、>>1の主張を強制するのならelse ifという慣用表現も禁止で
>>341みたいにきちんとif文をネストするような表現とすることを
強制するべき。
>>342式を禁止するというか非推奨にするのは、それなりに根拠がある。
多くの場合、>>342の形式の場合、ロジックが練れていなく、
バグが多い割に修正が難しいから。経験的に言って>>341式のほう
が、バグも少なくなり、バグが出ても修正しやすいような気がする。
結論的に言えば>>342式を禁止するのは一定の意味を持つが
>>1を強制するのはやり過ぎかも。
0345デフォルトの名無しさん2008/07/27(日) 04:11:17
>>342禁止ですら、行き過ぎという感があるのに
>>1強制なんてあり得ない
0346デフォルトの名無しさん2008/07/27(日) 13:36:09
なる。
それなら俺は {} 強制で else if 容認かな。

自分のバグ元としては {}なしのif より 比較に = 使っちゃう方が多いけど。
だから、エディタで[^><=]=[^=] を赤くなるようにしてる。
0347デフォルトの名無しさん2008/07/28(月) 15:32:25
caseで
0348デフォルトの名無しさん2008/07/28(月) 17:42:41
多くの場合、経験的に言って、根拠があると言っているわりに>>344は主観推論しか言っていない気がする。
0349デフォルトの名無しさん2008/07/28(月) 21:13:28
case式が強力な言語ならいいんだけどCだと定数との比較しかできない
0350デフォルトの名無しさん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的な使い方だと誤解して順序を変えてしまうと、意味が変ってしまう。
0351デフォルトの名無しさん2008/10/01(水) 23:41:42
if(id == typeA && ){}
else if (id == typeB &&){}

って書く奴いるけどなんでswitch文使わないの
バカなのねぇバカなの？
0352デフォルトの名無しさん2008/10/02(木) 09:16:07
>>351
妙な && が気になるが、if で書けば
・コードの行数が少なくて済むので見やすい
・スコープがしっかり認識できて良い
・シンタックスハイラトや自動インデントなど IDE によっては switch の対応が微妙
・if の方がコンパイラが最適化しやすい条件になっている
とかとか。分かってて書いている人なら、別に良いと思うけど？
0353デフォルトの名無しさん2008/10/02(木) 22:17:54
if(id == typeA)
if(id == typeB)
と
if(id == typeA)
else if(id == typeB)
同じ意味だよね？
0354デフォルトの名無しさん2008/10/03(金) 01:40:46
>>353
if (id == typeA) {
...
id = typeHoge;
}
の場合は？

0355デフォルトの名無しさん2008/10/06(月) 12:06:12
>>353
idがconstなら同じ。そうでないなら、>354の可能性がある。
例えば、この関数では全く同じ。
void func(const int id)
{
if (id == typeA) {
funcA();
}
if (id == typeB) {
funcB();
}
}
0356デフォルトの名無しさん2008/10/06(月) 12:18:01
つか、同じじゃないように見えるんだけど？

if(id == typeA)
if(id == typeB)
って、インデント付けると
if(id == typeA)
　if(id == typeB)
だよな？　更に括弧も付けると
if(id == typeA) {
　if(id == typeB) {
　}
}
だよな？
0357デフォルトの名無しさん2008/10/06(月) 13:00:09
>>356
>353が>351を踏まえて書いたかどうかだな。
>353が>351を踏まえずに>356の意味で書いたのだとしたら、
if (id == typeA) if (id == typeB)
は(typeAとtypeBが等しいと言う無謀な前提を仮定しない限り)
if (0)と同じになってしまう。
0358デフォルトの名無しさん2008/10/07(火) 18:07:30
べつに無謀な前提ではないんじゃないか
typeA != typeBでもid == typeAかつid == typeBだったりすると怖いけど
0359デフォルトの名無しさん2008/10/09(木) 12:42:52
>>358
この流れでその前提は、余りに阿呆過ぎる。
最早>351も>353もいないから真意は不明だが。
0360デフォルトの名無しさん2009/04/08(水) 19:34:44
ダメ
0361デフォルトの名無しさん2009/08/26(水) 18:28:00
{}をつけないせいで失敗するほど不注意なら{}をつけたせいで失敗する事もありそう
0362デフォルトの名無しさん2009/08/31(月) 11:56:11
こういうバカなやつもプログラム書いてるのが問題なんだよね
0363デフォルトの名無しさん2009/09/01(火) 02:47:11
？
0364デフォルトの名無しさん2009/09/01(火) 07:59:27
凡人と初心者は{}付けとけば問題なし。
0365デフォルトの名無しさん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
>>365
上級者はふつーに省略して、省略するなって主張してるのって、2chの名無しとか
素人くさいプログラム系のブログってイメージ。
0369デフォルトの名無しさん2009/09/04(金) 02:03:58
オフサイドルール大勝利
0370デフォルトの名無しさん2009/09/04(金) 20:36:44
っていうか{}省略で起こる問題って具体的にどんなことがあるんだ？
if(){
func1();
}
else
func2();

ふつうにインデントしてれば何も間違えよう無いし{}省略で
間違えたことなんて一度もねーぞ。
0371デフォルトの名無しさん2009/09/04(金) 20:51:54
>>1本人のコーディングトラブルの 70% だそうなので
皆さんは気にしなくていいですよ
0372デフォルトの名無しさん2009/09/04(金) 23:38:11
俺は省略しないんだが、省略したら今の三倍もバクが増えるとは
とても思えないんだが。
0373デフォルトの名無しさん2009/09/05(土) 08:52:10
さすがに70%はありえないな。
{}省略で間違えることはあまり無い。
ただ、else節以降でインデントを間違えてるソースを見た事は2回ぐらいある。
あれは悩ましいからやめてくれ。

初心者のうちは間違いようの無いシンプルなルールで書いて、
他の部分に頭を使った方がいい。
もちろん天才とベテランは別。
0374デフォルトの名無しさん2009/09/08(火) 09:41:31
>>372
バグをバクとtypoするようなレベルの奴が言っても
0375デフォルトの名無しさん2009/09/08(火) 12:26:48
ﾜﾛﾀ
0376デフォルトの名無しさん2009/09/08(火) 14:08:44
　　,ｨ─--、　　　,ｨ─--、　　　,ｨ─--、
　 (_/　(ヽ'ヽ。　(_/　(ヽ'ヽ。　(_/　(ヽ'ヽ。
　 ヽ　゛д ノ　　ヽ　゛д ノ　　ヽ　゛д ノ　　＜三倍に増えるぞな！
　　ﾉ　∪　|　　　ﾉ　∪　|　　　ﾉ　∪　|
　 ,ゝ、　 .ノ　　 ,ゝ、　 .ノ　　 ,ゝ、　 .ノ
　　　|＿(　　　　　|＿(　　　　　　|＿(
0377デフォルトの名無しさん2009/09/08(火) 22:26:47
2chの書き込みのタイポごときで揚げ足取ったつもりで得意顔？
みっともね。
0378デフォルトの名無しさん2009/09/09(水) 09:35:16
>>377
手がすべったtypo、意図的なものとして定着したtypoならそうかもしれんが、明らかに違うよな。本人乙。
0379デフォルトの名無しさん2009/09/09(水) 11:13:43
>>378
JISカナ配列使いかも知らん。
0380デフォルトの名無しさん2009/09/09(水) 11:59:17
そもそもコーディング時のミスの話してる時に書き間違いの書き込みしてるんだから
間違いは起こりうると証明してるようなもん。
0381デフォルトの名無しさん2009/09/09(水) 12:02:32
>>380
>そもそもコーディング時のミスの話してる時
「{}を省略することによる」という前提外すなよ。
0382デフォルトの名無しさん2009/09/09(水) 14:42:40
世の中qwertyでローマ字入力ばかりだと思ってんのかよ。
0383デフォルトの名無しさん2009/09/10(木) 09:22:19
カナ入力するプログラマなんて死ねばいいけどね
0384デフォルトの名無しさん2009/09/10(木) 11:42:18
>>383
自分の前に使ってた人がカナロックしっぱなしで
うっかり「ﾄﾝﾄｶｲﾓ」とか入れちゃったとか、そういう被害にでも遭ったのか？
0385デフォルトの名無しさん2009/09/10(木) 22:26:26
懐かしいな、ﾄﾝﾄｶｲﾓ。
0386デフォルトの名無しさん2009/09/12(土) 16:20:26
有限会社ﾊﾆﾘｲﾄってのがあってちょっとクスッときた
0387デフォルトの名無しさん2009/09/14(月) 04:05:51
カナ無刻印キーボード使ってるんで面白さがわからん。
解説してくれ。
0388最後の二つはNECとNTT2009/09/14(月) 09:17:47
>>387

トントカイモ→system
ハニリイト→files

パソ通の時代は、みんな覚えていたもんさw
ミイソの98でミミカ経由で繋いでたからね。
0389デフォルトの名無しさん2009/09/14(月) 14:20:41
ミカカでしょ
リニトカとかスナミとかもやったなあ
03903882009/09/14(月) 15:18:38
おー、typoだ。失敬。
0391デフォルトの名無しさん2009/09/17(木) 11:51:39
俺も一行なら省略してたけど、別にそれでトラブルったことはないな。
それより、結局処理追加する必要があると分かった時に挿入したり、
逆に一行でいいと分かった時に整合性のために削除してることが多いのに気付いて
めんどいから最近は {} 非省略派になった。
0392デフォルトの名無しさん2009/09/17(木) 13:44:44
俺の場合は{}を使ってifやループでやる処理をぱっと見て分かるように囲ってる。
if(hogehoge){
　　...;
　　...;
}
とか
if(hogehoge){ ...; }
とか。
ブレース使っても短い処理なら1行で記述できるし省略の必要性は全く感じてない。
0393デフォルトの名無しさん2009/09/17(木) 13:52:53
ifと括弧の間に空白のないコードの70%は糞。
ときには、条件に一致した場合の処理を同一行に書く、上級糞コードも。
0394デフォルトの名無しさん2009/09/17(木) 14:04:44
フォーマッター使えばどうにでもなるような事をグジグジ言ってる暇があるなら
もっとマシなコード書けよ。
くっだらねえ。
0395デフォルトの名無しさん2009/09/17(木) 14:54:09
確かに、スペースポリシーって些細なようでその人の性格が出るな。
統一感がなかったり、合理性がない書き方をする奴は確かにコード自体も質が悪い傾向にある。
ところでたまに

if (続行条件) {
　続行処理...
} else {
　終了処理...
}

みたいなのと

if (終了条件) {
　終了処理...
}

続行処理...

どっちがいいのか迷うんだけど、（無駄にブロック作りたくないから後者にしてるけど）
こういう制御構文の使い分けのケーススタディみたいなのが
詳しく載ってるサイトとか書籍ってないのかな。
0396デフォルトの名無しさん2009/09/17(木) 15:18:38
>>1
ジョークかと思ったら、本気みたい。
0397デフォルトの名無しさん2009/09/18(金) 09:51:54
>>395
それだけじゃよく判らんが、無駄にブロックを作りたくないなら
if (! 続行条件) {
　終了処理...
}
続行処理...
とするか
if (続行条件) {
} else {
　終了処理...
}
続行処理...
としてもいいよね。
0398デフォルトの名無しさん2009/09/19(土) 12:11:51
"else if"をひとつながりで一つのキーワードにしてみるのはどうだろう。
マイクロソフトならやりかねない
0399デフォルトの名無しさん2009/09/23(水) 11:58:27
ほかの言語にはelifつーものがあってだな
0400デフォルトの名無しさん2009/09/24(木) 00:02:47
if 〜 else if は if 〜 else と違って if に対して処理が対象ではないから、
勘違いする人のためには elif が有ってもいいかもね。ダサイけど。
0401デフォルトの名無しさん2009/09/25(金) 11:04:48
>398はどれへのレスなんだ?
少なくとも>395はelse ifの話なんて全然してないわけだが。
0402デフォルトの名無しさん2009/09/25(金) 14:46:22
>>394
書かれたコードを問題にしているのではない。
書いた阿呆の無能さを問題にしているのだ。
0403デフォルトの名無しさん2009/09/27(日) 18:19:52
eclipseで自分仕様のスタイルが設定できなくて困る
一度間違ってソースが全部整形されてしまって、ヒストリで元に戻そうにも
そのミスをやってしまったのがかなり前だと判明したため泣きながら手作業で修正した
0404デフォルトの名無しさん2009/09/27(日) 18:31:08
そこで bc ですよ。
0405デフォルトの名無しさん2009/09/28(月) 11:20:30
暫くindentを改造して使っていたが、思い通りにいかないことが増えてきて捨てた。
今は必要なときに必要なところだけエディタで整形している。
0406デフォルトの名無しさん2009/09/28(月) 21:29:02
ideやら整形ツールで対応できないような一般的でないスタイルは捨てるというのはどうだろうか。
0407デフォルトの名無しさん2009/09/30(水) 15:01:54
エディタを俺仕様にカスタマイズするのは大分前にやめた。
自分をエディタに合わせる方が楽。
0408デフォルトの名無しさん2009/11/23(月) 20:43:16
ガード節による入れ子条件記述の置き換え
1. メソッドに正常ルートが不明確な条件付振る舞いがある
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 つでいいが、そうでなければ使うべきではない
■ このスレッドは過去ログ倉庫に格納されています