CをサポートするPVS-Studioの実験バージョン＃

PVS-Studioアナライザーの実験版があり、C＃-projectsを分析でき、世界中に表示できます。 これはリリースではなく、ベータ版でもありません。 これは、現在のPVS-Studioのビルドです。 ユーザーまたは潜在的なユーザーからC＃サポートに関するフィードバックをできるだけ早く取得したいと考えています。 そのため、C＃プロジェクトでPVS-Studioの新しいバージョンを試してみて、結果、欠点、希望を表明する愛好家を募集しています。 そうそう、もちろんこの記事では、次のプロジェクトであるSharpDevelopの検証結果について説明します。

PVS-Studio

ここで重要な質問の1つは、「C＃用の別のコード分析ツールを作成する理由」です。



移動する場所と理由を明確に理解するために、潜在的なユーザーと自分自身の両方に回答してみましょう。



C / C ++言語用のPVS-Studioアナライザーを作成し、開発を継続しています。 このアナライザーは、さまざまなタイプのエラーを識別するための多くの興味深いユニークなアイデアを実装しています。 時間が経つにつれて、実装された診断の多くが特定のプログラミング言語に関連付けられていないことが明らかになりました。 使用する言語は関係ありません。 タイプミス、不注意によるエラー、またはコピーペーストの失敗が常にあります。



そして、私たちの経験を別のプログラミング言語であるC＃に適用しようとすることにしました。 これがどれほど成功するか、時間はわかります。 私たちは、多数のC＃開発者から利益を得ることができる非常に興味深いツールを徐々に作成できると考えています。



現在、私たちの仕事は、できるだけ早く潜在的なユーザーからフィードバックを受け取ることです。 PVS-Studioアナライザーのフルバージョンはまだ準備ができていません。 現在、診断はほとんどありません（執筆時点では36個ありました）。 ただし、このバージョンをインストールして試すことはできます。 そして、これを行うすべての人に感謝します。 一般的に正しい方向に進んでおり、分析装置全体が動作していることを確認することが重要です。 そして、新しい診断を非常に迅速に追加します。



したがって、興味のある方は、次のリンクからPVS-Studioの実験バージョンの最新バージョンをダウンロードすることをお勧めします： http : //files.viva64.com/beta/PVS-Studio_setup.exe



ご注意 時間が経つにつれて、上記のリンクは無効になります。 したがって、公開から1か月以上経過してからこの記事を読む場合は、現在の配布バージョンをインストールすることをお勧めします： http : //www.viva64.com/en/pvs-studio-download/



読者がPVS-Studioを試したことがない場合は、記事「 PVS-Studio for Visual C ++ 」を読むことをお勧めします。 ご覧のとおり、C ++に焦点を当てていますが、実際には違いはありません。 インターフェイスの観点から見ると、C ++プロジェクトとC＃プロジェクトのどちらで作業しても違いはほとんどありません。



フィードバックと提案を送信するには、フィードバックページを使用できます 。

SharpDevelopプロジェクトの検証

プログラマーにとって、通常の広告は機能しません。 しかし、私はこれらの真面目で非常に忙しいクリエイターの注目を集める方法を知っています。 さまざまなオープンソースプロジェクトをチェックし 、それに関する記事を書いています。 私たちのツールが何ができるかを示すことほど良い広告はありません。



車輪を再発明する理由はないと思います。 さて、同じ方法で、C＃プログラマーを魅了します。 また、開いているSharpDevelopプロジェクトのチェックに関する別の記事があります。



SharpDevelopは、C＃、Visual Basic .NET、Boo、IronPython、IronRuby、F＃、C ++の無料の開発環境です。 一般的にVisual Studio .NETの代替として使用されます。 Mono / GTK +-MonoDevelopにもフォークがあります。



プロジェクトが完全にC＃で記述されていることが重要です。 そのため、PVS-Studioの実験バージョンで確認できます。 プロジェクトには、拡張子が「cs」の8522個のファイルがあり、その合計サイズは45メガバイトです。

最も疑わしいコードスニペット

フラグメントN1

public override string ToString() { return String.Format("Thread Name = {1} Suspended = {2}", ID, Name, Suspended); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

警告PVS-Studio：V3025の形式が正しくありません。 'Format'関数を呼び出すときに、異なる数の実引数が予期されます。 予想：2.現在：3. Thread.cs 235



変数IDは、決して使用されません。 おそらくここに本当の間違いはないでしょう。 ただし、この場所は明らかにチェックする価値があります。 おそらく、ここで完全に異なるラインを形成することが計画されていたでしょう。



フラグメントN2

 public override string ToString () { return String.Format ("[Line {0}:{1,2}-{3,4}:{5}]", File, Row, Column, EndRow, EndColumn, Offset); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

警告PVS-Studio：V3025の形式が正しくありません。 'Format'関数を呼び出すときに、異なる数の実引数が予期されます。 予想：4.現在：6. MonoSymbolTable.cs 235



より興味深いケース。 プログラマーがまさに望んでいたことは、私には明らかではありません。 おそらく、彼は次のようなメッセージを作成したかったでしょう。



[ファイルfile.cs：10,20-30,40：7]



しかし、どうやら彼はいくつかのブレースを逃しました。 したがって、「、2」と「、4」がフィールドの配置を指定し、EndRow変数とEndColumn変数の値をまったく表示しないことがわかります。



次の書式設定行が正しいことを提案しようと思います。

 String.Format ("[Line {0}:{1},{2}-{3},{4}:{5}]", File, Row, Column, EndRow, EndColumn, Offset);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フラグメントN3

 static MemberCore GetLaterDefinedMember(MemberSpec a, MemberSpec b) { var mc_a = a.MemberDefinition as MemberCore; var mc_b = b.MemberDefinition as MemberCore; .... if (mc_a.Location.File != mc_a.Location.File) return mc_b; return mc_b.Location.Row > mc_a.Location.Row ? mc_b : mc_a; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3001「！=」演算子の左右に同じサブ式「mc_a.Location.File」があります。 membercache.cs 1306



ここではタイプミスを扱っています。 次の比較が正しい選択肢だと思います：

 if (mc_a.Location.File != mc_b.Location.File)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フラグメントN4

 public WhitespaceNode(string whiteSpaceText, TextLocation startLocation) { this.WhiteSpaceText = WhiteSpaceText; this.startLocation = startLocation; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3005「this.WhiteSpaceText」変数はそれ自体に割り当てられます。 WhitespaceNode.cs 65



美しい間違い。 ここで、静的アナライザーはその本質を示しました。 彼は気配りがあり、人と違って疲れません。 それで彼はタイプミスに気づいた。 彼女が見えますか？ 同意して、間違いを見つけるのは簡単ではありません。



したがって、1文字のタイプミス。 「= whiteSpaceText」と書く必要がありました。 そして、「= WhiteSpaceText」と表示されます。 その結果、クラスの「WhiteSpaceText」の値は変更されません。



これは一般に、変数に名前を付けるべきでないことの良い例です。 1つの小文字/大文字だけで名前を区別するのは悪い考えです。 ただし、コーディングスタイルに関する議論はこの記事の範囲外です。 さらに、それは神聖な議論の戦争を打つ。



フラグメントN5

 new public bool Enabled { get { return base.Enabled; } set { if (this.InvokeRequired) { base.Enabled = this.VScrollBar.Enabled = this.hexView.Enabled =this.textView.Enabled = this.side.Enabled = this.header.Enabled = value; } else { base.Enabled = this.VScrollBar.Enabled = this.hexView.Enabled = this.textView.Enabled = this.side.Enabled = this.header.Enabled = value; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3004「then」ステートメントは「else」ステートメントと同等です。 Editor.cs 225



「this.InvokeRequired」の値に関係なく、同じアクションが実行されることは非常に疑わしいです。 文字列「base.Enabled = .....」がコピーされたのではないかと強く思います。 そして、彼らはその中の何かを変えるのを忘れていました。



フラグメントN6、N7、N8、N9

 public override void Run() { .... ISolutionFolderNode solutionFolderNode = node as ISolutionFolderNode; if (node != null) { ISolutionFolder newSolutionFolder = solutionFolderNode.Folder.CreateFolder(....); solutionFolderNode.Solution.Save(); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3019「as」キーワードを使用した型変換後、おそらく誤った変数がnullと比較されます。 変数「node」、「solutionFolderNode」を確認します。 SolutionNodeCommands.cs 127



「ノード」がインターフェース「ISolutionFolderNode」から継承される場合、彼らはいくつかのアクションを実行したかった。 しかし、彼らは間違った変数をチェックしました。 正しいオプション：

 ISolutionFolderNode solutionFolderNode = node as ISolutionFolderNode; if (solutionFolderNode != null) {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ちなみに、これはC＃プログラムでかなり一般的なエラーパターンです。 たとえば、SharpDevelopプロジェクトでは、このようなエラーがさらに3つ発生しました。

• V3019「as」キーワードを使用した型変換後に、誤った変数がnullと比較される可能性があります。 変数「geometry」、「g」を確認してください。 PathHandlerExtension.cs 578
• V3019「as」キーワードを使用した型変換後に、誤った変数がnullと比較される可能性があります。 変数「oldTransform」、「tg」を確認します。 ModelTools.cs 420
• V3019「as」キーワードを使用した型変換後に、誤った変数がnullと比較される可能性があります。 変数「node」、「solutionFolderNode」を確認します。 SolutionNodeCommands.cs 104

フラグメントN10

 public override void VisitInvocationExpression(....) { .... foundInvocations = (idExpression.Identifier == _varName); foundInvocations = true; .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3008「foundInvocations」変数には、連続して2回値が割り当てられます。 おそらくこれは間違いです。 行を確認：211、209。RedundantAssignmentIssue.cs 211



非常に疑わしい再割り当て。 おそらく、2番目の割り当ては、コードをデバッグするプロセスで記述され、その後それを忘れてしまったのでしょう。



エラーN11

 public static Snippet CreateAvalonEditSnippet(....) { .... int pos = 0; foreach (Match m in pattern.Matches(snippetText)) { if (pos < m.Index) { snippet.Elements.Add(....); pos = m.Index; } snippet.Elements.Add(....); pos = m.Index + m.Length; } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3008「pos」変数には連続して2回値が割り当てられます。 おそらくこれは間違いです。 チェック行：151、148。CodeSnippet.cs 151



別の不審な再割り当て。 ここでは、エラーまたは「pos = m.Index;」という割り当ては不要です。



フラグメントN12

 .... public string Text { get; set; } .... protected override void OnKeyUp(KeyEventArgs e) { .... editor.Text.Insert(editor.CaretIndex, Environment.NewLine); .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3010関数 'Insert'の戻り値を利用する必要があります。 InPlaceEditor.cs 166



C＃の文字列は不変です。 したがって、文字列を使用して何かを行う場合、結果をどこかに保存する必要があります。 しかし、例えばここで起こったように、それは忘れがちです。 開発者は、Insert（）メソッドを呼び出すことで、行に何かを追加することにしました。 しかし、これはそうではありません。 正しいコードは次のとおりです。

 editor.Text = editor.Text.Insert(editor.CaretIndex, Environment.NewLine);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フラグメントN13、N14

 public IEnumerable<PropertyMapping> GetMappingForTable(SSDL.EntityType.EntityType table) { var value = GetSpecificMappingForTable(table); var baseMapping = BaseMapping; if (baseMapping != null) value.Union(baseMapping.GetMappingForTable(table)); return value; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3010関数「Union」の戻り値を使用する必要があります。 MappingBase.cs 274



一般的に、C＃プロジェクトでは、プログラマーがオブジェクトの変更を予期しているという事実に関連するかなりの数のエラーが発生するという予感がありますが、これは起こりません。



IEnumerableインターフェイスを実装するコレクションに対して定義された 'Union'拡張メソッドを使用すると、2つのセットの共通部分を取得できます。 ただし、コンテナの「値」は変更されません。 正しいオプション：

 value = value.Union(baseMapping.GetMappingForTable(table));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

別のそのような状況はここにあります：V3010関数 'OrderBy'の戻り値を利用する必要があります。 CodeCoverageMethodElement.cs 124



フラグメントN15



PVS-Studioアナライザーは、プログラマーがスイッチ（）で何かを行うのを忘れるかもしれない状況を特定しようとしています。 警告するかどうかを決定するロジックは非常に複雑です。 誤検出が得られることもあれば、明らかなエラーが見つかることもあります。 これらのプラスの1つを検討してください。



そのため、コードには次のような列挙があります。

 public enum TargetArchitecture { I386, AMD64, IA64, ARMv7, }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

場所では、このリストのすべてのバリアントが使用されます。

 TargetArchitecture ReadArchitecture () { var machine = ReadUInt16 (); switch (machine) { case 0x014c: return TargetArchitecture.I386; case 0x8664: return TargetArchitecture.AMD64; case 0x0200: return TargetArchitecture.IA64; case 0x01c4: return TargetArchitecture.ARMv7; } throw new NotSupportedException (); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、疑わしい場所があります。 たとえば、アナライザーは次のコードに注意を向けました。

 ushort GetMachine () { switch (module.Architecture) { case TargetArchitecture.I386: return 0x014c; case TargetArchitecture.AMD64: return 0x8664; case TargetArchitecture.IA64: return 0x0200; } throw new NotSupportedException (); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3002 switchステートメントは、「TargetArchitecture」列挙型のすべての値をカバーしていません：ARMv7。 ImageWriter.cs 209



ご覧のとおり、アーキテクチャがARMv7の場合、大文字と小文字は区別されません。 これが間違いかどうかはわかりません。 しかし、これはまさに間違いであるように思えます。 名前ARMv7は列挙の最後にあります。つまり、最後に追加されたことを意味します。 その結果、プログラマはGetMachine（）関数の修正を忘れて、このアーキテクチャを考慮する必要がありました。



フラグメントN15

 void DetermineCurrentKind() { ..... else if (Brush is LinearGradientBrush) { linearGradientBrush = Brush as LinearGradientBrush; radialGradientBrush.GradientStops = linearGradientBrush.GradientStops; CurrentKind = BrushEditorKind.Linear; } else if (Brush is RadialGradientBrush) { radialGradientBrush = Brush as RadialGradientBrush; linearGradientBrush.GradientStops = linearGradientBrush.GradientStops; CurrentKind = BrushEditorKind.Radial; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3005「linearGradientBrush.GradientStops」変数はそれ自体に割り当てられます。 BrushEditor.cs 120



読むべきかなり重いコード。 そして明らかにそれが間違いを犯した理由です。 ほとんどの場合、コードはCopy-Pasteメソッドを使用して記述されており、1箇所で誤って変更されています。



どうやら、代わりに：

 linearGradientBrush.GradientStops = linearGradientBrush.GradientStops;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

書かれている必要があります。

 linearGradientBrush.GradientStops = radialGradientBrush.GradientStops;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

臭い

アナライザーが指す多くのフラグメントは、ほとんど実際のエラーではありません。 一方、このようなコードで発行されたメッセージは、誤検知とも呼ばれません。 通常、彼らは臭いがするようなコードについて言います。



上記では、エラーを含んでいると思われる多くのコードを見ました。 次に、匂いの例をいくつか示します。 私はすべての状況を考慮しませんが、それは面白くないです。 3つの例に限定します。 開発者は、SharpDevelopプロジェクトをチェックアウトすることで、残りの匂いに慣れることができます。



スニペットコードスニペットN1

 protected override bool CanExecuteCommand(ICommand command) { .... } else if (command == DockableContentCommands.ShowAsDocument) { if (State == DockableContentState.Document) { return false; } } .... else if (command == DockableContentCommands.ShowAsDocument) { if (State == DockableContentState.Document) { return false; } } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3003「if（A）{...} else if（A）{...}」パターンの使用が検出されました。 論理エラーが存在する可能性があります。 行を確認してください：773、798。DockableContent.cs 773



ご覧のとおり、プログラムには2つの同一のブロックが含まれています。 一番下のブロック「if」の条件は決して満たされません。 しかし、私の意見では、これは間違いではありません。 偶然にブロックを複製したように思えますが、それは不要です。 ただし、これは確認して修正する価値のある場所です。



スニペットコードスニペットN2

 void PropertyExpandButton_Click(object sender, RoutedEventArgs e) { .... ContentPropertyNode clickedNode = clickedButton.DataContext as ContentPropertyNode; clickedNode = clickedButton.DataContext as ContentPropertyNode; if (clickedNode == null) .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PVS-Studio警告：V3008「clickedNode」変数には、連続して2回値が割り当てられます。 おそらくこれは間違いです。 行を確認してください：105、104。PositionedGraphNodeControl.xaml.cs 105



コードは冗長であり、次のように簡略化できます。

 ContentPropertyNode clickedNode = clickedButton.DataContext as ContentPropertyNode; if (clickedNode == null)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードスニペットスニペットN3

 IEnumerable<ICompletionData> CreateConstructorCompletionData(IType hintType) { .... if (!(hintType.Kind == TypeKind.Interface && hintType.Kind != TypeKind.Array)) { .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

警告PVS-Studio：V3023この式の検査を検討してください。 表現が過剰であるか、誤植が含まれています。 CSharpCompletionEngine.cs 2392



冗長コード。 式は単純化できます：

 if (hintType.Kind != TypeKind.Interface) {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

続行できますが、それで十分です。 他のすべての「匂い」はかなり均一で、すでにリストされているものに似ています。

おわりに

ご覧のとおり、C＃言語だけでは愚かなエラーを防ぐことはできません。 したがって、私はこの写真をここに明確な良心をもって持ち込むことができます。







ユニコーンは長く生き続けます。ユニコーンは、C＃プログラムのエラーを見つけることを学びました。



しかし、真剣に、それから：

• プログラミングするとき、私たちは皆、複雑なだけでなく、単純な間違いも犯します。 合計すると、単純なエラーの検索に多くの時間が費やされます。 そして時々 たくさん 。
• 静的コード分析のツールを使用すると、コードを記述する段階でも、多数の単純なエラーを検出できます。 このようなツールを使用すると、多くの時間を節約でき、多くのエラーの検索とデバッグに費やすことができます。
• 静的解析で最も重要なことは、定期的な使用です。 静的分析の1回限りのチェックには意味がありません。 その全体的なポイントは、エラーがコードに現れた直後にエラーを見つけることです。 まれなチェックは時間がかかり、ほとんど役に立ちません。 結局のところ、すでにこの瞬間までにすばやく簡単に発見できるこれらの間違いは、汗と血で修正されました。

この記事を英語圏の聴衆と共有したい場合は、翻訳へのリンクを使用してください：Andrey Karpov。 C＃サポート付きのPVS-Studioの実験版 。