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

>>358
この流れでその前提は、余りに阿呆過ぎる。
最早>351も>353もいないから真意は不明だが。

ダメ

{}をつけないせいで失敗するほど不注意なら{}をつけたせいで失敗する事もありそう

こういうバカなやつもプログラム書いてるのが問題なんだよね

？

凡人と初心者は{}付けとけば問題なし。

初心者ほど{}を省略するからな。
そして成長しないまま{}を省略し続けると。

{}を付ける癖がつくと、すべてのロジックをそのルーチンの中に
詰め込み、使い回せる関数だけを外側に出そうとする癖がつく？
本当に使い回せるかどうかの判断は実は相当のベテランでも
ない限り難しいにも関わらず。

{}を付けない癖がつくと、すべて下請けに回そうというコード
になりがち。最初は調子が良いが硬直なコードになりがちなので
仕様変更時に泣きを見る結果になりやすい？

初心者は何度も書き換えて、コードが増えたり減ったりを繰り返す。
構造もあやふやだろうし、{}無しで使ってコケる。それも勉強だろうけど、
{}を付けて処理範囲を明確にすれば、最低限コケることは無くなる。
{構造化を意識させることもできる(その地点からはだいぶ先の話だけど)。

>>365
上級者はふつーに省略して、省略するなって主張してるのって、2chの名無しとか
素人くさいプログラム系のブログってイメージ。

オフサイドルール大勝利

っていうか{}省略で起こる問題って具体的にどんなことがあるんだ？
if(){
func1();
}
else
func2();

ふつうにインデントしてれば何も間違えよう無いし{}省略で
間違えたことなんて一度もねーぞ。

>>1本人のコーディングトラブルの 70% だそうなので
皆さんは気にしなくていいですよ

俺は省略しないんだが、省略したら今の三倍もバクが増えるとは
とても思えないんだが。

さすがに70%はありえないな。
{}省略で間違えることはあまり無い。
ただ、else節以降でインデントを間違えてるソースを見た事は2回ぐらいある。
あれは悩ましいからやめてくれ。

初心者のうちは間違いようの無いシンプルなルールで書いて、
他の部分に頭を使った方がいい。
もちろん天才とベテランは別。

>>372
バグをバクとtypoするようなレベルの奴が言っても

ﾜﾛﾀ

　　,ｨ─--、　　　,ｨ─--、　　　,ｨ─--、
　 (_/　(ヽ'ヽ。　(_/　(ヽ'ヽ。　(_/　(ヽ'ヽ。
　 ヽ　゛д ノ　　ヽ　゛д ノ　　ヽ　゛д ノ　　＜三倍に増えるぞな！
　　ﾉ　∪　|　　　ﾉ　∪　|　　　ﾉ　∪　|
　 ,ゝ、　 .ノ　　 ,ゝ、　 .ノ　　 ,ゝ、　 .ノ
　　　|＿(　　　　　|＿(　　　　　　|＿(

2chの書き込みのタイポごときで揚げ足取ったつもりで得意顔？
みっともね。

>>377
手がすべったtypo、意図的なものとして定着したtypoならそうかもしれんが、明らかに違うよな。本人乙。

>>378
JISカナ配列使いかも知らん。

そもそもコーディング時のミスの話してる時に書き間違いの書き込みしてるんだから
間違いは起こりうると証明してるようなもん。

>>380
>そもそもコーディング時のミスの話してる時
「{}を省略することによる」という前提外すなよ。

世の中qwertyでローマ字入力ばかりだと思ってんのかよ。

カナ入力するプログラマなんて死ねばいいけどね

>>383
自分の前に使ってた人がカナロックしっぱなしで
うっかり「ﾄﾝﾄｶｲﾓ」とか入れちゃったとか、そういう被害にでも遭ったのか？

懐かしいな、ﾄﾝﾄｶｲﾓ。

有限会社ﾊﾆﾘｲﾄってのがあってちょっとクスッときた

カナ無刻印キーボード使ってるんで面白さがわからん。
解説してくれ。

>>387

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

パソ通の時代は、みんな覚えていたもんさw
ミイソの98でミミカ経由で繋いでたからね。

ミカカでしょ
リニトカとかスナミとかもやったなあ

おー、typoだ。失敬。

俺も一行なら省略してたけど、別にそれでトラブルったことはないな。
それより、結局処理追加する必要があると分かった時に挿入したり、
逆に一行でいいと分かった時に整合性のために削除してることが多いのに気付いて
めんどいから最近は {} 非省略派になった。

俺の場合は{}を使ってifやループでやる処理をぱっと見て分かるように囲ってる。
if(hogehoge){
　　...;
　　...;
}
とか
if(hogehoge){ ...; }
とか。
ブレース使っても短い処理なら1行で記述できるし省略の必要性は全く感じてない。

ifと括弧の間に空白のないコードの70%は糞。
ときには、条件に一致した場合の処理を同一行に書く、上級糞コードも。

フォーマッター使えばどうにでもなるような事をグジグジ言ってる暇があるなら
もっとマシなコード書けよ。
くっだらねえ。

確かに、スペースポリシーって些細なようでその人の性格が出るな。
統一感がなかったり、合理性がない書き方をする奴は確かにコード自体も質が悪い傾向にある。
ところでたまに

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

みたいなのと

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

続行処理...

どっちがいいのか迷うんだけど、（無駄にブロック作りたくないから後者にしてるけど）
こういう制御構文の使い分けのケーススタディみたいなのが
詳しく載ってるサイトとか書籍ってないのかな。

>>1
ジョークかと思ったら、本気みたい。

>>395
それだけじゃよく判らんが、無駄にブロックを作りたくないなら
if (! 続行条件) {
　終了処理...
}
続行処理...
とするか
if (続行条件) {
} else {
　終了処理...
}
続行処理...
としてもいいよね。

"else if"をひとつながりで一つのキーワードにしてみるのはどうだろう。
マイクロソフトならやりかねない

ほかの言語にはelifつーものがあってだな

if 〜 else if は if 〜 else と違って if に対して処理が対象ではないから、
勘違いする人のためには elif が有ってもいいかもね。ダサイけど。

>398はどれへのレスなんだ?
少なくとも>395はelse ifの話なんて全然してないわけだが。

>>394
書かれたコードを問題にしているのではない。
書いた阿呆の無能さを問題にしているのだ。

eclipseで自分仕様のスタイルが設定できなくて困る
一度間違ってソースが全部整形されてしまって、ヒストリで元に戻そうにも
そのミスをやってしまったのがかなり前だと判明したため泣きながら手作業で修正した

そこで bc ですよ。

暫くindentを改造して使っていたが、思い通りにいかないことが増えてきて捨てた。
今は必要なときに必要なところだけエディタで整形している。

ideやら整形ツールで対応できないような一般的でないスタイルは捨てるというのはどうだろうか。

エディタを俺仕様にカスタマイズするのは大分前にやめた。
自分をエディタに合わせる方が楽。

ガード節による入れ子条件記述の置き換え
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 つでいいが、そうでなければ使うべきではない