問題タブ [code-readability]

コードにトレースを追加し始めているため、多くの混乱が生じていることに気付きました。Visual Studio ではコードを非表示にしたり表示したりできることは知っていますが、コードを "トレース" コードにグループ化し、コードを読んでいるときに自由に非表示にしたり表示したりしたいと考えています。ファイルごと、クラスごと、または関数ごとにこれを行うことができると思います。

これを行う方法はありますか？あなたたちは何をしますか？

いくつかの説明を追加する

現在の非表示機能を使用すると、これを行うことができますが、コードが非表示になっている場合、トレースされているかどうかはわかりません。また、何をしようとしているかに応じて関数を読み取るときに役立つ「すべてのトレース コードを非表示にする」および「すべてのトレース コードを表示する」とは言えません。

この質問を無視/クローズする前に、コードの明確化は議論の重要なトピックであり、保守可能なコードを書くために不可欠であるため、これは有効な質問であると考えています。 .

私は最近、この問題に遭遇しました.LINQクエリは、大量のネストのために非常に厄介なものになる可能性があります.

以下は、私が思いついた書式設定の違いの例です (同じ比較的複雑ではないクエリの場合)。

フォーマットなし

高度な書式設定

ブロックの書式設定

リストの書式設定

読みやすさと理解を最大化し、きれいでプロフェッショナルに見えるように、linq の書式設定の標準を考え出したいと思います。まだ判断がつかないので、プロの方に質問させてください。

今日、ReSharper の厚意により、C# 言語機能に出くわしました。オペレーター。これにより、コードを最初の試みよりもさらに簡潔にすることができました。行/長さ/コードの読みやすさを改善するための反復については、以下を参照してください。

最初の試みは次のようなものかもしれません..

..にリファクタリング

最初は上記が最も効率的/簡潔なバージョンだと思っていましたが、3番目のステップがあります...

C# 言語機能がコード行の削減と読みやすさの向上に役立つ同様の例があれば教えてください。

コードを読みやすくするために、以下のコードを変更するにはどうすればよいですか？

a）「workThreadMethod（）」を独自のクラスに移動します

b）このワーカースレッドクラスにメインの「プログラム」クラスからの静的変数を参照するコードがない

c）上記は主な2つの要件ですが、副作用として、テスト容易性のためにワーカースレッドクラスメソッドのテストが容易になり、理想的にはIOC（Ninjectなど）を介したテストに役立つことを期待しています。コンセプト[これが意味をなさない場合は、質問の目的のためにこの点を無視してください]

解決についてよくわからない主な課題は、元のスレッドと新しいスレッドの間の2つの異なる共有変数（1つは新しいスレッドが追加するConcurrentQueue、もう1つは元のスレッドが追加するbool変数）をどのように処理するかです。スレッドは、いつ停止するかを新しいスレッドに示すために使用します）

私たちのほとんどは等幅フォントを使用してコードを記述しますが、"m" 文字は (文字の組み合わせにもよりますが) 等幅フォントではよく見えません。あまりにも少ないスペースであまりにも多くのピクセルを使用しています。

誰かがこれについて私に同意するかどうか、私は興味があります.

これは純粋にコードの読みやすさに関する質問であり、クラスのパフォーマンスは問題ではありません。

この XMLHandler を構築する方法は次のとおりです。

アプリケーションに関連する各要素について、「ElementName」にブール値があり、解析中の場所に応じて true または false に設定しました: 問題、クラスの先頭に 10 以上のブール宣言があり、それがますます大きくなっています。

私の startElement と endElement メソッドには、数百行の

それらにはさまざまな解析ルールがあります（xmlファイルのこの位置にいる場合はこれを行い、そうでない場合はこれを行います...）

新しい構文解析ルールとデバッグのコーディングは、ますます困難になっています。

sax パーサーをコーディングするためのベスト プラクティスは何ですか?また、コードを読みやすくするにはどうすればよいですか?

(内部の最初のコードである条件が満たされないため) すぐに戻る .NET のメソッドを呼び出すオーバーヘッドは何ですか?

アプリケーションがどれほどリアルタイムであっても、そのオーバーヘッドは無視できるものであり、いずれにせよプロファイリングは事実を示すべきであり、可読性がより重要であると主張しますが、一部の同僚は私に同意せず、あなたがすべきだと言います常にそれらの呼び出しを避けてください...

他に意見は？

私は.h最善の意図を持ってファイルを整理することから始めますが、どういうわけかそれらはうんざりするほど乱雑になります。

以下は例です（これはそれほど悪くはありませんが、私ははるかに悪いことを見てきました！）。でセクションをグループ化してみまし#pragma markたが、さらに乱雑に見えるようです。

すべてのUILabelsとUIButtonsは（上記のように）必須です。これらはWebサービスリクエストからのデータを表示しているため、InterfaceBuilderを使用してGUIを設計する場合はすべて必須です。たとえば、ラベルは製品の「重量」または「高さ」の特性である可能性があります。

誰かがこれらを最も保守可能で読みやすい方法で整理する方法について何か良いアドバイスがありますか？

乾杯

本The Art of Unit Testingでは、保守可能で読みやすい単体テストを作成したいということが述べられています。204 ページあたりで、1 つのテストで複数のアサートを避けるようにし、オーバーライドされた Equals メソッドでオブジェクトを比較する必要があると述べています。これは、期待される結果と実際の結果を比較するオブジェクトが 1 つしかない場合にうまく機能します。しかし、上記のオブジェクトのリスト (またはコレクション) がある場合はどうでしょう。

以下のテストを検討してください。複数の主張があります。実際、アサートを呼び出す 2 つの別個のループがあります。この場合、アサーションは 5 つになります。1 つのリストの内容が別のリストに存在することを確認する 2 と、その逆の 2 です。リスト内の要素の数を比較する 5 番目。

このテストを改善するための提案があれば、私はすべて耳にします。現在は MSTest を使用していますが、MSTest の Assert を流暢な API (Assert.That) 用の NUnits に置き換えました。

現在のリファクタリングされたコード:

元のマルチアサート単体テスト:

Resharper を使い始めたばかりです。その機能の 1 つは、適切なコーディング プラクティスに基づいてコードの変更を提案することです。

提案された変更の 1 つは、割り当て中に変数の型を var に変更することです。私は変更を続けましたが、今ではコードのいたるところに var があります。「var」キーワードがコードを少し理解しにくくしているような気がします。

可能な限り「var」を使用することは良いコーディング慣行ですか、それとも実際の型に固執する方が良いですか? (「var」を使用する必要がある匿名型を除く)

ありがとう。