中かっこスープの取り扱い

私は何年もC＃とVB.NETの両方でプログラミングしましたが、主にVBでプログラミングしました。私はキャリアをC＃にシフトしていますが、全体的にはC＃の方が好きです。

しかし、私が抱えている問題の1つは、中括弧のスープです。VBでは、各構造キーワードに一致する近いキーワードがあります。次に例を示します。

Namespace ...
    Class ...
        Function ...
            For ...
                Using ...
                    If ...
                        ...
                    End If
                    If ...
                        ...
                    End If
                End Using
            Next
        End Function
    End Class
End Namespace

C＃で記述された同じコードは、非常に読みにくくなります。

namespace ... {
    class ... {
        function ... {
            for ... {
                using ... {
                    if ... {
                        ...
                    }
                    if ... {
                        ...
                    }
                }
            }
            // wait... what level is this?
        }
    }
}

VBにそのように慣れているので、読みやすさを改善し、コードが正しい「ブロック」になることを保証するためにCスタイルのプログラマーによって採用されている技術があるのだろうかと思っています。上記の例は比較的読みやすいですが、コードの最後に8レベル以上の中かっこがあり、興味のあるブロックを終了するブレースを特定するために、いくつかのページを上にスクロールする必要がありますに。

次のように、開始中括弧を終了と同じ「ランク」に入れます。

namespace ... 
{
    class ... 
    {
        function ... 
        {
            for ... 
            {
                using ... 
                {
                    if ... 
                    {
                        ...
                    }
                    if ... 
                    {
                        ...
                    }
                }
            }
            // It's the `function` level!
        }
    }
}

• IDEに応じて、カーソルをオープン/クローズブレースに置くと、そのブレースと対応するブレースの両方が強調表示されます。
• ブロックを折りたたむと、ブロックの開閉位置が表示されます。
• より小さいコードブロックを記述します。真剣に。をチェックしてClean Code、この問題に二度と出会うことはありません（より読みやすく保守しやすいコードを用意してください）。

1つの注意点として、以下は特定の状況に役立つ有効なc＃構文です。

using (var type = new MyDisposable1())
using (var type2 = new MyDisposable2())
{
    /* do what you will with type2 and type2 */
}

一般的な規則は、閉じ括弧の後にコメントを追加して、閉じている構造を示すことです。

if {
   ...
} // end if

while (condition) {
   ...
} // end while

など。私はこのコンベンションに自分自身を温めたことがありませんが、一部の人々はそれが役立つと感じています。

一般に、どのスタイルでもブレースを一致させることが困難になると、おそらくメソッドが長すぎてリファクタリングする必要があることを意味します。

中かっこで頑張る必要があると思います。最終的にそれらはあなたにとって二番目の性質になり、あなたは彼らなしでどうやって生きてきたのか不思議に思うでしょう。

ただし、それらが適切にインデントされていること、およびいくつかの間隔規則が守られていることを確認してください（どちらでもかまいません）。

名前空間とクラススコープを水平方向に折りたたみ、2レベルのネストを削除します。メソッドが画面の左端と同じ高さになっていることに注意してください。すべてのファイルで2レベルのインデントを失うことには意味がありません。

その後、4レベル以上の深さまでネストすることはほとんどありません。

namespace FooNameSpace {
class Foo {

public void bar()
{
    while(true)
    {
        while(true)
        {
            break;
        }
    }
}

public void fooBar()
{
    foreach(var item in FooList)
    {
        foreach(var b in item.Bars)
        {
            if(b.IsReady)
            {
                bar();
            }
            bar();
        }
        bar();
    }
}

}}//end class, namespace

私は最近、基本的に次のようなフロー制御構造に関する2つのルールを試してみることにしました。

• 必要なコードフロー構造だけが必要です
• コードフロー構造はできる限り小さくする必要があります

あなたが言及し、明確に認識している正確な理由から、これらは従うべき素晴らしいルールだと思います。それらを達成するために使用できるいくつかの簡単なテクニックがあります。

• できるだけ早くスコープを終了します（これには、ループのスコープと関数が含まれます）
• 前述のifから関数を終了することで軽減できる他の要素を監視し、前述のスコープ終了手法を適用します
• if内のコードが外部のコードよりも優れている場合、条件チェックを逆にします
• ループのサイズが大きくなり、メソッドの残りが不明瞭になると、ループ内のコードを別のメソッドに分解します
• 別のスコープのみを含むスコープ、たとえば、スコープ全体がifで満たされ、if以外に何も含まれていない関数を監視します

私は詳細にここにこれらはあなたが言ったようにやっている間違ったコードブロックにコードを置くことで終わることができ、以下ではない方法の例悪いとメンテナンス時までトリミングバグの簡単な原因を。

これは、残念ながら、コンピューティングにおける戦争の最も古い原因の1つです。両側から合理的な議論を行うことができます（垂直方向の不動産経済の改善と、開き中かっこと閉じ中かっこを視覚的に一致させる簡単な機能）が、実際には単純なソースコードフォーマッタがすべてを解決します。MS Visual C＃には、うまく機能するものが組み込まれています。

ただし、チームの一員として作業している場合は、そのチームが使用する規則に従うことが期待されるため、両方のスタイルにある程度精通し、ブレーススタイルよりも宗教的になることを控えることが重要です。

そのため、学習している間は、学習しやすいスタイルに焦点を当てますが、学習中は相手に目を向けてください。そうすればうまくいきます。

Resharperを使用します。これは、ネストを減らす方法を推奨するのに役立ちます。また、Bob Martinの著書Clean Codeを読んでください。関数は1つのことだけを行うべきであり、したがって、各関数は半ダースの行だけである必要があることを強調しています。

エディターには、C＃の概要で役立つアドオンがあります。

このアドオンは、ネストされたコードブロックを折りたたみ、展開、強調表示する機能を追加することで、C＃のVS20xxエディターを拡張します。これらの機能により、if、whileなどのコードブロックのネストされたコンテンツの編集と読み取りが容易になります。

Visual Studioでコードを記述する場合、構築するすべての構造の最初と最後の間に縦のドットを表示するプラグインもあります。

しかし、全体的には、「Curly-Braces-Soup」に慣れるまで少し時間がかかると思います。（ところで、私はその表現が本当に好きです。ビッグバン理論のエピソード名に少し似ています）

インデントは、構文の両方のスタイルで、現在地を示します。VBプログラムまたはC＃プログラムを1行で書くと、ネストされた構文のどこにいるかをすぐに知ることができなくなります。マシンはブロック終了フレーズまたは中括弧を解析しますが、人間にはインデントが必要です。

ブロックエンディングフレーズは、プログラミングがはるかにインタラクティブで視覚的ではなかった、パンチカードや紙テープの時代に由来します。または、実際にはまったくインタラクティブではありません。プログラムを入力することは困難であったため、プログラマーはコンパイラーに構文解析とエラー回復について非常に巧妙である必要がありました。

過去の時代では、編集-コンパイル-実行のサイクルには、カードパンチャーを使用してパンチカードを準備し、その後、店員がパンチカードを受け取ってマシンに送信するジョブ送信ウィンドウに並ぶ必要がありました。その後、プログラマは別のウィンドウから出力（紙に印刷）を収集します。プログラムにエラーがある場合、出力はコンパイラ診断のみで構成されます。ターンアラウンド時間が長い場合、プログラマは時間の無駄を減らすために1回の反復でできるだけ多くのエラーを修正する必要があるため、診断の品質の向上に役立つ場合end if、単なる入力ではなく入力の追加コスト)が正当化されますジョブ送信ウィンドウでの反復。

閉じ中括弧が欠落している場合、どの開き括弧が閉じられていないかを判断するのは困難です。（コンパイラーは、知識に基づいた推測を行うためにインデントを解析する必要がある場合があります。）関数内の右中括弧を削除すると、ファイルの残りの部分全体がその関数の一部であるように見えます。一方、end function構文がある場合、コンパイラはエラーのある関数がどこで終了するかを推測し、後続の関数を適切に回復、解析し、もしあれば、意味のある追加の診断を提供できます。

コードを自動的にインデントおよび色付けするコード対応テキストエディターで作業している場合、60行以上を表示できる高解像度画面では、これらの種類の不器用な言語の引数は適用されなくなります。プログラムを段階的に編集および再構築できるので、一度に1つのエラーに対処できます。さらに、画面上でプログラムの大きなセクションを同時に表示し、適切なインデントを維持することにより、そもそもこうした種類のネストエラーの発生を減らすことができます。また、優れたプログラミングテキストエディターは、入力時にいくつかの種類の構文エラーにフラグを立てます。さらに、構文に基づいてプログラムのブロックを折りたたみ、構造の「概要のような」ビューを提供する折りたたみエディターがあります。

Lispは最初から括弧を使用しましたが、おそらく偶然ではないが、Lispハッカーは、小さなチャンク（式）でプログラムを受け入れるシステムを構築することで、プログラミングをインタラクティブな体験として開拓しました。

実際、Python言語が示すように、終了記号はまったく必要ありません。インデントは単なるできること構造。人間はすでにマシンが終了記号やフレーズに依存している言語でも、インデントを使用してコードの構造を理解しています。

IDEを使用している場合は、Crtl+ k+ Dを押すだけで、IDEが残りの作業を行います。