3

私は最近このコードに出くわしました：

do {
    if ( ! checkSomething() )
        break;

    // some code

    if ( ! checkSomeOtherThing() )
        break;

    // some other code
} while(false);

// some final code

それを書いたプログラマーは、の行に沿ってコメントを書きました"cleaner control flow"。

私の意見では、元のコードを別のコードにリファクタリングすると、見栄えが良くなる可能性があります。しかし、この声明には真実がありますか？この構成は良いですか？

4

4 に答える 4

6

これははるかに読みやすく、同じ結果が得られます。

if ( checkSomething() )
{
    // some code
    if ( checkSomeOtherThing() )
    {
        // some other code
    }
}
// some final code

通常はフォローするのが難しいと思いますdo ... whileが、ループ以外の目的で使用するのは、せいぜい誤解を招く恐れがあります。

于 2010-12-06T00:10:28.960 に答える
3

これは。と同等gotoです。

このような状況ではgoto、醜いハックを使用するよりもを使用する方が適切です。

を使用するように変更すると、gotoはるかに読みやすくなります。

if (!checkSomething())
    goto Done;

// some code

if (!checkSomeOtherThing())
    goto Done;

// some other code
Done: //some final code
于 2010-12-06T00:20:10.663 に答える
2

複数のステートメントを含むループを気にしない場合break、ここでの唯一の問題は、C（明らかな理由で）が裸のブロックから抜け出せないことです。したがって、疑いを持たない将来のメンテナが誤解する可能性のある「非ループ」です。実際のループの場合。

考慮事項は次のとおりです。

  • ポイントが2つしかない場合、2つのステートメントbreakの何が悪いのでしょうか。if
  • ブレークポイントが3つ以上ある場合、ifステートメントのインデントが不快になる可能性があります。これにより、それを節約できますが、関数の実行が多すぎますか？gotoそして、そうでない場合でも、ループしないループの奇妙さを使用して回避する方が良いでしょうか？

この言語に依存しないタグを付けるので、私はマクロ化されたアセンブリ言語を使用していましblockたendblock。これにより、次のような必要な条件をチェックするための適度に優れたコードが得られます。

block
    breakif str1 == null
    breakif str2 == null
    get some combined property of str1 and str2
    breakif some other condition that stops us getting on with it
    get on with it
endblock

実はそうではなかったbreakif str1 == nullし、そうだったのですがbreakifeq.p str1, null、正確に何を忘れているのでしょうか。

于 2010-12-06T00:16:32.847 に答える
0

コーダーが準拠する標準として do-while 形式が採用されているのを見てきました。利点は、ループが常に少なくとも 1 回実行されることを伝え、実装することです。これにより、ループ内のコードが実行されないなど、何か異なる状況が発生する状況を一貫性を持って切り分けることができます。

Warnier-Orr 法が適用されていたため、この規格が採用されました。

于 2010-12-06T04:06:11.840 に答える