goto文に関しては何処にでも飛べるので使いこなすのに
センスとか能力が必要と言う話もわかるのですけれど、
continue文に関しては使いこなせないと駄目なのではと思います。
確かに慣れないと追いにくいと言うのはあるんでしょうけれど、
gotoと違って跳び先が限定されているのでスパゲッティプログラムには
なら無いと思いますし。

私は、皆で共有するソースは、
「単純、素直」が良い
と思っているので、基本的なスタイルはAみたいになるかなと。
今まで比較的よく見るルールに
「３項演算子を使わないと言うのがあります。」
これに関しても代替の解りやすい表現法がありますし、
ソースを読む方のスキル依存を下げる目的なのだと思います。

わはは、括弧の位置を間違えました。
気にしないで下さい。

ガイドラインは
・全員のコンセンサスを得る
・逸脱する場合は理由を明記する。
くらいで運用してますな。

MISRA-CとかIPA/SECとかが参考になれば。

> 「使い方次第」「使いこなす」「使い分ける」「上手に使う」
> これが、ルールの理由なんじゃないかな。

なるほど、そうかもしれませんね。
「分かりやすくなるような使い方をしろ」だと、
結局、人によってその定義が様々だから、
それだったら「ルール化しましょう」ってことなのかも。

自分も、趣味では自分流のルールを定めてはいるのですが、
まだまだ模索中だったりします。
とりあえず、趣味でも「人に見せること」を意識する場合は（滅多にないけど）、
if文のカッコと非マルチステートメント化は、行うようにしようと思います。

でも、マルチステートメントについては、やっぱりどうしても捨てがたいんですよね。
以前、実際に書いたソースですが、

// コマンドによって処理を分岐
if (strcmp(ComStr, LIST) ComList();
else if (strcmp(ComStr, MAKE) ComMake();
else if (strcmp(ComStr, EDIT) ComEdit();
else if (strcmp(ComStr, SAVE) ComSave();
else if (strcmp(ComStr, OPEN) ComOpen();
else if (strcmp(ComStr, SORT) ComSort();
else if (strcmp(ComStr, HELP) ComHelp();

というのが、何十行も続くものを書いたことがあります。
こういう場合だったら、やっぱりマルチステートメントの方が
見やすいと思いませんか………？

> MISRA-CとかIPA/SECとかが参考になれば。
ありがとうございます。じっくり読んでみます。

if文の閉じるカッコを忘れました…
気にしないでください。

>// コマンドによって処理を分岐
>if (strcmp(ComStr, LIST) ComList();
>else if (strcmp(ComStr, MAKE) ComMake();
>else if (strcmp(ComStr, EDIT) ComEdit();
>else if (strcmp(ComStr, SAVE) ComSave();
>else if (strcmp(ComStr, OPEN) ComOpen();
>else if (strcmp(ComStr, SORT) ComSort();
>else if (strcmp(ComStr, HELP) ComHelp();
>
>というのが、何十行も続くものを書いたことがあります。
>こういう場合だったら、やっぱりマルチステートメントの方が
>見やすいと思いませんか………？
僕なら関数ポインタを活用して for 文で処理するけどな。

// 例
static struct table_t {
const char *str;
void (*pfunc)(void);
} table[] = {
LIST, ComList,
MAKE, ComMake,
EDIT, ComEdit,
SAVE, ComSave,
OPEN, ComOpen,
SORT, ComSort,
HELP, ComHelp,
NULL, NULL,
};

for ( struct table_t *p = table ; p->str != NULL ; p++ ){
if ( !strcmp(cmdname,p->str) ){
p->pfunc();
return;
}
}
printf( コマンドエラー\n );
return;

こんな感じです。

追記。
コーディング(ルール)も重要ですが
アルゴリズムの追求・研究も重要だと思う。

>// コマンドによって処理を分岐
>if (strcmp(ComStr, LIST) ComList();
>else if (strcmp(ComStr, MAKE) ComMake();
>else if (strcmp(ComStr, EDIT) ComEdit();
>else if (strcmp(ComStr, SAVE) ComSave();
>else if (strcmp(ComStr, OPEN) ComOpen();
>else if (strcmp(ComStr, SORT) ComSort();
>else if (strcmp(ComStr, HELP) ComHelp();
>
>というのが、何十行も続くものを書いたことがあります。

アルゴリズムの話が出たので一言。
このコード、劇的に遅いです。
CMapを使いましょう。

LIST,MAKE,...をキーにして、ComList(),ComMake(),...の関数ポインタを
CMap::SetAt()するか、

もう少し分かりやすくするなら、
enum ECmdNum
{
ECN_List,
ECN_Make,
:
};
LIST,MAKE,...をキーにして、ECN_List,ECN_Make,...をCMap::SetAt()した
上で、
switch()
{
case ECN_List:
break;
case ECN_Make:
break;
:
}

>CMapを使いましょう。
ん？MFC使用している様には見えないのだが。。

>>CMapを使いましょう。
>ん？MFC使用している様には見えないのだが。。

「素直に連想配列(辞書)使いなさいよ」の意じゃねぇですかしら。

そうです、
連想配列(辞書) 要するに ハッシュ を使った方がいいよという意味です。

ただ、連想配列とかハッシュとかそう言う言葉だと知らない人には伝わらないので
あえて、CMapと言ってみました。

かえって分かりづらくなってしまったようで失礼

> というのが、何十行も続くものを書いたことがあります。
> こういう場合だったら、やっぱりマルチステートメントの方が
> 見やすいと思いませんか………？

まにさんが書き直したマルチステートメントのソースコードを貼ったら、
どっちが見やすいかの意見が集まると思いますよ。

> 連想配列(辞書) 要するに ハッシュ を使った方がいいよという意味です。

ぃゃぃゃ、連想配列(associative-array)とハッシュはまた別物ですぜ。
連想配列の実装のひとつがハッシュであるってだけで。
# std::map だとbinary-tree実装だし

>ぃゃぃゃ、連想配列(associative-array)とハッシュはまた別物ですぜ。
>連想配列の実装のひとつがハッシュであるってだけで。
># std::map だとbinary-tree実装だし

なるほど、勉強になりました φ(..)メモメモ

bunさん、イラン突っ込み申し訳ありません。
επιστημηさん、フォローあろがとうございました。
納得です。