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

自分は1行しか書かないつもりでも
あとでコードを足さなければならない事態なんていくらでもやってくる。
他人がきちんと中括弧補ってくれるかどうかはわからない。

1行文だろうがなんだろうが
最初から中括弧をつけるクセをつけろ

>>1
禿同!!

>>2
自演乙!!

アンケートとったんですか？
アンケートに答える暇がある人にのみ聞いたんですか？

>>4はVB使い

自分ひとりで書くときはつけないが、人と組むときはつけることにしてるな。

同じく。
でも自分が信用できないので最近は１行でも書くようにしてる。
今のところ（自分一人で使う範囲でも）
このおかげでバグが出たことはないけど。

>>6
スクリプトでポイポイ使い捨てのつもりで書いた物とかならともかく。
自分一人の時でもコーディング規約を適用するとそれほど縛りを感じないけどな。
むしろコーディング規約ナシで書いて半年後に眺めた日には泣ける。

規約があると、その規約を適用していた時のコードを振り返るときも楽だし。

そんなん明らかに実行結果違うでしょ。
コーディング後テスト出来ずに、すぐにリリースしなくてはならない環境だったり
中括弧の後の追加文が検証しにくい環境であることの方が問題。

　＿＿　　　　 ＿＿　　＿＿＿＿＿　　＿＿＿＿_　　　 　___　___　　 　___
　|　　 |　　　 /　　/　　/　　　　　　　|　/＿＿　　__/ [][] ＿|　|_|　|＿_　_|　|_
　| 　　|.　　 /　　/ 　 /　　 /￣￣|.　l　　　　/　/　　　　 |　　　 ＿　　| |_　　ﾚ'~￣|
　|　　 |　　/　　/　　 /　　 /.　　／　/　　　　|　 |___ 　 　　￣| 　|　/　/　/ 　 ／|　|
　|　　 |　 /　　/　 　/　　　￣￣　／　　　　　＼＿_|　　　　　| 　|　￣　/_　 /　　|　|_
　| 　　|. /　　/　　 /　　 /￣￣|　＼　　　 　　　　　　　　　 　|＿|　　　　 |__|　　　＼/
　|　　 |/　　/　 　/　　 /　　　 ｜　 |
　|.　　　　 /　 　 /　　 /　　　／　　/　　　　　　　　　　 　　　Powered By Visual Basic 6.0
　|　　　　/. 　　./　　 　￣￣　　／　http://pc8.2ch.net/test/read.cgi/prog/1155017860/
　￣￣￣　　　 ￣￣￣￣￣￣

そもそも、そんなに入力めんどくさいモンじゃないじゃん
省略しないほうがメリット大なのに省略するやつって
インデントもグチャグチャなことが多い。

条件式も代入も全部インデントなしの位置で記述してたり

いつも省略しないで書くから、｛｝省略しているコードが非常に読みづらい
省略している奴らはなんか美意識とかあんのかなぁ

省略するだろ普通。
それだけ縦方向に圧縮できて情報量がふえる

インデントで対応するPythonやendをつけるRubyなんかはたしかにこの手の問題を意識してるのかな

if文1つにつき1行そこらで情報量が増えるとか言われてもねえ

>>1
俺も省略するが、それでトラブるのは莫迦だからじゃね？

>>13-14
そんな大層なもんじゃねえだろ。

馬鹿な奴ほど、なんでも省略したがる傾向にあるんだよな。
頭のいい奴は省略なんてしねーよ。重要なのは省略じゃなく最適化だろうが。
中括弧の省略は可読性を低下させるだけの悪習だろ。
そんなにソースの情報量にこだわるのなら、空白文字類をすべて省けよ。
ま、中括弧をつけないことに美を感じるとか趣味だとかそういう理由なら何も言わんが。
好きにすればって感じ。
つうか、中括弧ごときで騒ぐ奴のほうがおかしいんじゃねーのとか思っちゃうけどね。

開発ソフトでソース書けば全解決ではないのですか？
よくシリマセンガ！

省略できてしまう文法が悪い。
宗教戦争起こるのは当然。

ぜひともトラブルの７０％とかいうソースを出してもらいたい。
調査したの？

これは大いに賛成
省略して何がうれしいのかと思う

自分はミスしない、と言うやつは一人で
コーディングして、一切ソースを人に見せない人なんだろう

人間って、１０段階評価って出来ないですよね

評価されたら１か２ばかりつけられちゃうじゃまいか
いやん

まぁ、情報量増やしたい奴らは、改行しないでエディタの右端で折り返しとかすれば一度にみれる情報量一気にふえるじゃん

情報量というか、可読性とかをあげた方が最終的にはバグとか減って生産性も上がると思うんだがな。

数値で評価といっても、結果的に、あるものとの比較による評価だよね。

{}省略してる奴が
コメントアウトで//ああお腹すいた
とか書いてたりすると殺意を覚える

このスレには少々驚いたな。一行の方が基本かと思ってた。
省略してると解釈するものか・・・。

java言語すら存在しない時代のCの教育書には
>>1と同じことが書いてある

これが原因でトラブルを起こすような奴がコードを書いてることが問題

>>28
人間のミスのほとんどは、ケアレスミスだよ。
言い方を換えれば、ケアレスミスをしないですむ状況をつくればミスは減る。

マ板でやれ。

ケアレスミスを減らすために決まりを沢山作るよりも、
問題がすぐに発見/修正されるような仕組みを作ることが重要。

取り敢えず一切省略しない。
エディタがifを入れたところでブレースを含めて展開してくれるから、面倒もない。

俺は基本的に1行でも{}はつけるけどたまにつけない事もある。
つけない事が原因でバグが入った事は無い。

{}無くてもインデント付けてりゃまず見逃さないだろ

>>31
少なくとも省略して可読性を悪くする人間は失格ｄな

省略を許してしまうような言語が悪い

俺は悪くない

>>35
あんたにとって可読性が良いコードが万人にとって可読性が良いわけじゃないでしょ。

>>37
{}を使った方が可読性が良いって流れなんだけどな

だからそれは万人にとってじゃないでしょ。
間延びして読みにくいと感じる人もいるわけで。

{}付ける派だが、俺は

if()
{
    // ...
}

って開きを綴じと同じレベルに置きたいから無駄になるのが1行じゃなくて2行なんだよな。

{{{{{{if(1)printf("Hello, world");}}}}}}

俺は状況によって色々

if (...) {
　　aaaaaa;
　　bbbbbb;
}

if (...)
{
　　int n = 0;

　　aaaaaa;
　　bbbbbb;
}

>>42
そういう決まりが無いのがトラブルを起こしやすいんじゃない？

そもそも省略不可な場合（複数行）が多くて、つけるのが癖になってる。
仮にものすごく低い確率でつけ忘れたってトラブルになる程でもない。
ちょっと実行してみて、あれおかしいな、ああここか修正修正って感じ。
この程度じゃトラブルになりようがない。
ワープロの文書コピー作業じゃないんだから。

>>43
決まりはあるけど？

関数の最初の方で早抜けするときはこうも書くな

if (...) return;

if (...)
  if (...)
    aho();
else
  baka();

つまり Python を使えばコーディングトラブルの約70%を省略できると(w

if(...)
　　nurupo();
else

if(...)
　　b = a>>49;
else
　　gaxtu();

完全記述

if(...) {
} else {
 if(...) {
 }
}

こうだろ？ｗ

if (...)
{
}
else
{
　　if (...)
　　{
　　}
}

以前は>>51のスタイルだったけど
VisualC#を使い始めてから>>52になった。

甘い。正解はこれ。

if (...)
{
}
else
{
　　if (...)
　　{
　　}
　　else
{
//do nothing
}
}

JavaでもC++でも>>52みたいに書いてる学生だけど
今のうちに修正した方がいいんだろーかと悩むお年頃

インデントがプログラムの意味とずれてさえいなければ、どれでも問題なっしんぐ。
あと、人のコードをいじるときは周囲に合わせる控えめな心が大事ｗ

心に刻んでおきます

プログラミング歴20余年の俺は紆余曲折を経て最終的に>>52のスタイルに至ったんだが。

else if
だけはぶら下げちまえ。
ぶら下げ使ってくれ。
頼むから。

あと、俺は
if(..) {
}
派なんだけど、
if(...)
{
}
派が理解できない。
一行無駄だろ。

eclipse(ﾃﾞﾌｫ)は>51なんだが、君たちの開発ソフトはどんな記述だ？

>>59
ブロックの中でローカルな変数使うときだけは

if (...)
{
　　変数宣言

　　あれこれあれこれ
　　ずびずばぱやぱや
}

ってやりたくなる。　

>>60
if (..) {
} else if (...) {
} else {
}

俺もeclipseだけど。

>>60 >>62
else の後の if を {} に入れてるかどうかで当然後の整形結果も違ってくるんだろ

else if は俺の場合こうだ。

if (...)
{
  ...
}
else
if (...)
{
  ...
}
else
if (...)
{
  ...
}

昔こうやってた時期がある。
あほか、とｗ

/**/ if (...) {
}
else if (...) {
}
else {
}

{}をつけないのは副作用のあるループで本体が空の場合だけかな

while (i--)
　;

こんなの。

>>66
それはこうやるな

while (i--) {}

【ネガティブ派遣根性チェック】

3つ以上、思い当たる点があればアナタの性格はひん曲がっており、ネガティブ負け組人生を歩んでいます。

□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなく自分のプライベートについても指示して欲しい
□奢ってくれる派遣先正社員は尊敬する
□自分の月額金額を知らないのは当然だ
□派遣先正社員より自分の生涯収入が低いのは当然だ
□派遣先に尻尾を振り、いつまでも派遣を続けることが大切だ

>>66
それでも、俺の場合はこうだ。

while(i--)
{
}

俺も青かったころは

while(i--);

とかやってたけどね。

典型的なレベルの低いスレだな。

こんなのは、「俺の場合」とかじゃなくて、決められたコーディング規則で書け。

これは恥ずかしいレスだな

>>70
趣味でやってる場合はコーディング規則なんてないし、
仕事でやってる場合でもそのコーディング規則とやらはたいてい誰かの「俺の場合」なんだが。

プログラミングは研究で使うだけで規則は決められてない

>>70
規約がある場面ならそれに従うのが前提だろ。

俺は縦方向にあまり引き伸ばしちゃうと、意味が俯瞰しにくい気がするんだな。

自信のない論拠を補強するために妄想で実体のない数字を提示する奴って、
すぐ言い訳や嘘をつくから一緒に仕事をしたくない。

うちは皆さんとは逆にif文にブロック禁止。
if(条件) 関数1(); else 関数2();
で書く。

コーディングレベルの低い奴に限ってコーディングルールの話をやたらとするんだよなｗ
そんな暇があったらコード書けよｗｗｗ

>>77
(条件) ? 関数1() : 関数2();

>>77
俺の場合、どうしても１行に納めたい場合は if 文使わずに
(条件 && (関数1(), true)) || (関数2(), true);
とかってする。

コードフォーマッタで括弧も自動で付けてくれる奴ってある？

チーム平均レベルが低い問題の100%は>>1が原因

>>80
詰め込みすぎだw

ていうか手段と目的が入れ替わってる

>>78 みたいなヤツが、小汚くてメンテナンス性ゼロなコードをまき散らしてんだろうな。

そんなに１行にしたいなら改行しなきゃいいだけじゃん。

みんな好きだねこういうスレ。
レスの伸びること伸びること。

>>85
お前はコードレビューの時につまんない俺流コーディング規則を得意げに解説したりするんだろｗ
聞いてる人うんざりだろうなｗｗｗ

>>87
知識が無くても話せるからねｗ

コーディング云々よりも、嘘つきの方が遙かに厄介。

>>88
お前にいいものやるよ。

　つ　[鏡]

お前の書き込み見てる人うんざりだから。

>>1のように自分のミスを他人のコードのせいにして、非を認めずに言い訳し続けたり、
何の根拠もない数字を持ってきて嘘をついたりする人間がプロジェクトに混ざっていると、
非常に迷惑極まりない状態になる。

有名ソフトや書籍でも、一行の場合は{}は省略してるのは多いな。
まあ、コーディングルールでも、どうでもいい部分だろな。
これは。

>>77
えええええええ

そんなあほらしい規約があるのか。。
驚愕

>>94
多少、あほな規約でもちゃんと一貫して守られてさえいればおk。
まぁ、厳しく管理してない限り、たいていなし崩しになっちゃうんだけどな。

>>95
> あほな規約でもちゃんと一貫して守られてさえいればおk。

そんなことねーよ。

linuxカーネルは、1行の場合は省略だね。
そうじゃないと、コミッタに罵倒されてパッチを受け付けてくれなかったり。
まぁlinuxの場合、インデントは8でタブで無いといけないという決まりもあるので、
読み間違えることは、まず無いのだが。
自分はドライバ書いてるが、そういう文化があるから、Cの場合は省略することが多いね。

でもJavaでは絶対省略しない。ていうか許している仕様が理解できない。
あと、elif とかをなんで用意しなかったのか、謎でしょうがない。
三項演算子もJavaの場合は使わないな。

既にある規約を、そのやり方ではミスが増えるとか主張して、
自分流のやり方を押し通そうとする奴がいるが、
いままでそんな問題はなかったからとみんなになだめられても、
絶対に考えを曲げずに最後にはふてくされる。
はっきりいってこういう奴は使えない。

>>98
>いままでそんな問題はなかったからと

ヘボいところは、自分らがいかにヘボいか理解できないからなぁ。

まあ、そういう所でやり方を変えようなんて怖くていえないけどな。
当たり前のことができずにトラブって「なんでやり方かえた→言い出したヤツはだれだ」
って展開になりがち。

現場の状況に合わせて柔軟に対処できない奴はあらゆるトラブルの原因になる。

Perlの
〜if ...;
って何気に最強だな。

>>99
規約を変えたければ管理する側に回ってからにしないと統率がとれなくなるだろ。
主張が通らない時点で、その権限が無いことが理解出来ないのが問題なんだよ。
自分の言っていることが正しいと思いこんで、自分勝手な行動をしているという認識がない。

>>102
いや、そこんとこは誰も問題にしてないから。

クラスの使い方覚えてホイホイ作りまくってたら
「解かりにくいわ！」って殴られた｡･ﾟ･(PД`q｡)･ﾟ･

>101
Rubyにもあるな。俺は and 派だが。

アホなルールもあるこたあるからね。
1ファイルにつき1関数とか、
関数に分けてはいけない(mainだけにしろ)とか、
関数名・変数名は紙ベースの台帳管理で関数はfxxxx変数はvxxxx(xxxxは数字)とか、
こういう規則はどうなんだろう。理にかなっているのかなあ。

こういうのはやめてもらいたいと思わない?

こういう底辺な現場からおさらばして10年以上になるけど、
まだこういう現場は残っているのだろうか。

まあif以下の文で複文でない場合も{}で囲むことなんてルールは、
あってもなくてもさほど害がないルールではあると思うけどもね。
境界はどの辺にあるんだろうね。

＞関数名・変数名は紙ベースの台帳管理で関数はfxxxx変数はvxxxx(xxxxは数字)とか、

これは実際に見るまでなかなか信じがたかったが、ホントにやってるとこあるのな。
漏れが見たのはJavaでの開発だった。

>>77
QB登場以前のBASICかよ。

C++/Java/C#使いのみんなに聞きたい。
自動変数のスコープを限定するためだけの{}使うよな。な。
仕事で使ったら、「この意味不明な{}は何なのか説明しる」って同僚に詰め寄られたんだが……。

>109
俺も使うことはある。特にC言語や、１つのメソッドが大きくなる時は。
ただ、Javaであまり必要に感じたことは無い。
privateメソッド複数作って、処理分けちゃうことが多いかな。

>>109
漏れはけっこう使う。

int n;
{
　// 一時的な変数なんかも使って n を初期化するコード
}

// n を使うコード

とか。
書いてみて思ったより長かったらそのまま別の関数にするけど。

>>107
そういう職場ってそのうち慣れますか？
それともとっとと逃げ出すのが正解ですか？

>>112
そこに骨を埋めるつもりならがんばって慣れないと。
いずれ他所へ行くつもりなら慣れちゃったら後が大変そう。

……後者を選ぶことにします

>>110
そうしたくなったときというのは、
そこで関数を分けるべき時だと思っているので、
ほとんどの場合は括りだして別の関数に仕立て上げちゃう。

もちろんほんのちょっとスコープを限定したいというときは、
その限りでないけど。

>>107
それをやっているところはコボラーが仕切っていると考えてほぼ間違いないです。

あいつらオブジェクトがどうのとかいう以前に関数をわける利点とか、
もっと以前にわかりやすい名前をつけるとかスコープとかいうことを知らん。

このスレおもすれえ

>116
しょうがないじゃん、COBOLの仕様にはグローバル変数と
引数の無いサブルーチンしか無いんだから…

うざい上司にはインデントで訴えかけるに限る

hoge.each do |foo, bar|
　　　　　　　　　　fuga
　　　　 　piyo
　　　　hogera
　　　end

　　　　　　piyo
hoge.to_a.each do |foo,bar|
　 　　　　　foo
　poi;　　　bar;　　　poi
qwe;　　　　　　　　　　　end

>>94 >>108 30年以上前かららしいから、そんなところでしょう。
COBOLで IF CC EQUAL DD PERFORM YY ELSE PERFORM ZZ. の名残だと思う。
テスト、デバックがこの方がやりやすいからというのが積極的な理由。
ただしbreakする時が大変。

http://www.mono-project.com/Coding_Guidelines#Where_to_put_braces

2つ目のgoodがbadだぜ

Coding Guideline であって Coding Convention じゃないんだな。
それくらい大きなオープンソースプロジェクトともなると、規約にしたところで従わない奴が続出するんだろうな。

厳密にやろうとするなら、コミット前にチェックして(subversionなら
pre-commitフック、CVSだとcommitinfoか?)、従ってなければコミット
させないなんてトコもありそう。

そこまでして関数名はf+数字を強制とかイヤすぎるなｗ

JavaやC++で省略する奴とは仕事しない

C++は省略しても普通だよね。

if(flag) break;

if(x)
　　　　/* 何らかの処理 */;

って書くとうっかりしやすいけど、

if(x) /* 何らかの処理 */;

って必ず一行に収める習慣にすれば大丈夫な気がする。

if(x) 何らかの処理1; 何らかの処理2;
と書く人がでてきちゃう。

そもそもブロックなしのifに一行追加して、ブロック付け忘れてハマったなんて経験がない。

御意

>>129
「;」で区切って一行にいくつも文を書く人にはお勧めできない。

if(cond) i = f(), j = g();

自分一人の開発ならこういうこともする。
読み間違えるとかありえない。

無能コーダーにぐだぐだコーディング規則を語られるのウザいから
ソースはIDEが自動整形してくれ。

括弧も自動で付けてくれるコードフォーマッタある？

>>130

if(cond) {
hoge();
fuga();
}
を
if(cond)
hoge();
にしようとした形跡のあるコードで
if(cond)
hoge();
fugafuga();
と、インデントそのままでブレースだけとられたコードではめられた事がある。
じっさいにはもうちょっと長いんだけど。

if(cond) {
　　hoge();
　　fuga();
}
と
if(cond)
　　hoge();
fugafuga();
にしようとしたコードで
if(cond)
　　hoge();
　　fugafuga();
とね（ちくせう空白つめんな）

>>135
ない

お前ら省略って言うけど、Cの場合本来ifの文法は
if( 条件 ) 文;
だよな？
でもこれだけじゃ機能不足で、複数の文を置きたいから{ }でブロックにするんだよな？

由来とかはどうでもいいし俺も{ }は必ずつける派だけどな？

>>139
確かに。
でもなんて表現したらいいんだろ？

実績ある有名なソフトでも、普通に省略してあるんで、品質には関係ない部分だとは思うけどな。

>>139
惜しい

if (式) 文

だ。最後にセミコロンはいらない。

>>141
そもそも品質はテストによって担保するものでコーディングスタイルに依存するものではない。
ただ、よいコーディングスタイルであればミスを未然に防ぎやすいというだけのこと。

そもそもスレタイの70%の根拠は何だ!

>>144
そんなんどうせ >>1 の経験からのなんとなくだろ。
そんなのいちいち気にしてたら負けだ。

だけど、
if(condition)
f1();
f2();
というコードに
if(condition)
f1();
f3();
f2();
なんて付け加えるプログラマっているか?

タブでなくスペースで送ってしまった。
>>146 は無かったことに。

>>146
なにがいいたいのかよくわからん。必要応じて   を使ってくれんか？

>>143
だから、{}を省略してもミスとは関係ないって判断してるんだろ?
有名ソフトで{}を省略するスタイルの人たちは。

一人の天才で組んでるならともかく馬鹿と仕事するときは
馬鹿のレベルに合わせなきゃいけないんだよ

>>149
有名ソフトでそうしているからっていう判断はあんまり感心せんな。

>>150
短期的にはそれは認めるけど、今のこの業界は馬鹿を馬鹿のまま放置しすぎ。

向上心が無いからバカ

>>151
自分の経験も加えて。
2chのななしよりの意見より、実際に成果を出してるやつのスタイルのほうが参考になる。

有名ソフトや書籍でも、省略する派としない派がある。
ようは、たいして重要じゃないってことだろ。

う〜ん、おそらくループ変数なんかのためでしょうし、
そのほうが安全そうですが、そういうソースは見たことないです。

>>1が70％の確率で{}省略でトラブルという告白スレ

>>155
逆だろ
派閥が分かれるってことは懸案事項だってこと

結論

コーディング規則を語るのは最下層の乞食コーダだけ。

奴隷につなぐ鎖の強度を語るのはいずれ管理へ回る前途ある者
それを理解できない159は、奴隷以下の乞食か動物

奴隷をつなぐ鎖なんて強度が十分であれば何を持ってきてもいい。
管理者はカタログから選んで持ってくればいいだけのこと。

鎖を再生産する管理者はバカ。
つながれてる鎖を自慢をする奴隷はマヌケ。

何の比喩なのか、わかったようでわからないレスだな。

わからないならレスしなくていいよ。

逆切れするくらいなら比喩なんか書くなよ

だそうだ。気をつけろよ>>160

>>165は>>160か。そんなにくやしかったのか？

悔しくなんてねーよ、バーカ

本物の160だけど、160以外のレスはつけてないけどね。
逆切れしたのはどいつだか知りたい。
あと、>>160の理由もね

＞あと、>>160の理由もね
まちがえた、
あと、>>165-166の理由もね

160必死だなｗｗｗｗ

だから｛｝でくくっておけばよかったんだ

int
hoge ( void ){
}

みたいなのもやめてほしいな。

括弧はともかく int と hoge の間の改行は正規表現で定義と使用が区別できるので vi 使いには便利。

正規表現なら別に改行でなくてもいいんでは。

>>174
vi使ってるときに、

/hoge で普通に検索
/^hoge で定義を検索

ていうことね。

IDE使えよ乞食

現実には戻りの型の方が関数名より長い事も多々あるからな。
intみたいな極端に短い物以外は改行で統一した方が見やすい。

いやそんなにないだろ

constもポインタも構造体もクラスもテンプレートも出てこないんですか。
APIやらライブラリ使ってりゃ長い名前の構造体なんていくらでもあるだろうに。

構造体なんか返すなよ

いくら長くても改行するほどじゃないな
というか、返す型情報まで含めてワンセットだから改行したくないなあ

BSD系のカーネルのソースなんかは改行する事になってるね。
style(9)あたりに書いてある。

>>180
３２ビット値２つとか３つの組は結構返すよ

>>158
どっちか片方に収束しないってことは、どっちでも大差ないんだよ。
どっちかが明らかによかったら、片方のスタイルは廃れてるだろ。

>>180はC使い

構造体自体を返さなくても、それを指すポインタ返せば記述は長くなりますやん。

>>185
C++でも同じだろ。
(スマートポインタで返すって手も使えるけど)

>>175
そんなん普通にコメントアウトでラベルつけときゃいいだけやん

>>188
意味わからん

>>189
int aho() /* teigi */
とかかな。
aho(); /* shiyou */

全部に書く気なんじゃない？

lint用のコメントみたいだなｗ

>>1
プログラマは信号は守るべきだが
小石を取り除くかどうかはプログラマしだいだ
尊敬するプログラマのソースを読め

>>192
尊敬するプログラマはみんな省略してませんでした

漏れその昔、ビル･アトキンソンをめちゃくちゃ尊敬してたが、
C系のコードは書いてたのかどうか知らん。

defineで閉じてるのは軽くいらっとさせるね
if () {
...
#if 1
} else
#endif
...

}
GNU関連は関数なんかもこれで閉じてくるよね

>>195
仕事でそんなコード書いてるヤツ見たら、思わずはり倒しちゃいそう。

return_type
func_name(
　arg_type arg
)
{
}
はダメダメってことですね。

>>197
なんで？

つ >>172 >>177

>>197
俺はよくそのスタイルで書く衝動にかられるけど、
引数リストの行末がカンマで統一できないのが
嫌でいつも思いとどまる。

> 引数リストの行末がカンマで統一
そ、最後ね

arg_type1 arg1,
arg_type2 arg2,
arg_type3 arg3

最後のarg3だけカンマなしでないとエラー。よく引っかかる。
配列の初期化子は最後のカンマOKなのにね。

>>187
C++ 使ってると C の頃の感覚が麻痺して
抵抗なく string 返したりもできるようになる筈ｗ

オーバーヘッドなんて高が知れてるし、参照もポインタも使わずに
構造体やクラスを平気で返しちゃうぜ

C++クックブックって本は、コンテナクラスは 全部引数でやり取りしてた。

何でスレ伸びてるの？

>>76
それおまえさんが強要して出させたんじゃないか？

>>206
スレタイの数字の話じゃねえの？

ぶら下がりelseに起因するbug発生回数は一回
その他の中括弧の省略に起因するbug発生回数は零回

どんな書き方をしてもバグを生み出さないソースを書けばいいだけ
どんなにファクターがありそうでも最終的にそこに原因を求めるのは結局責任転嫁だ

読みやすい書き方はそれだけでバグの抑制になる

インクリメントとかシンプルな処理なら｛｝なんて使わなくても
使うのは数行に渡る見込みがあるか後々まで残す部分くらいだな

やはりbegin〜endの勝利だな

Python最強ということで

schemeもええで

ソレより、 && || をif文中で使ってる場合の方が多いように思うけどな

特に俺が書いた時に無かったのに後から何気なく追加されたような場合、たいてい間違ってるゾ！

70%はそっちの方だね。

まだ && ||を２行に別けて書く人はミスが少ない気がする

if( ( hoge == hage )
&& ( hige ) ){
}
みたいに

こういうのは程度の問題で、複雑な式は分けて書いた方が理解しすいだろうが、
シンプルな式まで徹底して分ける事に決めちゃったりしたら、かえってコードの意図がわかりにくくなると思う。
{}の省略についても同様。

if修飾子が使える言語(PerlやRuby)だと、やることが1つなら修飾子にして
おいて、増えたら複文支配のifに書き換える、という使い分けが出来るな。

むしろ後置ifが使えるなら、
前置ifでの単文修飾は不可能にすべきじゃなかろうか。

perlはそうだね。

俺はPBP6.2の通りに後置ifはnext, last, redo, return, goto, die, croak, throwでのみ使うようにしてる。
メンテ不要な書き捨てプログラムはこの限りでないがw

if文より型の変換とか値入れてない変数とかの方がやばい気がする。

全ての分岐をgoto文で書いてやる

gotoが必要なのは多重ループを抜けるときだけだよな。

ttp://gedo-style.net/g/?v=361721&d=d.jpg

多重ループは関数化で対処

gotoはエラー処理と字句解析のハードコード。

if()
{
;
}

↑これは異端か？

異端もクソも、なぜ if() の中を ! で否定しないよ

頭ごなしに否定するのはよくない

ケツで否定してやる。

{ ; } unless hoge;

{ } を付けたら女の子にもてるようになりました

スーパー括弧閉じ

括弧閉じはコッカって言わないか？

通じるけど恥ずかしいから自分では言わない。

>>235
それは局所的にしか通じないだろう。

sh 系だとそんなだよな。

esac ってなんだろと。

fi はまあ想像つくけどなｗ

言語規格の中で if() ; 形を if() { ; } の省略形であるとしている
言語はどんなものがありますか。

そんなのあるのか？

お前らエディタのソース整形機能とか使ったことなさそうだな

COBOLにそんな機能ねーよ

ソース整形が必要なほどのクソコードに出会ったら
とりあえず腹をくくることにしている。

おまえはソース整形について誤った観念を抱いているのではないか

ソーッスねぇ

ソース整形したらテスト全部やり直しなんだけどそれついてはどうなの？

>>247
なんで？

>>248
あ？遊びでやってんじゃねーんだぞ

>>247
kwsk

バイナリがかわんなきゃよくね？
or
テストケース再実行すりゃいいじゃん

好きなほうで

テストする前に整形すればいいだけじゃん

リポジトリにコミットするとき、自動的にソース整形すりゃよくね？も追加

>>247は自動化したテストですらとんでもなく時間を食う
ちょー大規模プロジェクトをやってるんだろう。

>>251
＞バイナリがかわんなきゃよくね？
これは納得できる

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

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

>>253
改行した瞬間に自動的にソース整形するVBが最適解か……orz

やはりpythonが・・・

>>255
時間かかるテストは、夜走らせとけよ

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

これ大抵の言語でいけるだろ。

バイナリが変わるようなコード変換はもはや整形じゃないと思う

>>175
そんなの^(unsigned)*[int|char|short|float|double] [a-Z]+[0-9|a-Z]*\(とかで検索すればいいんじゃね？

無理やりこうやればできるとかいう話じゃなくってさ。
viでは検索が日常的なカーソル移動手段のひとつなんだよ。

>>259
ぜんぜんだめ。おはなしにならない。

C言語は文脈自由文法だから正規表現で完璧にマッチさせるのは不可能

>>262 こういう話疎いので、初心者にも解るように解説してください。

>>263
コンパイラの本でも嫁

突然舞い上がったようなレスだな。>>262は
そもそもどのレスに依存するのだろう。

259のあたりだろ。

>>265が>>262を全く理解できなかったということだけはわかった。

まあ規約ガチガチなのはそのせいだしな

正規表現に疎い俺に>>173はどういう正規表現を書いているのか教えて欲しい。

そこらじゅうに未定義・未規定・処理系依存が
ぽっかり口をあけているC言語のどの辺がガチガチ？

コーディング規約でガチガチにするって意味だよ

そんな連関、聞いたこと無いけどな。

>>263
かっこが自由に無制限に入れ子に出来るパターンは
正規表現じゃ理論上無理らしいよ

正規文法と文脈自由文法でぐぐってみ

正規文法は 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.

そういうこっちゃ．

だかPerlとかの変態拡張性器表現ならきっと・・・

Perlのは正規表現の中でPerlのコードを評価できたりするからある意味万能

つまりゲストのお客さんが自由に参加すると収拾がつかなくなるので、
レギュラーのメンツだけでやってくれ、というわけですね。

結構前の話題だが

俺は例えば if なら
if(式) 文;
文が一行で、かつこの行が長くならない場合だけ { } を使わずに書くかなぁ。
if(式)
　　文;
と書くぐらいならブレースを使ってる。

条件文がすげー長かったら？
やっぱ１行でもブロックにする？

条件式を関数なりマクロなりに分けて良い感じの名前を付ければおけ。
そういう時ローカル関数使える言語だといいんだけどな。

ローカル関数は欲しいねえ・・

C++;なら関数内で定義したクラス/構造体のメソッドで代用出来るけどな

無理やりそんなことしても読みにくくなるだけだろ。
読みやすくすることが目的なのに。

>280
うん。条件が長い時もブレースにする。
もしくは条件式の閉じ括弧を実行文の行に持ってくる。
これなら俺は間違えない。集団ならやらんけど。

if(
　　条件式
) 実行文;

BASICで育ったんで一行IF／ブロックIFが基本、
長い時はブロック化するかこうしてたからなー。
IF 〜 _
THEN 実行文

自分所のコーディングルールは、

if (式) 文1つ ;

if (式) {
複数の文
}

のいずれか片方のみ可。

ルール作るなら、常にブロック使えやコラにした方が良くね？

ガチガチだと読みにくくなるよ・・・

if (式)
{
　・・・
}

これに統一すると美しい

主観

>>289
自分には美しく見えない。

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


{
何か
}
という可能性を考えて、前方向をチェックしなくてはならない。
if (式) {
何か
}
というように同じ行に書くように強制すれば、見てすぐにわかる。
if (式) と { が生き別れになってしまうこともない。

そんなのは、常に整形ツール使えって事でいいじゃないか。

そのルールが気に入らない場合は、自分が読む時に整形しなおせばいい。
そして、読み終わったら元に戻すと。

よっぽどものすごい書き方してなきゃだいたい読めるし、
書くときはまわりに合わせりゃそれでいいじゃないの。
こんなのが原因でトラブるやつは他の原因でもっとトラブるよ。

>>291
つ[c++ or c99]

TCLではブレース次行じゃダメなんだよな

>>295
そうなのか。
あれは、それぞれがシェルコマンドみたいなもんだからな。

Tclは改行した時括弧の中じゃなかったら
そこでバッサリ文末になるからな

Rubyは、改行したところまでで文が成立する場合は次の行は別の文扱いだな。

二項演算式の途中とか対応するカッコを閉じる前のような、文が未完結である
ことがわかる場合は途中改行ができる。完結しているように見える場合は、
¥を付けて明示的に継続する必要がある。

セミコロンが文の終わり、にしときゃ良かったと思うんだけど
なんでそんなにも ; なくしたかったのかな？

毎回行末記号書くよりも、必要な時だけ継続記号使った方が手間がかからないという思想だろう。

>299
俺は逆に

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

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

Lisperは文末どころか文の始まりまで毎回書くんだもんな…凄いと思う。

Ruby慣れると、C書くとき早速セミコロンを忘れる。
無いほうが自然なんだな、と実感する

文脈によらずに継続行書くときは常に\つける方が好み。

おまいらFORTRANやCOBOLの時代に逆戻りだな・・・

>304
むしろ、その時代はカラム制限があったから
セミコロン文末の方が利点が多かったろうに
ある程度のカラムが扱えるなら継続行のみ明示で良いと思うぞ
どうせそんな滅茶苦茶長い行書かないし

…ああ、C言語は使うAPIによっちゃ長い行が普通になるのか

>>301
Lisperにはカッコは見えていないし意識して入力もしてないｗ

>306
そういうモノなのかｗ
他言語の人（俺含）から見れば大量の括弧の方が目につくんだがな〜

>>307
begin endが目につくpascalとか
:-が目につくprologとか
{}が目につくCとか
<>が目につくXMLとか

インデントしてたらそんなに目に付くもんでもないんじゃない？

セミコロンなしで行末で文末としてしまうと、

class hoge { どわーーー}
という具合に1行に書かないといけなくなりますぞ。

どわーーーでなぜか和んだ。

>310
そういう言語は
・閉じ括弧が少ない場合はブロックが継続する
・構文でブロックを示すからendが来るまでブロックが継続する
のどちらかを備えてるだろ普通。

Tclは前者。
BASICやCOBOLは後者。
Rubyは両方使ってるな。
Pythonはインデントでブロックを示すんだっけ？

Pythonはインデントでブロックを表してて、両方だな。

途中から良スレになってる気がした

気のせいだった

age

かの有名なカーニハン先生も省略するべきでないと仰っているよ。

蟹飯がナンボのもんじゃーい！

>>317
K&R、省略しまくりじゃん。

俺はC→JAVA→C++→C#と勉強してきたから
コードブロックよりもセミコロンがない言語が苦手だな

セミコロンは文の区切りです。

同じセミコロンでもデリミタとして使う言語とターミネータとして使う言語があるのよん。

Pascalは文の最後はピリオドだったな。

pascal は
○ if a then b else c;
× if a then b; else c; (コンパイルエラー)
Cはどっちも大丈夫

Cはどっちも怒られそうだぞ

カッコが付かないな

Pascalの場合、elseはif文の一部で
セミコロン付けると、そこでif文が終わるから
「文頭にelseはおかしい」って言われるんだよね。

c でも else は if 文の一部。

; が文同士のセパレータではなく文の終端記号でしかないから、
b; が 1 文となって問題にならない、ってこと。

>>323
プログラムの最後だろ？

>>1
COBOLのIF文の歴史を知らないんだな。

内容（意味）によらず形式だけで決める
>>1の考え方が危険なだけ

人いたんだ。

>>331
形式で決められるものは、決めればいい。
その分、考えないといけないことに頭のリソースを配分しようぜ。

ブラを付ける自由もあれば、付けない自由もある。
女性はブラジャーの着用を義務付けるという法律が
制定できないのと同じ。
ブラは時には非常に邪魔になる。
形式では決めることができないものは意外に多い。

そもそも、
Windowsのメモ帳にたくさん毛が生えたようなテキストエディタを使ってコードを書く
という時点で、おかしいだろ。

C#なら言語仕様で{}を強制してたとしても不思議ではないね
switch内のbreakは強制だっけ

{} を強制するなら elseif キーワードが必要

ブラを強制するのなら、elseの禁止も合わせてやったほうが良いかも？

よくね〜よw。
なるべくブラ着用。elseの多用は可愛気がないぜ。といったところ。

コーディングするためのユーザインタフェースが、
事故を未然に防ぐべく何かするのが第一だろ

いつまでも
紙に鉛筆でプログラムを書くレベルに留まるな

>337
なぜに?

elseifがないと
if () {
} else {
　if () {
　} else {
　　if () {
　　} else {
　　　if () {
　　　} else {
　　　}
　　}
　}
}
みたいにどんどんネストが深くなる。

{} を省略できるなら
if () {
} else if () {
} else if () {
} else if () {
} else {
}
みたいに書けるんだけど

強制する←→省略不可だからそういうのも認めないって話じゃねーの。

というか、>>1の主張を強制するのならelse ifという慣用表現も禁止で
>>341みたいにきちんとif文をネストするような表現とすることを
強制するべき。
>>342式を禁止するというか非推奨にするのは、それなりに根拠がある。
多くの場合、>>342の形式の場合、ロジックが練れていなく、
バグが多い割に修正が難しいから。経験的に言って>>341式のほう
が、バグも少なくなり、バグが出ても修正しやすいような気がする。
結論的に言えば>>342式を禁止するのは一定の意味を持つが
>>1を強制するのはやり過ぎかも。

>>342禁止ですら、行き過ぎという感があるのに
>>1強制なんてあり得ない

なる。
それなら俺は {} 強制で else if 容認かな。

自分のバグ元としては {}なしのif より 比較に = 使っちゃう方が多いけど。
だから、エディタで[^><=]=[^=] を赤くなるようにしてる。

caseで

多くの場合、経験的に言って、根拠があると言っているわりに>>344は主観推論しか言っていない気がする。

case式が強力な言語ならいいんだけどCだと定数との比較しかできない

>>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的な使い方だと誤解して順序を変えてしまうと、意味が変ってしまう。

if(id == typeA && ){}
else if (id == typeB &&){}

って書く奴いるけどなんでswitch文使わないの
バカなのねぇバカなの？

>>351
妙な && が気になるが、if で書けば
・コードの行数が少なくて済むので見やすい
・スコープがしっかり認識できて良い
・シンタックスハイラトや自動インデントなど IDE によっては switch の対応が微妙
・if の方がコンパイラが最適化しやすい条件になっている
とかとか。分かってて書いている人なら、別に良いと思うけど？

if(id == typeA)
if(id == typeB)
と
if(id == typeA)
else if(id == typeB)
同じ意味だよね？

>>353
if (id == typeA) {
...
id = typeHoge;
}
の場合は？

>>353
idがconstなら同じ。そうでないなら、>354の可能性がある。
例えば、この関数では全く同じ。
void func(const int id)
{
if (id == typeA) {
funcA();
}
if (id == typeB) {
funcB();
}
}

つか、同じじゃないように見えるんだけど？

if(id == typeA)
if(id == typeB)
って、インデント付けると
if(id == typeA)
　if(id == typeB)
だよな？　更に括弧も付けると
if(id == typeA) {
　if(id == typeB) {
　}
}
だよな？

>>356
>353が>351を踏まえて書いたかどうかだな。
>353が>351を踏まえずに>356の意味で書いたのだとしたら、
if (id == typeA) if (id == typeB)
は(typeAとtypeBが等しいと言う無謀な前提を仮定しない限り)
if (0)と同じになってしまう。

べつに無謀な前提ではないんじゃないか
typeA != typeBでもid == typeAかつid == typeBだったりすると怖いけど

>>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 つでいいが、そうでなければ使うべきではない