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

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

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

1行文だろうがなんだろうが
最初から中括弧をつけるクセをつけろ
0280デフォルトの名無しさん2007/03/19(月) 07:18:05
条件文がすげー長かったら？
やっぱ１行でもブロックにする？
0281デフォルトの名無しさん2007/03/19(月) 07:27:01
条件式を関数なりマクロなりに分けて良い感じの名前を付ければおけ。
そういう時ローカル関数使える言語だといいんだけどな。
0282デフォルトの名無しさん2007/03/19(月) 08:29:05
ローカル関数は欲しいねえ・・
0283デフォルトの名無しさん2007/03/19(月) 08:35:21
C++;なら関数内で定義したクラス/構造体のメソッドで代用出来るけどな
0284デフォルトの名無しさん2007/03/19(月) 08:44:43
無理やりそんなことしても読みにくくなるだけだろ。
読みやすくすることが目的なのに。
02852792007/03/19(月) 20:21:25
>280
うん。条件が長い時もブレースにする。
もしくは条件式の閉じ括弧を実行文の行に持ってくる。
これなら俺は間違えない。集団ならやらんけど。

if(
　　条件式
) 実行文;

BASICで育ったんで一行IF／ブロックIFが基本、
長い時はブロック化するかこうしてたからなー。
IF 〜 _
THEN 実行文
0286デフォルトの名無しさん2007/04/03(火) 13:47:00
自分所のコーディングルールは、

if (式) 文1つ ;

if (式) {
複数の文
}

のいずれか片方のみ可。
0287デフォルトの名無しさん2007/04/03(火) 14:34:40
ルール作るなら、常にブロック使えやコラにした方が良くね？
0288デフォルトの名無しさん2007/04/03(火) 14:35:55
ガチガチだと読みにくくなるよ・・・
0289デフォルトの名無しさん2007/04/03(火) 14:49:39
if (式)
{
　・・・
}

これに統一すると美しい
0290デフォルトの名無しさん2007/04/03(火) 14:58:54
主観
0291デフォルトの名無しさん2007/04/11(水) 06:53:45
>>289
自分には美しく見えない。

変数のスコープのために、
{
何か
{
何か
}
何か
}
という書き方をする場合があるので、
if (式)
{
何か
}
という書き方を許してしまうと、{ が現われたとき、
if (式)


{
何か
}
という可能性を考えて、前方向をチェックしなくてはならない。
if (式) {
何か
}
というように同じ行に書くように強制すれば、見てすぐにわかる。
if (式) と { が生き別れになってしまうこともない。
0292デフォルトの名無しさん2007/04/11(水) 11:19:49
そんなのは、常に整形ツール使えって事でいいじゃないか。

そのルールが気に入らない場合は、自分が読む時に整形しなおせばいい。
そして、読み終わったら元に戻すと。
0293デフォルトの名無しさん2007/04/11(水) 11:36:07
よっぽどものすごい書き方してなきゃだいたい読めるし、
書くときはまわりに合わせりゃそれでいいじゃないの。
こんなのが原因でトラブるやつは他の原因でもっとトラブるよ。
0294デフォルトの名無しさん2007/04/11(水) 12:55:21
>>291
つ[c++ or c99]
0295デフォルトの名無しさん2007/04/11(水) 14:17:17
TCLではブレース次行じゃダメなんだよな
0296デフォルトの名無しさん2007/04/11(水) 22:35:26
>>295
そうなのか。
あれは、それぞれがシェルコマンドみたいなもんだからな。
0297デフォルトの名無しさん2007/04/12(木) 19:54:03
Tclは改行した時括弧の中じゃなかったら
そこでバッサリ文末になるからな
0298デフォルトの名無しさん2007/04/12(木) 20:55:47
Rubyは、改行したところまでで文が成立する場合は次の行は別の文扱いだな。

二項演算式の途中とか対応するカッコを閉じる前のような、文が未完結である
ことがわかる場合は途中改行ができる。完結しているように見える場合は、
¥を付けて明示的に継続する必要がある。
0299デフォルトの名無しさん2007/04/12(木) 23:55:43
セミコロンが文の終わり、にしときゃ良かったと思うんだけど
なんでそんなにも ; なくしたかったのかな？
0300デフォルトの名無しさん2007/04/13(金) 00:57:43
毎回行末記号書くよりも、必要な時だけ継続記号使った方が手間がかからないという思想だろう。
0301デフォルトの名無しさん2007/04/13(金) 01:16:58
>299
俺は逆に

何でわざわざ毎回行末を書かなきゃいけないんだ？
行末は普通文末だろ？

と思うぞ。
結局、普段使ってる言語の影響が強いんだと思う。

Lisperは文末どころか文の始まりまで毎回書くんだもんな…凄いと思う。
0302デフォルトの名無しさん2007/04/13(金) 09:50:40
Ruby慣れると、C書くとき早速セミコロンを忘れる。
無いほうが自然なんだな、と実感する
0303デフォルトの名無しさん2007/04/13(金) 10:13:04
文脈によらずに継続行書くときは常に\つける方が好み。
0304デフォルトの名無しさん2007/04/13(金) 11:38:37
おまいらFORTRANやCOBOLの時代に逆戻りだな・・・
0305デフォルトの名無しさん2007/04/13(金) 14:28:13
>304
むしろ、その時代はカラム制限があったから
セミコロン文末の方が利点が多かったろうに
ある程度のカラムが扱えるなら継続行のみ明示で良いと思うぞ
どうせそんな滅茶苦茶長い行書かないし

…ああ、C言語は使うAPIによっちゃ長い行が普通になるのか
0306デフォルトの名無しさん2007/04/13(金) 19:18:25
>>301
Lisperにはカッコは見えていないし意識して入力もしてないｗ
0307デフォルトの名無しさん2007/04/13(金) 19:56:09
>306
そういうモノなのかｗ
他言語の人（俺含）から見れば大量の括弧の方が目につくんだがな〜
0308デフォルトの名無しさん2007/04/13(金) 20:56:19
>>307
begin endが目につくpascalとか
:-が目につくprologとか
{}が目につくCとか
<>が目につくXMLとか
0309デフォルトの名無しさん2007/04/13(金) 21:57:00
インデントしてたらそんなに目に付くもんでもないんじゃない？
0310デフォルトの名無しさん2007/04/14(土) 01:53:45
セミコロンなしで行末で文末としてしまうと、

class hoge { どわーーー}
という具合に1行に書かないといけなくなりますぞ。
0311デフォルトの名無しさん2007/04/14(土) 09:42:14
どわーーーでなぜか和んだ。
0312デフォルトの名無しさん2007/04/14(土) 09:43:53
>310
そういう言語は
・閉じ括弧が少ない場合はブロックが継続する
・構文でブロックを示すからendが来るまでブロックが継続する
のどちらかを備えてるだろ普通。

Tclは前者。
BASICやCOBOLは後者。
Rubyは両方使ってるな。
Pythonはインデントでブロックを示すんだっけ？
0313デフォルトの名無しさん2007/04/14(土) 12:12:36
Pythonはインデントでブロックを表してて、両方だな。
0314デフォルトの名無しさん2007/04/16(月) 22:57:37
途中から良スレになってる気がした
0315デフォルトの名無しさん2007/04/17(火) 04:31:02
気のせいだった
0316デフォルトの名無しさん2007/08/31(金) 11:46:07
age
0317デフォルトの名無しさん2007/09/01(土) 15:23:25
かの有名なカーニハン先生も省略するべきでないと仰っているよ。
0318デフォルトの名無しさん2007/09/01(土) 15:33:26
蟹飯がナンボのもんじゃーい！
0319デフォルトの名無しさん2007/09/01(土) 17:16:33
>>317
K&R、省略しまくりじゃん。
0320デフォルトの名無しさん 2007/09/02(日) 06:09:15
俺はC→JAVA→C++→C#と勉強してきたから
コードブロックよりもセミコロンがない言語が苦手だな
0321デフォルトの名無しさん2007/09/02(日) 18:34:19
セミコロンは文の区切りです。
0322デフォルトの名無しさん2007/09/02(日) 21:58:20
同じセミコロンでもデリミタとして使う言語とターミネータとして使う言語があるのよん。
0323デフォルトの名無しさん2007/09/02(日) 23:07:25
Pascalは文の最後はピリオドだったな。
0324デフォルトの名無しさん2007/09/03(月) 00:46:44
pascal は
○ if a then b else c;
× if a then b; else c; (コンパイルエラー)
Cはどっちも大丈夫
0325デフォルトの名無しさん2007/09/03(月) 01:18:28
Cはどっちも怒られそうだぞ
0326デフォルトの名無しさん2007/09/03(月) 13:06:03
カッコが付かないな
0327デフォルトの名無しさん2007/12/31(月) 03:42:45
Pascalの場合、elseはif文の一部で
セミコロン付けると、そこでif文が終わるから
「文頭にelseはおかしい」って言われるんだよね。
0328デフォルトの名無しさん2008/03/05(水) 17:00:17
c でも else は if 文の一部。

; が文同士のセパレータではなく文の終端記号でしかないから、
b; が 1 文となって問題にならない、ってこと。
0329デフォルトの名無しさん2008/03/15(土) 16:13:12
>>323
プログラムの最後だろ？
0330デフォルトの名無しさん2008/05/04(日) 13:30:52
>>1
COBOLのIF文の歴史を知らないんだな。
0331デフォルトの名無しさん2008/05/06(火) 17:30:21
内容（意味）によらず形式だけで決める
>>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
そもそもコーディング時のミスの話してる時に書き間違いの書き込みしてるんだから
間違いは起こりうると証明してるようなもん。
■ このスレッドは過去ログ倉庫に格納されています