PVS-Studio AnalyzerがUnityプロジェクトでより多くのエラーを見つけ始めた方法

PVS-Studioスタティックアナライザーの開発中、さまざまな方向で開発を試みています。したがって、私たちのチームはIDE（Visual Studio、Rider）のプラグインに取り組んでおり、CIとの統合を改善しています。Unityのプロジェクト分析の効率を上げることも、私たちの優先目標の1つです。静的分析により、このゲームエンジンを使用するプログラマは、ソースコードの品質を向上させ、プロジェクトでの作業を簡略化できると考えています。したがって、Unity向けに開発している企業の間でPVS-Studioの人気を高めたいと思います。このアイデアを実装する最初のステップの1つは、エンジンで定義されたメソッドのアノテーションを記述することでした。これにより、アノテーション付きメソッドの呼び出しに関連付けられたコードの正確さを制御できます。

前書き

注釈は、最も重要なアナライザーメカニズムの1つです。これらは、引数、戻り値、および自動的に把握できないメソッドの内部機能に関するさまざまな情報を提供します。同時に、注釈プログラマーは、文書化と常識に基づいて、メソッドのおおよその内部構造とその作業の機能を提案できます。



たとえば、返される値が使用されていない場合、GetComponentメソッドの呼び出しは少し奇妙に見えます。でたらめの間違い？どういたしまして。もちろん、これは単に忘れられ、見捨てられた余分な挑戦であるかもしれません。または、いくつかの重要な割り当てが欠落している可能性があります。注釈は、アナライザーが同様のエラーや他の多くのエラーを見つけるのに役立ちます。



もちろん、アナライザー用の多くの注釈をすでに書いています。たとえば、System名前空間のアノテーション付きクラスメソッド。さらに、いくつかのメソッドに自動的に注釈を付けるメカニズムもあります。これについて詳しくは、こちらをご覧ください。この記事では、C ++でプロジェクトを分析するPVS-Studioの部分について詳しく説明しています。ただし、C＃とC ++の注釈の動作には明確な違いはありません。

Unityメソッドのアノテーションを書く

Unityを使用してプロジェクトのコードレビューの品質を向上させるよう努めているため、このエンジンのメソッドに注釈を付けることが決定されました。



もともとのアイデアは、アノテーションですべてのUnityメソッドをカバーすることでしたが、それらの多くがありました。その結果、最も一般的に使用されるクラスのメソッドに注釈を付けることから始めることにしました。

情報収集

まず、他のクラスよりも使用頻度の高いクラスを見つける必要がありました。さらに、重要な側面は、注釈の結果を収集する機能を提供することです-書かれた注釈が原因でアナライザーが実際のプロジェクトで検出する新しいエラー。したがって、最初のステップは、関連するオープンソースプロジェクトを見つけることでした。しかし、これはそれほど簡単ではないことがわかりました。



問題は、見つかったプロジェクトの多くがソースコードの点で非常に小さいことです。そのため、エラーがある場合、エラーはそれほど多くなく、Unityのメソッドに特に関連するポジティブが見つかる可能性はさらに低くなります。 Unity固有のクラスを実際には使用しなかった（またはまったく使用しなかった）プロジェクトもありましたが、説明によると、それらは何らかの形でエンジンに接続されていました。そのような発見は、目前の仕事には完全に不向きでした。



もちろん、時々私は幸運でした。たとえば、このコレクションの宝石はMixedRealityToolkitです。その中にはまともなコードがすでにあります。つまり、そのようなプロジェクトでのUnityメソッドの使用に関する収集された統計はより完全になります。



したがって、エンジンの機能を使用して20のプロジェクトが採用されました。最も一般的に使用されるクラスを見つけるために、RoslynベースのユーティリティがUnityからのメソッド呼び出しをカウントするように作成されました。ちなみに、このようなプログラムは静的アナライザーと呼ぶこともできます。結局のところ、あなたがそれについて考えれば、彼女はプロジェクト自体を起動することに頼ることなく、本当にソースコードを分析します。



書かれた「アナライザー」はクラスを見つけることを可能にしました、見つけられたプロジェクトでの平均使用頻度は最高です：

• UnityEngine.Vector3
• UnityEngine.Mathf
• UnityEngine.Debug
• UnityEngine.GameObject
• UnityEngine.Material
• UnityEditor.EditorGUILayout
• UnityEngine.Component
• UnityEngine.Object
• UnityEngine.GUILayout
• UnityEngine.Quaternion
• 等。

もちろん、これはこれらのクラスが実際に開発者によって頻繁に使用されることを決して意味しません-結局のところ、そのような小さなプロジェクトのサンプルに基づく統計はあまり信頼できません。ただし、この情報を開始することで、少なくともどこかで使用されているクラスのメソッドに確実に注釈を付けることができました。

注釈

必要な情報を取得したら、次は実際のアノテーションを開始します。この問題の真の助力者は、テストプロジェクトが作成されたドキュメントとUnityエディターでした。これは、ドキュメントで指定されていないいくつかの点を確認するために必要でした。たとえば、引数にnullを渡すとエラーが発生するのか、それともプログラムが問題なく動作し続けるのかは常に明確ではありませんでした。もちろん、原則としてnullを渡すことは完全に良いことではありませんが、この場合、実行のスレッドを中断したエラー、またはUnityエディターによってエラーとしてログに記録されたエラーのみを考慮しました。



そのようなチェック中に、いくつかの方法の作業の興味深い特徴が見つかりました。たとえば、コードを実行する

MeshRenderer renderer = cube.GetComponent<MeshRenderer>();
Material m = renderer.material;
List<int> outNames = null;
m.GetTexturePropertyNameIDs(outNames);

Unityエディター自体がクラッシュするという事実につながりますが、通常、このような場合、現在のスクリプトの実行が中断され、対応するエラーがログに記録されます。もちろん、開発者がこれを頻繁に書くことはまずありませんが、Unityエディターが通常のスクリプトを実行することでクラッシュする可能性があるという事実はあまり良くありません。同じことが、少なくとももう1つのケースで発生します。

MeshRenderer renderer = cube.GetComponent<MeshRenderer>();
Material m = renderer.material;
string keyWord = null;
bool isEnabled = m.IsKeywordEnabled(keyWord);

これらの問題はUnity Editor 2019.3.10f1に関連しています。

結果の収集

注釈を付けた後、これが発行された警告にどのように影響するかを確認する必要があります。選択したプロジェクトごとに注釈を追加する前に、エラーを含むログが生成されます。これを参照と呼びます。次に、新しい注釈がアナライザーに組み込まれ、プロジェクトが再チェックされます。生成された警告のリストは、注釈のおかげで、参照リストとは異なります。



注釈テスト手順は、これらのニーズのために特別に作成されたCSharpAnalyserTesterプログラムを使用して自動的に実行されます。プロジェクトの分析を開始した後、結果のログと参照ログを比較し、相違点に関する情報を含むファイルを生成します。



ここで説明する方法は、新しい診断を追加したり、既存の診断を変更したりしたときに、ログにどのような変化が現れるかを見つけるためにも使用されます。



前述のように、Unityの下で大規模なオープンプロジェクトを見つけるのは困難でした。アナライザーがより興味深い応答を生成できるため、これは不愉快です。同時に、参照ログと注釈の後に形成されたログの間には、はるかに多くの違いがあります。



それにもかかわらず、書かれた注釈は、検討中のプロジェクトのいくつかの疑わしいポイントを特定するのに役立ちました。これもまた、作業の楽しい結果です。



たとえば、GetComponentへのやや奇妙な呼び出しが見つかりました：

void OnEnable()
{
  GameObject uiManager = GameObject.Find("UIRoot");

  if (uiManager)
  {
    uiManager.GetComponent<UIManager>();
  }
}

アナライザー警告：V3010関数「GetComponent」の戻り値を利用する必要があります。-現在の追加UIEditorWindow.cs 22 ドキュメントに



基づいて、このメソッドによって返された値を何らかの方法で使用する必要があると結論付けるのは論理的です。したがって、注釈を付けると、それに応じてマークが付けられました。すぐに、呼び出し結果は何にも割り当てられず、少し奇妙に見えます。 さらに、追加のアナライザートリガーの別の例を次に示します。

public void ChangeLocalID(int newID)
{
  if (this.LocalPlayer == null)                          // <=
  {
    this.DebugReturn(
      DebugLevel.WARNING, 
      string.Format(
        ...., 
        this.LocalPlayer, 
        this.CurrentRoom.Players == null,                // <=
        newID  
      )
    );
  }

  if (this.CurrentRoom == null)                          // <=
  {
    this.LocalPlayer.ChangeLocalID(newID);               // <=
    this.LocalPlayer.RoomReference = null;
  }
  else
  {
    // remove old actorId from actor list
    this.CurrentRoom.RemovePlayer(this.LocalPlayer);

    // change to new actor/player ID
    this.LocalPlayer.ChangeLocalID(newID);

    // update the room's list with the new reference
    this.CurrentRoom.StorePlayer(this.LocalPlayer);
  }
}

アナライザーの警告：

• V3095 'this.CurrentRoom'オブジェクトは、nullに対して検証される前に使用されました。チェック行：1709、1712。-現在のLoadBalancingClient.cs 1709に追加
• V3125「this.LocalPlayer」オブジェクトは、nullに対して検証された後に使用されました。チェック行：1715、1707。-追加の現在のLoadBalancingClient.cs 1715

PVS-StudioはLocalPlayerをstring.Formatに渡すことに注意を払っていないことに注意してください。そして、コードは意図的に書かれたように見えます。



この場合、注釈の効果はそれほど明白ではありません。しかし、これらのポジティブを出現させたのは彼らでした。問題が発生します-なぜこれらの警告は以前にはなかったのですか？



実際のところ、DebugReturnメソッドでいくつかの呼び出しが行われ、理論的にはCurrentRoomプロパティの値に影響を与える可能性があります。

public virtual void DebugReturn(DebugLevel level, string message)
{
  #if !SUPPORTED_UNITY
  Debug.WriteLine(message);
  #else
  if (level == DebugLevel.ERROR)
  {
    Debug.LogError(message);
  }
  else if (level == DebugLevel.WARNING)
  {
    Debug.LogWarning(message);
  }
  else if (level == DebugLevel.INFO)
  {
    Debug.Log(message);
  }
  else if (level == DebugLevel.ALL)
  {
    Debug.Log(message);
  }
  #endif
}

アナライザーは呼び出されたメソッドの機能を認識していないため、それらがどのように状況に影響を与えるかは不明です。そのため、PVS-Studioはthis.CurrentRoomの値がDebugReturnメソッドの操作中に変更される可能性があると想定しているため、さらに検証が行われます。



アノテーションは、DebugReturn内で呼び出されたメソッドが他の変数の値に影響しないという情報を提供しました。したがって、nullかどうかをチェックする前に変数を使用することは疑わしいことです。

結論

まとめると、Unity固有のメソッドにアノテーションを付けることで、このエンジンを使用するプロジェクトでさまざまなエラーを見つけることができることは間違いありません。それにもかかわらず、利用可能なすべてのメソッドのアノテーションをカバーするには、多くの時間が必要になります。最も頻繁に使用されるものに最初に注釈を付ける方が効率的です。ただし、どのクラスがより頻繁に使用されるかを理解するには、コードベースが大きい適切なプロジェクトが必要です。さらに、大規模なプロジェクトでは、注釈の効果をより適切に制御できます。近い将来、これらすべてに対処していきます。



アナライザーは常に開発され、改良されています。Unityメソッドにアノテーションを追加することは、その機能を拡張する1つの例にすぎません。したがって、時間の経過とともに、PVS-Studioのパフォーマンスは向上します。したがって、PVS-Studioをまだ試していない場合は、対応するページからダウンロードして修正してください。そこで、さまざまなプロジェクトをチェックして、アナライザーの機能を理解するためのトライアルキーを取得できます。

この記事を英語を話すユーザーと共有したい場合は、翻訳リンクNikita Lipilinを使用してください。PVS-StudioアナライザーがUnityプロジェクトでさらに多くのエラーを検出し始めた方法。