コーディングスタイルにこだわるスレ

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
2009/04/17(金) 17:10:55
> 後、関数の出口の return が必ず末尾の一つだけってプロジェクトに
> 参加したことがあるけど、処理の条件が変わっても、メモリリークが
> 出にくい構造になるのは良いと思った

これは結局ケースバイケースで、関数的（副作用がない）なコードが主か、
副作用とかバリバリか、で変わってくるよね。
あと、例外的な場合の処理にgotoを許すか、とか。
2009/04/17(金) 17:44:38
>中々見つけにくいんだな、このバグ
最近のコンパイラなら確実にwarning出すんでそうでも無い
2009/04/17(金) 22:26:29
ついでに言えば、比較対象が0ではなくて変数だったらやっぱり検出できないから殆ど意味がない。
2009/04/18(土) 01:02:21
RAII 使え、 const 付けとけ、って話でもあるな。
2009/08/21(金) 17:39:24
まぁOOPが不可能なプロジェクトなら、そういうリーク対策にも意味はあるかもしれんね
OOPが可能なら、RAII（厳密にはデストラクタによる資源解放）の徹底も可能だよな
2009/08/31(月) 12:09:43
>>269
C/C++で、zeroとの比較をするのであれば、
if (hoge(var) == 0)とぜすに、if (!hoge(var))の方が目的がはっきりする

比較する数値がたまたまzeroであるのなら、数字で比較すべきではない
定数化された変数を用いるか、#defineマクロで名付けられた定数を用いるべきだ

よって条件式に、数字が書き込まれている時点で何かおかしなコードであると思われる
2009/08/31(月) 12:32:58
>>275
しかしstrcmpの時ははゼロを扱っていいと思う。
2009/08/31(月) 12:38:20
おばかのきわみ > #define ZERO 0
2009/08/31(月) 12:55:27
>>276
その場合、BASE_CMPとか名付けて比較したほうが分りやすい予感
2009/08/31(月) 13:11:50
>>278
少なくとも俺は今、BASE_CMPナニソレ？(´･ω･`)　ってなってるが。
2009/08/31(月) 13:12:58
>>278
CMP_OBJCTじゃね?
2009/08/31(月) 13:15:20
>>275
あほか。
「ゼロと比較する」という処理ならコードにそのまま書いたほうがいいだろｊｋ
2009/08/31(月) 13:22:58
#define STREQ(a, b) !strcmp((a), (b)) みたいなマクロに
2009/08/31(月) 13:28:21
>>282
それなら辛うじて許せるような気もするが、
strcmpくらいそのまま使えよ、ってのが正直なところ。

strcmp(a, b) < 0 // a < b
strcmp(a, b) > 0 // a > b
strcmp(a, b) == 0 // a == b

という、並べて書いた上での法則がせっかくあるのに。
2009/08/31(月) 18:55:48
>>278
わかりやすくねーよ。
イディオムはそのままにするべき。
2009/08/31(月) 19:01:39
strcmpの場合
比較対象と同等か、大きい、もしくは、小さいだから
>>282よりはマシだろ
2009/08/31(月) 19:04:58
>>285
意味不明(´･ω･`)
2009/08/31(月) 19:25:05
>>275
> if (hoge(var) == 0)とぜすに、if (!hoge(var))の方が目的がはっきりする

そんなバナナ

0との比較なら素直に==0、真偽値としての比較ならそのまま、ってのが普通の感覚だと
思うけどなぁ。まぁ最後は主観だからあれだけど。
0をマクロに入れるなんてのは論外。
2009/08/31(月) 19:51:24
NULLの分らんアホばっかだな
2009/08/31(月) 20:10:03
>>287
0との比較の「0」とは何かという話じゃないの？
2009/08/31(月) 20:14:06
>>288-289
お前ら二人は一体なにをいってるんだ？
2009/08/31(月) 21:11:58
NULL自体が要らないマクロ
2009/09/05(土) 23:12:56
初心者なんですが、if (cond == false)って書き方と
if (!cond)ってどちらにすべきですか？
ずっと後者だと思っていたのですが、前者もたまに見かけるので
わからなくなってしまいました。
2009/09/05(土) 23:50:59
>>292
論理定数との比較はそもそもナンセンスなので、前者は論理値に対する理解が
あやしい感じがする。

たいした理由じゃないんだけど、どちらかというと後者にしといたほうがいいと思うよ。
2009/09/06(日) 00:27:29
>>293
ありがとうございます。このまま後者の書き方を続けていきます。
2009/09/06(日) 10:41:39
その cond の名前が ablable とか enabled なら ! allowed のような書き方が良いだろう。
availability とか visibility とかだと、「可視性ですか？」 じゃ頭弱いみたいだから 「可視性は偽ですか」の方が分かりやすいと思う。
専用に enum 作れという話だけど。
2009/09/11(金) 19:06:43
//これはだめ
hoge(foo,bar);

//これはおｋ
hoge(foo, bar);
2009/09/11(金) 20:49:45
http://www.eetimes.jp/content/3107

1TBS って初めて聞いた。
2009/09/11(金) 21:31:02
>297
これ思ったけど、1TBSの方が図2のような間違いは簡単に検出できるような。
（単純に /;\s*{/ で検出できる。オールマンスタイルの場合、ツールによってはマッチしない）

でも個人的にはオールマンスタイルのが好きだけどな。
2009/09/12(土) 07:31:42
俺は1TBSくらいの黒っぽさが好みだな
もちろん黒すぎるのは辛いけど、オールマンだとちょっと白っぽく感じる

まぁこれはさすがに完全に好みの問題だろうと思うな…
2009/09/13(日) 02:47:08
そもそも筆者のコメントを打つ位置が気に入らない。 //行末に書くな
2009/09/13(日) 03:18:16
俺は//の後にスペースがないのが気に入らない
2009/09/13(日) 11:47:43
一番のツッコミどころは比較式の左辺に定数だろ。
303デフォルトの名無しさん
垢版 |
2009/09/25(金) 00:36:47
そもそも
if(!x)
とか
if(!(z=x-N))
とかやることが多いから==使わないな。
2009/09/25(金) 07:48:41
条件式に関数呼び出しを書くなってルールもあったな
2009/09/25(金) 09:26:21
へぇ。どういう理屈でそんなルールが認められるのかさっぱりわからんな。
2009/09/25(金) 10:21:31
>>305
&& や || のショートカットと関数の副作用の関係
f0() || f1() || …
f0 が成立すると f1 以降が評価されないってのを知らないやつがいるそうだ
なので、こう書かなきゃいけない。とてもうざい。
v0 = f0(); v1 = f1(); …
if (v0 || v1 || …)
2009/09/25(金) 10:25:40
>>306
それ、 (s && strlen(s) > MIN) とかいう時はどうすればいいの？
2009/09/25(金) 10:59:33
int len = -1;
if (!s) {
len = strlen(s);
if (MIN < len) {
...
}
}
2009/09/25(金) 11:00:20
!sじゃなくてsなｗ　素で間違えた。
2009/09/25(金) 11:26:08
そんなルールおとなしく守ってるプログラマなんてほんとにいるの？
何なの？ばかなの？しぬの？
2009/09/25(金) 12:08:10
>>310
元請けにコードの監査部隊がいて意地でも書き直させる方法を取っていた
うざくってしょうがなかった
2009/09/25(金) 12:10:14
その監査部隊を短絡評価の講習要員にすればいいのに。
2009/09/26(土) 21:43:06
308の書き方だと、正しく読めない/書けない奴が居るから仕方が無い。
一方、漏れらに308の書き方を強制しても、せいぜい能率が落ちるだけ。

実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。
平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは
冷徹ではあるが正しい方策。
2009/09/26(土) 23:32:37
へぼいコーディングルールの話になると、その理論がよくでてくるけど、実際はコーディングルールを
決めてるやつがヘボいだけだろうな。ほとんどの場合。

それに「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論が、本当に正しいかすごい疑問だし。
2009/09/26(土) 23:42:03
まぁ俺の持論とは真逆だな
ウンココーダの頭数揃えても、精鋭一人にも劣る
2009/09/27(日) 09:34:49
> 実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。
> 平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは
> 冷徹ではあるが正しい方策。

「人月の神話」に燦然と挑戦しているな。
まぁそのような開発分野もあるんだろう。多分。
2009/09/28(月) 09:09:58
「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論は確かに疑問だが、
十分な精鋭を確保できるプロジェクトなんてほとんど無いんだから、大量のヘボが存在
するのは前提だと思う。
加えて上司も無能だと、そのヘボが逐次投入されてチームは恐竜に、プロジェクトは
タールの沼に。
2009/09/29(火) 21:53:42
>316
そうでもないと思うが。
1つのプロジェクトに投入する人員については、「人月の神話」の理論で良いけど、
複数のプロジェクトに人員を配置する場合は、>313の理論の方が適している。

308みないなルールは大規模なプロジェクトほど多く、小規模なプロジェクトほど比較的フリーだろ?
（逆な例もある事は承知している）
2009/09/29(火) 21:57:10
短絡評価が分からないだけならまだしも、「教えても理解できない」という人員なんか
さすがに切り捨てても困らないと思うけどな
2009/09/29(火) 22:31:14
簡単なコードを量産するような人海戦術プロジェクトでも、上位の2,3割だけ使って、
のこりはじゃまにならないように遊ばせておいても、あんがい生産性あがるんじゃないかって気もする。
2009/09/29(火) 23:13:59
>>318
人月の神話、読んでないか忘れてるだろ。

>>319
短絡評価に限って言えばその通りだけど、教えられても理解できない部分は人によって違うから。

>>320
論文報告を楽しみに待ってる。
2009/09/30(水) 00:10:59
どうでもいいけどstrlen()が返すのはintじゃなくてsize_tだよ
2009/10/01(木) 20:40:57
ストレンツォ容赦せん！
2009/10/11(日) 14:52:50
>>318
つまり、たとえば優秀なプログラマなら3ヶ月で終わる仕事を一年かけて
（原則同じくらいの人数で）やるけど、
同時に抱えられるプロジェクト数を増やして会社としてのスケールメリットを得るって話？
要するに節約できるのは総務だの人事だのの管理コストの話であって
プロジェクトそのものの効率は上がってないと思うが…
2009/10/12(月) 02:57:19
>324
プロジェクトの効率は上がらなくても、利益は上げられる罠。
場合にもよるが。
下手すりゃ投入人員と期間を増やせばその分儲かる。

糞ルールがまかり通ってる現場って、大体は上がこんな思想で動いてる希ガス。
2009/10/12(月) 03:57:31
まぁ、その思想を最高だと思って布教しようとしたりしなきゃどうでもいいけどな
2009/10/17(土) 11:55:45
javaで

public void XXX() throws YYY, ZZZ {
}

のthrows以下が長くなると80桁超えますけど見やすい折り返し方ないですか？
eclipseのデフォルトで整形すると

public void XXX() throws YYY,
　　　　ZZZ {
}

とやってくれましたけど見づらいな。
2009/10/17(土) 12:44:58
>>325
思想とか計算づくで、レベル低いんじゃなくて、ただレベル低いだけなんじゃないの?
効率が利益に結びつかないから、淘汰されないだけで。
2009/10/18(日) 21:42:59
>>324
保守要員みたいなところにエース級は投入せんだろ。

むしろ OJT で勉強させるために新人を。。。
2009/10/20(火) 11:51:05
>>327
行が長くなるときどう折り返すか
ttp://java-house.jp/ml/archive/j-h-b/009166.html#body
2009/10/20(火) 12:09:53
C++ 使っててカンマとか演算子の「前」で折り返して、演算子の類が行頭にくるように
してたんだけど、 Python 使い出したらそうもいかなくなって、今は微妙な気持ちです。
2009/10/20(火) 12:20:08
>>331
英語では普通、カンマやセミコロンなどは単語の後ろに空白なしにつける。当然、改行はその後。
演算子もそれに準じる。
2009/10/20(火) 13:57:32
>>331
（ ・∀・）人（・∀・ ）ﾅｶｰﾏ

.append(foo)
.append(bar)
.toString();

+ fooooooooooooooooooooooo
- (baaaaaaaaaar % baaaaaaaaz);

= {
11111111111
, 2222222222
, 3333333333
}

if (
(cooooooooooooooond)
|| (baaaaaaaar && bazzzzzzzz)
)

文末を見るより、文頭を見るほうが目の動きが少ない。
2009/10/20(火) 14:05:42
. を先頭にもってくるのは許せるが、 , を先頭にもってくるのが許せないのはなぜだろう。
2009/10/24(土) 22:25:29
if 〜 else if 〜 else の各節にコメントをつけたいとき、俺はこのように書いているんです。
// こういう場合はこう
if (...)
{
}
// こういう場合はこう
else
{
}

ところが、節を分断するのはよくないと言う人がいるんですね。それはそれで一理あります。
その人はこう書いている。
if (...) // こういう場合はこう
{
}
else // こういう場合はこう
{
}

このやり方だと、条件式が長くなったり複数行にわたると、ちっと面倒なことになる。
みなさん、if文のコメントはどのように書いていますか？
2009/10/24(土) 22:35:25
>>335
if にコメント付いてれば else へのコメントは冗長だろ？考えるだけ無駄。
2009/10/24(土) 23:21:52
冗長なんて言ったらコメントなんて書けなくなる。
それに複数のelse ifがある場合はコメントがあった方がいい。
2009/10/25(日) 00:16:58
>>337
お前はなんのためにコメントが書きたいの？
コメントを書くことが目的なの？
2009/10/25(日) 01:41:21
// コメント
if(...) {
}
else {
// コメント
}
2009/10/25(日) 02:39:09
>>339
俺もそれだ。
2009/10/25(日) 02:43:33
俺はこうだわ。space efficiant!!

if(...) { // コメント
  foo();
} else if(...) { // コメント
  bar();
} else {
  foobar();
}
2009/10/25(日) 07:39:57
漏れは内容に応じて使い分けた方が良いと思うけど。

// 分岐全体について。
if( ... ){　　　// 式について。
　// ブロック内の処理&実行条件の概要
}
else {
　// ブロック内の処理&実行条件の概要
}


（例）
// 〜と〜を切り分ける
if( … 　　// 〜をチェック
&& … ) { // 〜をチェック
　// 〜の場合、〜する
}
else {
　// 〜の場合、〜する
}
2009/10/25(日) 14:06:52
こうしてる
if(...) {
　// ...なら〜
} else {
　// 〜(条件についての記述は無し)
}
2009/11/22(日) 14:45:58
お前ら、そんな面倒なコメントつけるくらいなら
is_こういう場合() っていう関数作ってif に入れとけよ。

どうしてもコメント書きたかったら
is_こういう場合() のところに書けばすっきりしていいだろ。
2009/11/23(月) 06:06:37
>344
それだと is〜() が何をチェックしてるのか知りたくなったら、一々中身を見なきゃ分からないし、
is〜() の条件を変えたくなったら、使ってる場所を全部チェックした上で変更するか、
「使われない関数」が生じるのを覚悟で別な関数を追加しなきゃならん。
（まぁ静的リンクのみなら、コンパイルすれば何処で使ってるかは分かるけど）

is〜()の名称自体は「何を」チェックするかに留めて、「何故」チェックするかとか
条件式全体が何を意味するかとかは、コメントに書く方がよっぽど面倒が無い。
2009/11/23(月) 10:58:02
>>345
> それだと is〜() が何をチェックしてるのか知りたくなったら、一々中身を見なきゃ分からないし、
ちゃんと名前付けて、関数宣言部分にコメント書けば、そんなことにはならないよ。
中身見るのはバグを疑うときぐらい。

> is〜()の名称自体は「何を」チェックするかに留めて、「何故」チェックするかとか
> 条件式全体が何を意味するかとかは、コメントに書く方がよっぽど面倒が無い。
コメントに書いて良いのは「何故」だけだな。
2009/11/23(月) 11:01:17
仕方なくわかりづらいコード書くときしか関数の中にコメントは書かないな
外側に書いたドキュメントだけでいい
2009/11/23(月) 11:01:32
>>345の思考様式だと関数を細かく分けることは悪になりそうだなｗ
適切な名前の関数を作ってどんどん分けるのは常識レベルだと思ってたが
349345
垢版 |
2009/11/23(月) 18:28:36
漏れは>344の言葉をそのまま鵜呑みにすると

　// Hogeの場合
　if ( isFoo() && isBar() )

のようなコードも、コメント付けるより

　if( isHoge() ）

とした方が良いって事になるのを否定しただけです。
ちょっと言葉足らずで意図不明瞭だったのは申し訳ない。
↓以外は>346-348全てに同意。


>346
>コメントに書いて良いのは「何故」だけだな。

この言葉を鵜呑みにすると、「何時呼び出す」とか書けない。
これは「5W1Hが単純に読み取れない場合だけ」のがより適切だと思う。


>348
>適切な名前の関数を作ってどんどん分けるのは常識レベルだと思ってたが

これは「どんどん」「分ける」の間に「適切な粒度になるよう」が抜けてる。
2009/11/23(月) 20:50:16
適切に分けてりゃ、関数名は「何を」チェックするかだけ示せば十分>>344のように
運用できるだろ
2009/11/23(月) 23:17:29
>>349
>>コメントに書いて良いのは「何故」だけだな。
>
> この言葉を鵜呑みにすると、「何時呼び出す」とか書けない。

コードに呼び出しタイミングは書いてあるのに、なんでそんなことを
コメントに書きたいの？

それとも、関数を作った側がどんなときに呼び出すべきか想定してる
ってこと？
それなら関数の側にコメント書くから、やっぱり if にコメント書くことには
ならないよ。
2009/11/23(月) 23:53:41
ってゆーか、さ、
if ((flag & F_OPT1) && (flag & F_ERROR_ABORT)) // デバッグが有効で abort する場合
{ ... }
else
{ ... }

みたいに謎の条件判断とコメント両方つけるぐらいなら

if (is_abort_on_debug(flag))
{ ... }
else
{ ... }
って書くだろ？
353354
垢版 |
2009/11/24(火) 00:15:33
ついでに言っとくと、>>342 みたいに
細切れでコメントつけるのはあんまり好きじゃない。

if (is_debug() && // デバッグモードをチェック
　　is_error_abort() ) { // エラーで abortするかチェック
　　// デバッグ時エラーならアボートする
　　... // 必要な処理をする
} else {
　　// デバッグモードでないか、エラーでも abort しない場合
　　nr_error++; // エラーカウンタを更新
　　... // 必要な処理をする
}

みたいに、C言語の日本語直訳を書くだけになりやすい。


それなら
/*****************************
* この関数は○○の時は△△します。
* 詳細は http://＜社内サイトの仕様書置き場＞
* の □□ のフローを参照してください。
* データフォーマットは grep -r Hoge_data ./sub1/include で探してしてください。
*****************************/
とでも書いてあったほうがわかるよ。
2009/11/24(火) 00:17:52
オレだよ、オレオレ
355354
垢版 |
2009/11/24(火) 02:45:53
>350
「AかつB ⇒ Cである」の「Cである」が、一言で言えるなら>344で十分だけど、
常にそうであるとは限らんでしょ。
「Aである」「Bである」とか、一言で言える「Cである」は
>344の方針で良いと思うけど。


>351
すまん、if文へのコメント限定ではなく、コメント全般で考えてた。
if文へのコメント限定だったら、「何時真になる」とか。


>352
その例、漏れなら下のいずれかにする。
1,2の場合はコメント無し。3は政治的理由等で1,2が採択できない場合の最後の手段。

(1) if ( (flag & F_OPT_DEBUG) && (flag & F_ERROR_ABORT) )
(2) if ( isDebug(flag) && isAbort(flag) )
(3)　if ( (flag & F_OPT1)　　　　　　　　　//デバッグON
　　　　&&(flag & F_ERROR_ABORT) )


>353
352も漏れだけど、そーいう実況的コメントを書けという意図ではない。
コメントを書くなら、対象が明示的になる位置に書くべきでないの?
という趣旨で書いてる。
2009/11/24(火) 02:47:03
>355=>345≠>354
orz
2009/11/24(火) 02:54:18
>>352のコードは二つのことを一つの関数で表してるから微妙だな。
>>353や>>355のコードの方が良い。

だが、>>345で言ってることはどうにも奇妙に感じられる。
要は、コードで語り合った方がいいタイプってことだな。
2009/11/27(金) 18:45:01
中身が1行のif文やfor文について

// 1
if (...)
　　...;
{}省略してバグ混入したら嫌。

// 2
if (...) { ...; }
デバッグの時にブレークポイントが置きにくい。1行が長くなりそうなのも×。

// 3
if (...)
{
　　...;
}
行数取りすぎて画面内に表示されるコードが減ってしまう。if (...) {にすれば1行減るけど普段使ってないから一貫して使いたくない。

// 4
if (...)
{ ...; }
インデントがないのが見にくそう。かと言って{がインデントされているのも気持ち悪い。

それぞれデメリットがあって悩ましいです。
皆さんはどう書いていますか？
2009/11/27(金) 19:00:25
「{}省略してバグ混入」とはちょくちょく聞く意見だが、
生まれてこの方十数万行書いてきたが、
一回もソレになったことがない。

中括弧書き忘れたからといってバグるやつも、
バグるから書いておけばいいと考えるやつも、
死んでしまえと思う。

その程度の注意力と読解力、記述力しかないのなら、
人間やめてしまえと思う。
2009/11/27(金) 19:25:27
>359
確かに中括弧省略によるバグ混入のリスクがどの程度あるのか疑問ですね。
しかし、その反論も中括弧を省略するメリットがなければ意味がなくないですか？
中括弧を書く僅かな手間で、少しでも注意力のいらないコードが書けるのなら理にかなっていると思いますが。
2009/11/27(金) 19:56:23
>>360
ifに一行くっついてて、それにもう一行加えるんだろ？　すぐ下とかに。
それを書くときに中括弧が必要か否かに注意を払えないやつ、
書き忘れ、などと捕らえてしまうやつは死んだほうがいい。
変更を加えるとき、いつだってその挿入行の前後への注意は必要だ。

その注意力すら欠いておいてプログラミングをしようとするのは怖い。

> 中括弧を書く僅かな手間で、少しでも注意力のいらないコードが書けるのなら理にかなっていると思いますが。

それは否定していない。ただ、効果は有るが、全体にとって微少だと思ってる。
ただ、そんなヤワなサポートに頼ってしまう時点で、既に色々ダメだ。

個人的にはこうしてる。

if (cond) return; // continue, breakなども

if (cond) {
 abababa;
} else {
 abababa;
}

これは、注意力軽減への配慮でもなんでもなく、
見た目を統一したいがためにそうしてる。
ネストを避けるための式は右側に書いちゃう。
それ以外で中括弧はいつもつける。elseがなくてもつける。

> 中括弧を省略するメリット

メリットなんざ特に思いつかない。あえて言うなら見た目。
2009/11/27(金) 19:57:15
中括弧省略によるバグは実際会社で２例ほど見た
自分だけがいじるコードならいいだろうけど
後々他の馬の骨がいじる可能性も考えると
{ } 省略はやめた方がいい

ちなみに、俺は開始 { は if と同じ行に書く派
そして { } 内が短くても { の次は改行を入れ、} は単独行にする
昔は { を if の次の行に書いてたけど間延びするのでやめた
でも、行が長いと間が詰まりすぎると感じる事もあるので微妙な所
2009/11/27(金) 20:01:17
最初は一行でも後で書き足すことも多いので大抵は常に括弧付ける。
括弧あった方が見やすいし。
2009/11/27(金) 20:46:51
>>361
> それは否定していない。ただ、効果は有るが、全体にとって微少だと思ってる。
コーディングスタイルで重要なのは統一する事ですよね。
どっちでもいいような事でも、できるだけ合理的な方を選びたいです。

> ネストを避けるための式は右側に書いちゃう。
> それ以外で中括弧はいつもつける。elseがなくてもつける。
参考になります。
確かにreturnなどは1行が長くなる事が少ないですし、if文の右側でもいいですね。

>>362,363
やはり中括弧は省略しない方がいいんですね。
2009/11/27(金) 22:05:58
お前らLinux KernelとGNUのコーディング規約調べてみｗ
2009/11/27(金) 22:11:31
Linuxカーネルは、単文を中括弧で囲むのを基本的に禁止してるね。
if文の分岐の片方が単文な時だけ、特例として中括弧で囲うルールだったはず。
2009/11/27(金) 22:54:07
後から追加して複文になったときの問題だけじゃなくて、
if-else のネストで意図したものと異なる方に
else がくっつくことがあるって問題もあるんだぜ
2009/11/28(土) 03:28:03
それでもLinuxは無駄な中括弧を排除してるし、それであの巨大プロジェクトが一応は
問題なくやれてる訳だよな
ぶっちゃけ、こだわるほどのことではないんだろ
2009/11/28(土) 13:16:28
Linuxいじるような人は概ねレベルが高いだろうから問題ないんだろうな
というイメージだが、実際の所どうなんだろう
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況