🌉 🕴🏼 💦 PVS-Studioを使用したMicrosoft Orleansプロジェクトのテスト 😔 👩🏼‍🚀 🚖

はじめに

すべての良い一日。

まず、疑う人のための小さな免責事項：はい、この投稿では、おそらくオープンなMicrosoft OrleansプロジェクトをテストするためのPVS-Studioのライセンスを取得します。または、チップがどのように落ちるか分からないかもしれません。いいえ、私はプログラム検証システムに直接接続しておらず、この投稿を自分のイニシアチブで書いています。

それでは、ポイントに行きましょう。

同社の公式Webサイトによると、 PVS-Studio 6.0は、使いやすさとコード記述段階でのエラーの発見に焦点を当てた静的コードアナライザーです。

そして比較的最近、同社はC＃プロジェクトの検証をサポートするバージョンをリリースしました。実際にMicrosoft Orleansプロジェクトを確認するよりも。

ちなみに、PVS-Studioチームは、検出されたエラーについてOrleansプロジェクトもチェックしましたが、少し先に進み、絶えず心地よいユニコーンでKDPV（「注意を引くための画像」）を親切に提供してくれました。

PVS-Unicorn-In-Clouds

オルレアンプロジェクト、バーチャルアクター、およびその利益とは何ですか。

Microsoft Orleansは、仮想アクターの概念に基づいて構築されたフレームワークです。 Orleansの用語は、他の同様のフレームワーク（Akka.Net、Service Fabric、Erlang Actors）とは少し異なります。アクターはGrains （別名穀物）と呼ばれ、クラスターに参加しているサーバーはSiloと呼ばれます。

仮想アクターの利点は、いつでもコードがOrleans Runtimeからプロキシを取得して、そのインターフェイスとIdを介して特定のGrainにアクセスできることです。プロキシメソッドを呼び出すと、メッセージは複数のサーバーのクラスターに送信され、そこで特定のIDでGrainに配信されます。ランタイムは、そのようなGrainがいずれかのサーバー上の単一のコピーで作成され、後続の呼び出しがそのGrainに配信されることを保証します。また、ランタイムは、一定時間コールを受信しなかったグレインを自動的に削除（非アクティブ化）するため、ガベージを常に収集します。「グレイン」が以前に配置されていたサーバーがオフラインになった場合-ランタイムはインスタンスをすぐに別のインスタンスに上げ、わずかな遅延以外は何も気付かないでしょう。呼び出しが同じサーバーに到達する場合-ランタイムはそれを最適化し、呼び出しはローカルになります。

実際、仮想アクターの利益は、クラウドで非常に簡単にスケーリングできることです。

サイロはお互いにpingを実行し、誰かがアクセスできないときを判断し、「倒れた同志」の粒を自分自身とすべての間で再配布します。クラスターは、アクティブなサイロが少なくとも1つ存在し、新しい参加者が接続されると、独自の範囲の「グレイン」を受け取り、アクティブにリクエストを処理し始める限り、存続して利用可能です。そして、使い慣れたOOPアプローチを使用してコードを記述します。「Distributed C＃/。NET」のようになります。

ランタイム自体も、メソッドがグレインで実行されたときに、他の呼び出しが同じグレインに到達しないことを保証します。ランタイムは、コードのシングルスレッド実行を保証します。これにより、スレッドセーフでない状況について考える必要がなくなり、有用なビジネスロジックの作成に集中できます。

一般に、交換可能なストレージプロバイダー、メッセージング、pub-subなど、クラウド（またはオンプレミスの分散型）プラットフォーム向けアプリケーションの開発に役立つものなど、他にも多くの興味深いものがあります。

プロジェクトの詳細については、 Microsoft Orleans @ GitHubをご覧ください。 Microsoft Orleansは、大規模プロジェクトでも十分にテストされています。このフレームワークは、Halo 4およびHalo 5ゲームのバックボードで使用され、すべてのゲームに関する情報、統計の集計などを収集します。

オルレアンをチェックアウトしたい理由

まず、私たち自身がOrleansを使用してDrawboardでクラウドプラットフォームを作成しています。便利で信頼性の高いフレームワークに依存したいと思います。

第二に、Orleansで定められている概念と保証はかなり重要であり、クラスター操作の品質はその実装に依存します。

第三に、C＃でPVS-Studioを試してみるのはおもしろかった-製品チームはC ++プロジェクトのチェックに関する優れた記事を書いたが、最近までC＃は何とか注意を奪われていた。

検証結果

Microsoft Orleansプロジェクトは非常に動的に開発されており、疑わしい場所を見つけるのには役立ちますが、1回限りのチェックは明らかに、長期的には全体的な品質に影響しません。

したがって、マージの時点で、PR＃1288 4/02/2016 2:43:26 PM, Commit hash: 7c1e35466fde08fcf1c2caf64fa304d25e60e045

PVS-Studio（バージョン6.01.15638.1）が発行されました：

18重大度の高いアラート
7中重大度の警告
58重大度の低いアラート

PVS-Studioでテストされた他のプロジェクト（複雑さ、コード量、開発者の能力、その他多くの要因）と比較できないため、これが良いか悪いかを言うのは困難です。

しかし、一般的に-それは最悪の結果のようには見えません、不審な場所の数は3桁または4桁の数字で表現されていません-1日ですべてを表示および処理できます。

PVS-Studioが深刻な問題を検出したかどうかを確認しましょう。

そしてまだ-ここに、メインコード（ランタイムおよびサポートプロジェクト）とテスト内のコードとの間のエラーの分離を示す表があります。

重大度	合計	ランタイム	テスト
高い	18	12 `*`	6
中	7	4	3
低い	58	13	45

*

-1つの方法でReplaceを不適切に使用した場合は4つの警告、未使用のコードでは3つの警告。合計で5に注意する価値があります。

主にランタイムのエラーについて説明します。通常、テストエラーはそれほど重大ではありません。彼らはすべてがOKであるという幻想を作成できますが、実際にはすべてがそれほどバラ色ではありません...

プロジェクトで検出された重大な警告

最も興味深いものから始めましょう、非常に深刻であることが判明しました。プロジェクト開発者は、このバグに起因する問題にも直面したことが判明しました

（これは、プロジェクトのGitterチャットで見つかった問題に関するものです）：

...最近IIRCが当惑させたSanitizeTablePropertyの恥ずべきバグ。

...消毒が機能することを確認しました。

PVS-Studioは次の警告を発行しました。

V3010関数 'Replace'の戻り値を使用する必要があります。 AzureStorageUtils.cs 278,279,280,281

そして、指定されたアドレスには（バグはすでに修正されています）メソッドがありました

 public static string SanitizeTableProperty(string key) { // Remove any characters that can't be used in Azure PartitionKey or RowKey values key.Replace('/', '_'); // Forward slash key.Replace('\\', '_'); // Backslash key.Replace('#', '_'); // Pound sign key.Replace('?', '_'); // Question mark if (key.Length >= 1024) throw new ArgumentException(string.Format("Key length {0} is too long to be an Azure table key. Key={1}", key.Length, key)); return key; }

かなりクールなバグ、ただのヘビ油（...そして、このバグが私たちのコードで数回クロールする可能性が高いという洞察がゆっくりとやって来ました....） 。

文字列型のキーパラメータもメソッドに渡されます。 .NETの文字key.Replace

は不変であるため、 key.Replace

を何度呼び出しても値は変わりません。

次の良い発見は

V3006オブジェクトは作成されましたが、使用されていません。 「throw」キーワードが欠落している可能性があります。新しいInconsistentStateException（FOO）をスローします。 MemoryStorageGrain.cs 129

 if (currentETag != null) { string error = string.Format("Etag mismatch during {0} for grain {1}: Expected = {2} Received = null", operation, grainStoreKey, currentETag.ToString()); logger.Warn(0, error); new InconsistentStateException(error); }

新しい例外はスローされますが、スローされません。つまり記録時にEtag = nullが送信され、これが最初のレコードである場合、エラーは発生しません。同じメソッドで少し低くなりますが、別の例外がまだスローされます-つまりここには問題がありません。

別の警告：

V3005「jsonSettings」変数はそれ自体に割り当てられます。 AzureTableStorage.cs 104

構成を読み取るとき、jsonSettings変数のシリアル化設定は2回初期化されます。

 if (useJsonFormat) { jsonSettings = jsonSettings = OrleansJsonSerializer.SerializerSettings; }

それほど重大な問題ではありませんが、私にとってはリファクタリングの結果のように見えます-「過去の人生」では、これらの変数の1つはおそらく別の方法で呼び出されました。その後、デフォルト設定用の別の変数が削除され、割り当てが残りました。

以下（この場合は誤報）：

** V3022式 'USE_DEBUG_CONTEXT_PARAMS && arguments！= Null && arguments.Length> 0'は常にfalseです。 GrainReference.cs 480 ***

 [NonSerialized] private const bool USE_DEBUG_CONTEXT_PARAMS = false; ... if (USE_DEBUG_CONTEXT_PARAMS && arguments != null && arguments.Length > 0) { ... }

デバッグフラグ。コンパイラはブランチのifを最適化します。それほど重要ではありませんが、コンテキストから何が起こるかは明らかです。ただし、このような場所を確認することは依然として重要です。重要で必要なコードが「c最適化」されないようにするためです。

この警告は使用頻度の低いコードで見つかったため、このセクションでは特別な問題は発生しませんでしたが、次のことが可能です。

V3025形式が正しくありません。 「フォーマット」関数を呼び出すときに、異なる数のフォーマット項目が予想されます。 予想：3.現在：2. Program.cs 169,183

 WriteStatus(string.Format("**Calling DeleteGrain({0}, {1}, {2})", silo, grainId)); WriteStatus(string.Format("**Calling LookupGrain({0}, {1}, {2})", silo, grainId));

これはそれほど重大な間違いではないように思えるかもしれません。まあ、ロガー、まあ、何かは記録されません。しかし、違います。実際、飛び出します-

FormatException: Index (zero based) must be greater than or equal to zero and less than the size of the argument list.

そして、次の警告は、コードロジックの実際の問題を示すことができます。幸いなことに、これはロギングのみです-

V3033この「else」ブランチは、前の「if」ステートメントに適用する必要がある可能性があります。 Interner.cs 251

 private void InternCacheCleanupTimerCallback(object state) { ... long numRemoved = numEntries - internCache.Count; if (numRemoved>0) if (logger.IsVerbose) logger.Verbose(ErrorCode.Runtime_Error_100296, "Removed {0} / {1} unused {2} entries in {3}", numRemoved, numEntries, internCacheName, clock.Elapsed); else if (logger.IsVerbose2) logger.Verbose2(ErrorCode.Runtime_Error_100296, "Removed {0} / {1} unused {2} entries in {3}", numRemoved, numEntries, internCacheName, clock.Elapsed); }

これはスタイル的に複雑なコードです-彼らが何をしたいのかはあまり明確ではありません。もちろん、あなたはそれを理解することができますが、このスタイルは読者の目を破るだけでなく、Appleからの驚きのような、あらゆる種類の不快なバグの機会を開きます。

Apple証明書チェックのバグ：

if（（err = SSLHashSHA1.update（＆hashCtx、＆serverRandom））！= 0）

gotoが失敗します。

if（（err = SSLHashSHA1.update（＆hashCtx、＆signedParams））！= 0）

gotoが失敗します。

gotoが失敗します。

そのようなものが表示されないようにするために、StyleCopおよび「適切なスタイルを適用する」他の多くの方法があります。また、使用するのにも便利です。

この場合も重要ではない別の警告は、単に冗長な検証です。しかし、チェックが計算上「高価」である場合-それを取り除く価値があります。

V3053過剰な表現。 サブストリング「/ bootstrap」および「/ boot」を調べます。 ClientGenerator.cs 310

 else if (arg.StartsWith("/bootstrap") || arg.StartsWith("/boot")){...}

これに関して、注目に値する重大なエラーは、もう少しMedium

と少し先にLow

なります。

中程度のエラーが見つかりました

最初の例は警告の例であり、問題のシグナルまたはホリバーの機会のいずれかです。

V3054潜在的に安全でない二重チェックロック。 これを回避するには、揮発性変数または同期プリミティブを使用します。 StreamImpl.cs 142、144

コードサンプルはわずかにカットされており、コメントのあるメインセクションのみが残っています。

 private readonly object initLock; // need the lock since the same code runs in the provider on the ... internal IAsyncBatchObserver<T> GetProducerInterface() { ->> // not so anonical double-checked locking, effectively doing the same, if (producerInterface != null) return producerInterface; lock (initLock) { if (producerInterface != null) return producerInterface; if (provider == null) provider = GetStreamProvider(); producerInterface = provider.GetProducerInterface<T>(this); } return producerInterface; } internal IInternalAsyncObservable<T> GetConsumerInterface() { ->> // Canonical double-checked locking if (consumerInterface == null) { lock (initLock) { if (consumerInterface == null) { if (provider == null) provider = GetStreamProvider(); consumerInterface = provider.GetConsumerInterface<T>(this); } } } return consumerInterface; }

ここでは、ダブルチェックロックパターンを使用する2つの例を示します。 .NETの世界のチャックノリス （Jon Skeetとも呼ばれます）の記事「 C＃でのシングルトンパターンの実装」は、シングルトンが必要な場合に、よりエレガントで信頼性の高い実装を提供します。

私もそれを書きたかった：

しかし、個人的にもう1つ疑問があります：この記事はすべての記事と例で常にstatic

オブジェクトのロックを使用し、信頼できる結果が保証された非static

ロックで使用できるかどうかはわかりません...

しかし、開発者と話をして、 Joe DuffyによるvolatileのSayonaraによるこの記事を読んだ後、私たちの場合、これはシングルトンではなく、非静的フィールドの使用は許可されています。そして、揮発性なし。

一般に、このエラーを調べて、コードの問題なのか、特にPVS-Studioのこの診断の問題なのかさえわからないような、自分用の「ワームの缶」を発見しました。

しかし、ツールがそのようなパターンを一般的にキャッチできるという事実は、私見、素晴らしいです。そして、将来的には、より洗練された、より良い警告が表示されることを願っています。

別の良い例に目を向けます。バグは人には非常にひどく捕らえられますが、アナライザーには簡単に捕らえられます。

V3022式 'n1 == 0 && n1！= 0'は常にfalseです。 符号なしの型の値は常に> = 0です。おそらく「||」 ここで演算子を使用する必要があります。 UniqueKey.cs 113

 private static UniqueKey NewKey(ulong n0, ulong n1, Category category, long typeData, string keyExt) { // in the string representation of a key, we grab the least significant half of n1. // therefore, if n0 is non-zero and n1 is 0, then the string representation will always be // 0x0 and not useful for identification of the grain. if (n1 == 0 && n1 != 0) throw new ArgumentException("n0 cannot be zero unless n1 is non-zero.", "n0");

ここでは、n0！= 0をチェックする必要がありました。これは、このコードへのコメントで記述されており、現在の実装では、チェックは常にfalseです。繰り返しますが、この場合は良いコーディングスタイルが役立ちます-変数がn0

とn1

、たとえばfirstHalf

とsecondhHalf

場合、エラーはより明白になります。比較する：

 if (firstHalf == 0 && secondHalf != 0) vs if (secondHalf == 0 && secondHalf != 0)

2つの異なる方法で同じコードに関する警告-

V3013「IncrementMetric」関数の本体が「DecrementMetric」関数の本体と完全に同等であることは奇妙です（1079、行1095）。 TraceLogger.cs 1079

Spaced Copy-Paste、これら2つの方法の間に正しい実装もあります

減少、メトリックを削減します。

 public override void IncrementMetric(string name, double value) { foreach (var tc in TelemetryConsumers.OfType<IMetricTelemetryConsumer>()) { ->> tc.IncrementMetric(name, value); } } ... public override void DecrementMetric(string name, double value) { foreach (var tc in TelemetryConsumers.OfType<IMetricTelemetryConsumer>()) { ->> tc.IncrementMetric(name, value); } }

同じですが、テストでは：

V3013「StartTimer」関数の本体が「StopTimer」関数の本体と完全に同等であることは奇妙です（183、188行目）。 TimerOrleansTest.cs 183

 public Task StartTimer(string timerName) { if (persistant) return persistantGrain.StartTimer(timerName); else return grain.StartTimer(timerName); } public Task StopTimer(string timerName) { if (persistant) return persistantGrain.StartTimer(timerName); else return grain.StartTimer(timerName); }

テストでのCtrl + C、Ctrl + Vからのこの挨拶は、より悪い結果をもたらす可能性があります-テストは偽陽性になります。

テストの複雑なコードは、10回または100回の開始に対して1つのエラーを生成する可能性があり、そのようなテストも刺激を引き起こします。

V3032この式で待機することは、コンパイラーがいくつかの変数を最適化する可能性があるため、信頼できません。 これを回避するには、揮発性変数または同期プリミティブを使用します。 LoggerTest.cs 468

 // Wait until the BulkMessageInterval time interval expires before wring the final log message - should cause bulk message flush while (stopwatch.Elapsed <= TraceLogger.BulkMessageInterval) { Thread.Sleep(10); }

正直なところ、私自身はこのサイクルが無限のサイクルに変わる方法と理由を本当に理解していませんが、PVS-Studio Webサイトのこの警告の説明の例は、より理解しやすいV3032です。

それほど大きな問題ではないテスト内のコードですが、理論的にも-ランダムに落下するテストや恒久的な凍結-は、最も楽しいものではありません。

そして再びテストの奇妙なコード-

V3051過剰なタイプチェック。 オブジェクトはすでに「例外」タイプです。 PersistenceGrainTests.cs 178

 catch (AggregateException ae) { exceptionThrown = true; Exception e = ae.GetBaseException(); ->> if (e is Exception) { // Expected error } else { throw e; } }

コードがelse

ブランチに入ることはないため、例外が再びスローされることはありません。重要度はコンテキストに依存します。テストではそれほど怖くないかもしれませんが、別のコードでは純粋なバグです

重大度が低いエラー

PVS-Studioはテストでかなりの数のコメントを見つけましたが、それらのほとんどを調べた後、それらの間に重大なまたは影響の大きい問題はないと結論付けることができます。そのような製品を包括的にテストすることは非常に難しく、多くの場合、システムの特定の動作を引き起こすためにさまざまなトリックを実行する必要があります。

たとえば、ここに：

V3008「promise」変数には、連続して2回値が割り当てられます。 おそらくこれは間違いです。 行を確認してください：91、84。TestInternalGrains ErrorGrain.cs 91

 // the grain method returns OK, but leaves some unobserved promise -->>Task<long> promise = Task<long>.Factory.StartNew(() => { if (!doThrow) return 0; logger.Info("About to throw 1."); throw new ArgumentException("ErrorGrain left Immideate Unobserved Error 1."); }); -->>promise = null; GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); GC.WaitForPendingFinalizers(); return Task.FromResult(11);

GCによってコンパイルされるタスクでのコードの動作が確認されます。

他のことに注意する必要があるもの（これらのエラーは、テスト中に誤った期待につながる可能性があります）：

V3013「ProduceSequentialSeries」関数の本体が「ProduceParallelSeries」関数の本体と完全に同等であることは奇妙です（618、625行目）。 StreamingGrain.cs 618

 public override async Task ProduceSequentialSeries(int count) { await base.ProduceParallelSeries(count); State.Producers = _producers; await WriteStateAsync(); } public override async Task ProduceParallelSeries(int count) { await base.ProduceParallelSeries(count); State.Producers = _producers; await WriteStateAsync(); }

テスト用の特別なクラスでは、連続した一連のイベントを生成するように設計されたメソッドが常に並列イベントを生成します。おそらくこれで問題ありませんが、テスト内のセマンティクスは誤解を招きます。

V3013「TestInitialize」関数の本体が「TestCleanup」関数の本体と完全に同等であることは奇妙です（44、52行目）。 ConfigTests.cs 44

 [TestInitialize] public void TestInitialize() { TraceLogger.UnInitialize(); GrainClient.Uninitialize(); GrainClient.TestOnlyNoConnect = false; } [TestCleanup] public void TestCleanup() { TraceLogger.UnInitialize(); GrainClient.Uninitialize(); GrainClient.TestOnlyNoConnect = false; }

構成テストでは、初期化中および完了時に、何らかの理由で、プリミティブのDE開始が2回実行されます。

V3043コードの操作ロジックがそのフォーマットに対応していません。 ステートメントは右側にインデントされますが、常に実行されます。 中括弧が欠落している可能性があります。 RequestContextTest.cs 87.97,111,155,181

 if(msg.RequestContextData != null) foreach (var kvp in msg.RequestContextData) { headers.Add(kvp.Key, kvp.Value); };

それでも、私は厳格なコーディングスタイルのルールの大きな支持者です。まあ、少なくともStyleCop、Resharper、CodeFormatterによって自動的にスタイルを強制します。費用はかかりませんが、目をつぶらないようにできます。

V3052元の例外オブジェクト「ae」が飲み込まれました。 元の例外のスタックが失われる可能性があります。 GrainReferenceCastTests.cs 212

 catch (AggregateException ae) { Exception ex = ae.InnerException; while (ex is AggregateException) ex = ex.InnerException; throw ex; }

スタックAggregatedExceptionが失われます。他の例外がある場合はこれが悪いことを理解していますが、このプロジェクトでは、同じ方法でAggregatedExceptionを「巻き戻し」ます。 AggregatedExceptionがcatchセクションにある場合、これを偽陽性で記述します。

プロジェクト開発者による発見されたバグの重要度評価。

送信されたすべてのエラーレポートのうち、3時間後に5がバグとしてマークされ、1はクリティカルでReplace

修正されました。自動モードで20分間の静的解析を行うと、かなり良い結果が得られます。

コード分析が今月の別のお気に入りではない理由。

Orleansプロジェクトは非常に集中的に開発されており、コミットの頻度は非常に高いとGihubは確認しています-Orleans -contributors 。記事の執筆中に、分析ログを保持しながら、プロジェクトを数回チェックしました。 PVS Studioの異なるバージョン（6.0および6.01）を含む。

さまざまなログの比較を次に示します。

優先順位	1月28日	2月2日	2月4日、v6.01	コメント
高い	19	21	18	2日で-3重大なエラー-これは良いです。しかし、たとえば、そのうちの2つは上記のV3025の類似物でした。そのようなコードをチェックすることさえできませんでした。
中	4	4	7	同じ2日間で、中程度の重大度の3つの警告。
低い	52	46	58	+12の新しいずさんなコードセクション。

表からわかるように、重大なエラーは非常に短い時間で現れたり消えたりします。数時間のデバッグや生産の落ち込みの後ではなく、ビルド直後に分析の結果としてそれらをキャッチする方が便利な場合、プログラマーの時間と神経を節約します。もちろん、 これは「貧乏人や病気よりも金持ちで健康な方が良い」シリーズのバナリティーですが、少なくとも一部の利用可能な静的コードアナライザーを使用しないプログラマーがいる場合-「あなたは間違っています」...

使いやすさの観点から-PVS-StudioとVisual Studio 2015の統合は非常に簡単です-C＃ファイル、プロジェクト、またはルートソリューションのソリューションエクスプローラーのコンテキストメニューには、 Analyze with PVS-Studio

アイテムが緑色のアイコンではっきりと表示されます。見つけるのはとても簡単です。このコンテキストメニューにのみ、他の拡張機能から100500ポイントがない場合。 Package Manger Consoleまたはbuild.cmdを開いてPVS-Solution

またはPVS-Project Orleans

と言うことができるように、コマンドラインから簡単に分析を実行できる補助的なNugetパッケージを見るのは興味深いでしょう。新しいCoreCLRのxprojメカニズムに組み込まれたもの。

ただし、 Ctrl+Q, PVS ... Down, Down, Down, Down, Enter

:)はクイックスタートには十分です。

おわりに

現代の開発の現実は、開発の速度に非常に高い水準を設定しています-少なくとも業界の競合他社のレベルにとどまるために、誰もが非常に迅速に前進しようとしています。当然のことながら、このような開発のスピードでは、何かを見逃したり、不注意に書くことができます。テストの広範なセットは、問題領域と回帰の特定に役立ちますが、これは万能薬でもありません-テストにエラーがあり、そのようなセットを作成し、それを最新に保つには、時間と労力がかかります。

Visual Studioの警告、Resharperのアナライザー、PVS-Studioのいずれの統計アナライザーも、開発者コレクションの別のツールであり、コードの潜在的な問題を検出するためのアシスタントです。少なくとも無料で入手できるものを使用してください。たとえば、すべてのプロジェクトで、警告をエラーとして扱うはデフォルトでオンになっています。これにより、少し規律のあるコードを書くことができます。これはプログラマに何の費用もかかりませんが、彼が自分の足で撃つのを防ぐことができます。最新のアナライザーを使用するのは非常に簡単です。ほとんどの場合、すべてが「そのまま」正常に動作し、少なくとも何らかの形でアナライザーの不使用を正当化できる唯一のことは価格の問題です。

NB： 著者は、テスト用の一時ライセンスを提供してくれたPVS-Studioチームに感謝します。

読む人全員-幸せでバグのないプログラミング！

PVS-Studioを使用したMicrosoft Orleansプロジェクトのテスト