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

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

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

1行文だろうがなんだろうが
最初から中括弧をつけるクセをつけろ
0207デフォルトの名無しさん2007/03/13(火) 00:04:04
>>206
スレタイの数字の話じゃねえの？
0208デフォルトの名無しさん2007/03/13(火) 01:41:45
ぶら下がりelseに起因するbug発生回数は一回
その他の中括弧の省略に起因するbug発生回数は零回
0209デフォルトの名無しさん2007/03/13(火) 02:09:20
どんな書き方をしてもバグを生み出さないソースを書けばいいだけ
どんなにファクターがありそうでも最終的にそこに原因を求めるのは結局責任転嫁だ
0210デフォルトの名無しさん2007/03/13(火) 02:10:42
読みやすい書き方はそれだけでバグの抑制になる
0211デフォルトの名無しさん2007/03/13(火) 05:57:35
インクリメントとかシンプルな処理なら｛｝なんて使わなくても
使うのは数行に渡る見込みがあるか後々まで残す部分くらいだな
0212デフォルトの名無しさん2007/03/13(火) 08:01:55
やはりbegin〜endの勝利だな
0213デフォルトの名無しさん2007/03/13(火) 09:26:05
Python最強ということで
0214デフォルトの名無しさん2007/03/13(火) 09:35:13
schemeもええで
0215デフォルトの名無しさん2007/03/13(火) 09:48:34
ソレより、 && || をif文中で使ってる場合の方が多いように思うけどな

特に俺が書いた時に無かったのに後から何気なく追加されたような場合、たいてい間違ってるゾ！
0216デフォルトの名無しさん2007/03/13(火) 11:02:09
70%はそっちの方だね。
0217デフォルトの名無しさん2007/03/13(火) 11:08:56
まだ && ||を２行に別けて書く人はミスが少ない気がする

if( ( hoge == hage )
&& ( hige ) ){
}
みたいに
0218デフォルトの名無しさん2007/03/13(火) 11:12:50
こういうのは程度の問題で、複雑な式は分けて書いた方が理解しすいだろうが、
シンプルな式まで徹底して分ける事に決めちゃったりしたら、かえってコードの意図がわかりにくくなると思う。
{}の省略についても同様。
0219デフォルトの名無しさん2007/03/13(火) 11:39:36
if修飾子が使える言語(PerlやRuby)だと、やることが1つなら修飾子にして
おいて、増えたら複文支配のifに書き換える、という使い分けが出来るな。
0220デフォルトの名無しさん2007/03/13(火) 13:07:20
むしろ後置ifが使えるなら、
前置ifでの単文修飾は不可能にすべきじゃなかろうか。
0221デフォルトの名無しさん2007/03/13(火) 13:16:18
perlはそうだね。
0222デフォルトの名無しさん2007/03/13(火) 14:06:40
俺はPBP6.2の通りに後置ifはnext, last, redo, return, goto, die, croak, throwでのみ使うようにしてる。
メンテ不要な書き捨てプログラムはこの限りでないがw
0223デフォルトの名無しさん2007/03/13(火) 22:45:43
if文より型の変換とか値入れてない変数とかの方がやばい気がする。
0224デフォルトの名無しさん2007/03/13(火) 22:46:14
全ての分岐をgoto文で書いてやる
0225デフォルトの名無しさん2007/03/13(火) 23:02:08
gotoが必要なのは多重ループを抜けるときだけだよな。
0226デフォルトの名無しさん2007/03/13(火) 23:14:43
ttp://gedo-style.net/g/?v=361721&d=d.jpg
0227デフォルトの名無しさん2007/03/14(水) 00:27:29
多重ループは関数化で対処
0228デフォルトの名無しさん2007/03/14(水) 04:07:30
gotoはエラー処理と字句解析のハードコード。
0229デフォルトの名無しさん2007/03/14(水) 04:48:53
if()
{
;
}

↑これは異端か？
0230デフォルトの名無しさん2007/03/14(水) 05:29:00
異端もクソも、なぜ if() の中を ! で否定しないよ
0231デフォルトの名無しさん2007/03/14(水) 06:53:59
頭ごなしに否定するのはよくない
0232デフォルトの名無しさん2007/03/14(水) 10:31:18
ケツで否定してやる。

{ ; } unless hoge;
0233デフォルトの名無しさん2007/03/14(水) 10:41:26
{ } を付けたら女の子にもてるようになりました
0234デフォルトの名無しさん2007/03/14(水) 17:09:17
スーパー括弧閉じ
0235デフォルトの名無しさん2007/03/14(水) 17:26:03
括弧閉じはコッカって言わないか？
0236デフォルトの名無しさん2007/03/14(水) 19:21:20
通じるけど恥ずかしいから自分では言わない。
0237デフォルトの名無しさん2007/03/15(木) 16:12:21
>>235
それは局所的にしか通じないだろう。
0238デフォルトの名無しさん2007/03/15(木) 16:57:00
sh 系だとそんなだよな。

esac ってなんだろと。
0239デフォルトの名無しさん2007/03/15(木) 17:06:36
fi はまあ想像つくけどなｗ
0240デフォルトの名無しさん2007/03/16(金) 22:54:36
言語規格の中で if() ; 形を if() { ; } の省略形であるとしている
言語はどんなものがありますか。
0241デフォルトの名無しさん2007/03/16(金) 23:11:15
そんなのあるのか？
0242デフォルトの名無しさん2007/03/17(土) 13:24:53
お前らエディタのソース整形機能とか使ったことなさそうだな
0243デフォルトの名無しさん2007/03/17(土) 13:25:18
COBOLにそんな機能ねーよ
0244デフォルトの名無しさん2007/03/17(土) 13:43:26
ソース整形が必要なほどのクソコードに出会ったら
とりあえず腹をくくることにしている。
0245デフォルトの名無しさん2007/03/17(土) 13:51:37
おまえはソース整形について誤った観念を抱いているのではないか
0246デフォルトの名無しさん2007/03/17(土) 13:52:38
ソーッスねぇ
0247デフォルトの名無しさん2007/03/17(土) 14:27:11
ソース整形したらテスト全部やり直しなんだけどそれついてはどうなの？
0248デフォルトの名無しさん2007/03/17(土) 14:29:25
>>247
なんで？
0249デフォルトの名無しさん2007/03/17(土) 14:33:05
>>248
あ？遊びでやってんじゃねーんだぞ
0250デフォルトの名無しさん2007/03/17(土) 14:34:46
>>247
kwsk
0251デフォルトの名無しさん2007/03/17(土) 14:37:04
バイナリがかわんなきゃよくね？
or
テストケース再実行すりゃいいじゃん

好きなほうで
0252デフォルトの名無しさん2007/03/17(土) 14:40:18
テストする前に整形すればいいだけじゃん
0253デフォルトの名無しさん2007/03/17(土) 14:41:43
リポジトリにコミットするとき、自動的にソース整形すりゃよくね？も追加
0254デフォルトの名無しさん2007/03/17(土) 14:45:04
>>247は自動化したテストですらとんでもなく時間を食う
ちょー大規模プロジェクトをやってるんだろう。
0255デフォルトの名無しさん2007/03/17(土) 14:49:30
>>251
＞バイナリがかわんなきゃよくね？
これは納得できる

＞テストケース再実行すりゃいいじゃん
手動のテストケースもあるから無理
仮に全自動であったとしても時間無駄にしてんじゃねーよ

>>252
ソース整形しただけの個所までテストするのが時間の無駄

>>253
改行した瞬間に自動的にソース整形するVBが最適解か……orz
0256デフォルトの名無しさん2007/03/17(土) 14:53:35
やはりpythonが・・・
0257デフォルトの名無しさん2007/03/17(土) 14:54:49
>>255
時間かかるテストは、夜走らせとけよ

エディタorIDE
↓
リポジトリ(コミット時にソース整形)
↓
CI(夜間に自動ビルド＋テスト)

これ大抵の言語でいけるだろ。
0258デフォルトの名無しさん2007/03/17(土) 16:57:26
バイナリが変わるようなコード変換はもはや整形じゃないと思う
0259デフォルトの名無しさん2007/03/18(日) 01:12:11
>>175
そんなの^(unsigned)*[int|char|short|float|double] [a-Z]+[0-9|a-Z]*\(とかで検索すればいいんじゃね？
0260デフォルトの名無しさん2007/03/18(日) 01:20:04
無理やりこうやればできるとかいう話じゃなくってさ。
viでは検索が日常的なカーソル移動手段のひとつなんだよ。
0261デフォルトの名無しさん2007/03/18(日) 01:34:57
>>259
ぜんぜんだめ。おはなしにならない。
0262デフォルトの名無しさん2007/03/18(日) 01:51:22
C言語は文脈自由文法だから正規表現で完璧にマッチさせるのは不可能
0263デフォルトの名無しさん2007/03/18(日) 05:35:27
>>262 こういう話疎いので、初心者にも解るように解説してください。
0264デフォルトの名無しさん2007/03/18(日) 07:02:14
>>263
コンパイラの本でも嫁
0265デフォルトの名無しさん2007/03/18(日) 11:30:39
突然舞い上がったようなレスだな。>>262は
そもそもどのレスに依存するのだろう。
0266デフォルトの名無しさん2007/03/18(日) 11:33:56
259のあたりだろ。
0267デフォルトの名無しさん2007/03/18(日) 11:41:31
>>265が>>262を全く理解できなかったということだけはわかった。
0268デフォルトの名無しさん2007/03/18(日) 11:50:27
まあ規約ガチガチなのはそのせいだしな
0269デフォルトの名無しさん2007/03/18(日) 13:40:30
正規表現に疎い俺に>>173はどういう正規表現を書いているのか教えて欲しい。
0270デフォルトの名無しさん2007/03/18(日) 13:49:32
そこらじゅうに未定義・未規定・処理系依存が
ぽっかり口をあけているC言語のどの辺がガチガチ？
0271デフォルトの名無しさん2007/03/18(日) 14:23:15
コーディング規約でガチガチにするって意味だよ
02722632007/03/18(日) 18:26:20
そんな連関、聞いたこと無いけどな。
0273デフォルトの名無しさん2007/03/18(日) 19:16:41
>>263
かっこが自由に無制限に入れ子に出来るパターンは
正規表現じゃ理論上無理らしいよ
0274デフォルトの名無しさん2007/03/18(日) 20:28:25
正規文法と文脈自由文法でぐぐってみ
0275デフォルトの名無しさん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.

そういうこっちゃ．
0276デフォルトの名無しさん2007/03/18(日) 21:01:57
だかPerlとかの変態拡張性器表現ならきっと・・・
0277デフォルトの名無しさん2007/03/18(日) 21:11:13
Perlのは正規表現の中でPerlのコードを評価できたりするからある意味万能
0278デフォルトの名無しさん2007/03/19(月) 00:02:33
つまりゲストのお客さんが自由に参加すると収拾がつかなくなるので、
レギュラーのメンツだけでやってくれ、というわけですね。
0279デフォルトの名無しさん2007/03/19(月) 05:52:30
結構前の話題だが

俺は例えば if なら
if(式) 文;
文が一行で、かつこの行が長くならない場合だけ { } を使わずに書くかなぁ。
if(式)
　　文;
と書くぐらいならブレースを使ってる。
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
そういうモノなのかｗ
他言語の人（俺含）から見れば大量の括弧の方が目につくんだがな〜
■ このスレッドは過去ログ倉庫に格納されています