🖖🏾 🐢 🔍 Tizen：C＃コンポーネントは高品質であることが判明しました。 🤱🏽 🛒 🛀🏼

写真1

今日、私は再びTizenプロジェクトに戻ります。私たちのブログの最近の記事「TizenのC＃コンポーネントのコードでエラーを見つける実験」で表面分析を行い、PVS-Studioアナライザーを使用してエラーについてこのプロジェクトのコンポーネントのすべてのC＃コードをチェックし、それについて書くことが理にかなっているという結論に達しました記事。遅滞なく、私はこの作業を行いました。その結果をあなたと共有したいと思います。 C＃コードでは、PVS-Studioアナライザーはそれ自体が不十分であるとすぐに言ったはずです。ただし、まず最初に、アナライザーが何を見つけることができるかを見てみましょう。次に、統計を取り、要約します。

はじめに

私の同僚のAndrei Karpovは最近、CおよびC ++で書かれたTizenプロジェクトコードの分析に関する2つの壮大な記事を公開しました。

TizenプロジェクトにC＃のコードが含まれていることに気付いたとき、この言語で書かれたコンポーネントのチェックに関する同様の記事を作成したかったのです。残念ながら、今回はアナライザーが顕著な成功を実証できませんでしたが、急いで問題を詳細に調査することはできません。

私がチェックしたこと

Tizenソースコードは、リンクからダウンロードできます。リポジトリには、約1,000のプロジェクトが含まれています。各プロジェクトは、ソースコードとサポートファイルを含むアーカイブで構成されています。アーカイブの名前または説明によって、内部の内容を常に理解できるとは限りません。そのため、リポジトリ全体のアーカイブをダウンロード、展開、および調査する必要がありました。

前回の記事で、Tizenプロジェクトに含まれるC＃ソースコードファイルの総数（4,929、* .Designer.csを除く）とその中のコード行（約691,000）を引用しました。ここで、より詳細な分析が必要です。最初に、拡張子が.slnまたは.csprojのファイルを見つけてください。このようなファイルが存在すると、Visual Studio IDEで分析が可能になり、作業が大幅に簡素化されます。

そのため、検索中に、227個のソリューション（* .sln）と166個のC＃プロジェクト（* .csproj）が見つかりました。ソリューションファイルから、C＃プロジェクトを含むものを選択しました。そのような解決策は3つしかありませんでした。

Tizen.Xamarin.Forms.Extension.sln
Xamarin.Forms.Tizen.sln
Xamarin.Forms.sln

最初の2つのソリューションは、Xamarin.Formsのサードパーティコンポーネント上のTizenアドオンであり、3番目にはコンポーネント自体が含まれています。 1年ちょっと前に、Xamarin.Formsのチェックに関する記事を書きました。私の仕事では、これらの結果を考慮して、新しいエラーを見つけようとします。

さらに、これらのソリューションの一部であるプロジェクトファイル（* .csproj）を除外することで、ソリューションに関連付けられていない107個のC＃プロジェクトを受け取りました。それらのほとんどすべては、「csapi- *」という形式の名前を持つ最上位のフォルダーにあります。この11個のテストプロジェクトと、サポートされていないVisual Studio形式の9個のプロジェクトを除き、残りの87個のプロジェクトを受け取りました。それぞれを個別にチェックしました。

この研究の純度のために、Tizenの内部C＃コンポーネント（同じ87プロジェクト）で得られた結果を、Xamarin.Formsに基づいてコンポーネントをチェックした結果から分離することにしました。最初はXamarin.Formsを考慮したくありませんでしたが、熟考した結果、Tizenはこのコンポーネントを独自の目的で使用しているため、Xamarin.FormsエラーがTizenに影響を与える可能性があると結論付けました。

また、以前の記事で既に引用されているエラーについては説明しません。

写真6

検証結果

内部C＃Tizenコンポーネント

Tizenプロジェクトのこの部分の検証中に、PVS-Studioアナライザーは356個の警告を発行しました。そのうち18個-高信頼レベル、157-中信頼レベル、181-低信頼レベルです。約325,000行のコードが分析されました。

誤検知の割合は通常高いため、低信頼レベルの警告は考慮しませんでした。ただし、残念ながら、今回の多くの誤検知は低レベルだけではありません。高レベルおよび中レベルの175の警告のうち、私は12個のエラーのみを検出できました。最も興味深いものを見てみましょう。

PVS-Studio警告： V3008 「_scanData」変数には値が連続して2回割り当てられます。おそらくこれは間違いです。行を確認してください：138、137。Tizen.Network.Bluetooth BluetoothLeAdapter.cs 138
CWE-563。使用しない変数への割り当て（「未使用変数」）

internal BluetoothLeDevice(BluetoothLeScanData scanData) { _scanData = new BluetoothLeScanData (); _scanData = scanData; .... }

_scanDataフィールドには 、値が2回割り当てられます。非常に疑わしいようです。念のため、 BluetoothLeScanDataクラスの宣言とそのコンストラクターを見てください。おそらく、コンストラクター呼び出しにはいくつかの追加のアクションが含まれています。クラスは小さいので、元のコードを少しフォーマットして、全体を提供します。

 internal class BluetoothLeScanData { internal string RemoteAddress { get; set; } internal BluetoothLeDeviceAddressType AddressType { get; set; } internal int Rssi { get; set; } internal int AdvDataLength { get; set; } internal byte[] AdvData { get; set; } internal int ScanDataLength { get; set; } internal byte[] ScanData { get; set; } }

ご覧のとおり、クラスにはオーバーライドされたデフォルトコンストラクタが含まれていないため、明らかに、 _scanDataフィールドへの値の二重割り当てはエラーになります。

PVS-Studio警告： V3009このメソッドが常に1つの同じ値「0」を返すのは奇妙です。 Tizen.Applications.WidgetApplication WidgetType.cs 47
CWE-393。誤ったステータスコードの返却

 private int OnCreate(....) { WidgetBase b = Activator.CreateInstance(ClassType) as WidgetBase; .... if (b == null) return 0; .... return 0; }

メソッドは、作業の結果に関係なく、常に0を返します。たとえば、次のように修正できる間違いがあります。

 private int OnCreate(....) { WidgetBase b = Activator.CreateInstance(ClassType) as WidgetBase; .... if (b == null) return 0; .... return 1; }

PVS-Studioの警告：

V3022式 '！LeftBoundIsForward'は常にfalseです。 clipper_library clipper.cs 838
V3022式 '！LeftBoundIsForward'は常にtrueです。 clipper_library clipper.cs 863

CWE-570 / CWE-571式は常にFalse / Trueです

 private TEdge ProcessBound(TEdge E, bool LeftBoundIsForward) { .... if (LeftBoundIsForward) { .... if (!LeftBoundIsForward) Result = Horz.Prev; .... } else { .... if (!LeftBoundIsForward) Result = Horz.Next; .... } .... }

このコードフラグメントには、同じタイプのエラーチェックがすぐに2つ含まれています。この場合、最初の場合、 Result変数はHorz.Prevの値を取得しません。2番目の場合、同じResult変数は常にHorz.Nextの値を取得します。作成者はこのコードを慎重に検討し、自分でエラーを修正する必要があります。

PVS-Studio 警告： V3022式 'e.OutIdx> = 0'は常にtrueです。 clipper_library clipper.cs 3144
CWE-571式は常に真です

 private void DoMaxima(TEdge e) { .... if(....) { .... } else if( e.OutIdx >= 0 && eMaxPair.OutIdx >= 0 ) { if (e.OutIdx >= 0) AddLocalMaxPoly(e, eMaxPair, e.Top); .... } .... }

検証が誤っている別のコード。演算子「||」が条件e.OutIdx> = 0 && eMaxPair.OutIdx> = 0で使用された場合、ネストされたifブロックでe.OutIdx> = 0をチェックするのが理にかなっています。今では不審に見えます。

PVS-Studio警告： V3110 'InsertBefore'メソッド内で無限再帰が発生する可能性があります。 ElmSharp Toolbar.cs 288
CWE-674非制御再帰

 public ToolbarItem InsertBefore(ToolbarItem before, string label) { return InsertBefore(before, label); }

InsertBeforeメソッドを呼び出すと、無限再帰が生成されます。このエラーは、おそらく間違ったメソッドオーバーロードの呼び出しが原因です。コードにはInsertBeforeという別のメソッドがあります。

 public ToolbarItem InsertBefore(ToolbarItem before, string label, string icon) { .... }

おそらく、これらはすべてこのセクションの興味深いエラーです。疑わしいコードセクションがいくつかありますが、それらについては詳しく説明しません。 C＃で記述されたSamsung Electronicsのコードは、優れた品質を示しています。検証済みのコードがSamsungであることを確信しているのはなぜですか？はい。チェックされた各ファイルには、ヘッダーに「Copyright©2016 Samsung Electronics Co.、Ltd All Rights Reserved」という形式のコメントが含まれているためです。

Xizarin.Forms Tizenコンポーネント

TizenがXamarin.Formsで使用するアドオンには、約242,000行のコードが含まれています。検証中、PVS-Studioアナライザーは163個の警告を発行しました。そのうち10個-高信頼レベル、46-中信頼レベル、107-低信頼レベル（考慮なし）。

約束どおり、Xamarin.Formsのチェックに関する以前の記事で説明されていないエラーを見つけようとします。ちなみに、新しいチェック中にそこにリストされているエラーのいくつかは見つかりませんでした。どうやら、著者が記事を知った後に修正されたようです。

少数の警告が発行されましたが、それらの間にいくつかの新しいエラーを見つけることができました。

PVS-Studio警告： V3095 nullに対して検証される前に「コンテキスト」オブジェクトが使用されました。チェック行：16、18。Xamarin.Forms.Xaml XamlServiceProvider.cs 16
CWE-476 NULLポインター逆参照

 internal XamlServiceProvider(INode node, HydratationContext context) { .... if (node != null && node.Parent != null && context.Values.TryGetValue(node.Parent, // <= out targetObject)) IProvideValueTarget = new XamlValueTargetProvider(....); if (context != null) // <= IRootObjectProvider = new XamlRootObjectProvider(context.RootElement); .... }

コンテキスト変数が最初に使用され、その後にのみnullがチェックされます。

PVS-Studio警告： V3095 nullに対して検証される前に 'type'オブジェクトが使用されました。行を確認：147、149。Xamarin.Forms.Xaml ExpandMarkupsVisitor.cs 147
CWE-476 NULLポインター逆参照

 public INode Parse(....) { .... var xmltype = new XmlType(namespaceuri, type.Name, null); // <= if (type == null) throw new NotSupportedException(); .... }

考えられる例外の別の例は、 NullReferenceExceptionです。型変数は、 XmlTypeクラスのインスタンスを作成するために使用され、その後、 nullの等価性がチェックされます。

他の同様のエラー：

V3095「e.NewElement」オブジェクトは、nullと照合される前に使用されました。行を確認してください：32、46。Xamarin.Forms.Platform.Tizen MasterDetailPageRenderer.cs 32
V3095「e.NewItems」オブジェクトは、nullに対して検証される前に使用されました。行を確認してください：557、567。Xamarin.Forms.Core Element.cs 557
V3095「e.OldItems」オブジェクトは、nullに対して検証される前に使用されました。行を確認してください：561、574。Xamarin.Forms.Core Element.cs 561
V3095「part」オブジェクトは、nullに対して検証される前に使用されました。行を確認してください：135、156。Xamarin.Forms.Core BindingExpression.cs 135

PVS-Studio警告： V3125 「e.NewItems」オブジェクトは、nullに対して検証された後に使用されました。行を確認してください：999、986。Xamarin.Forms.Core TemplatedItemsList.cs 999
CWE-476 NULLポインター逆参照

 void OnProxyCollectionChanged(....) { .... if (e.NewStartingIndex >= 0 && e.NewItems != null) // <= maxindex = Math.Max(maxindex, e.NewStartingIndex + e.NewItems.Count); .... for (int i = e.NewStartingIndex; i < _templatedObjects.Count; i++) SetIndex(_templatedObjects[i], i + e.NewItems.Count); // <= .... }

そして、これは逆の状況です。 e.NewItems変数は、最初に使用する前にnull がチェックされます。ただし、再利用するとき、彼らはこれを行うことを忘れます。

統計

同僚のAndrei Karpovが以前の記事で書いたように、PVS-Studioアナライザーは、Tizenプロジェクトからの1000行のC / C ++コードごとに約0.4のエラーを検出します。 C＃コードで得られるものを計算してみましょう。

合計で、約567,000行のC＃コードがチェックされました。

私の意見では、15個のコードフラグメントのみが見つかったため、エラーが含まれていると言えます。

アナライザーは、コード1000行ごとに0.02エラーを検出することがわかりました。または、言い換えれば、50,000行のコードごとに1つのエラーを検出します。十分ではありません。

写真11

この場合、アナライザーがその有用性を実証できなかったことを認めなければなりません。なぜ起こったのかを言うのは難しいです。他の開いているプロジェクトをチェックするとき、アナライザーはしばしば良い結果を示しました。たとえば、開いているUnity3Dコンポーネントをチェックすると、検出されたエラーの密度はコード1000行あたり0.5エラーでした。すなわちレートは25倍向上しました。

現在テストされているコンポーネントは非常に高品質である可能性があり、おそらくアナライザーはこのプロジェクトに典型的なタイプのエラーを見つけることができません。たぶんその理由は、Tizenの複雑なインフラストラクチャです。多くの場合、必要なすべての環境が含まれていないプロジェクトがチェックされ、多くのリンクが欠落していたため、一部の診断を実行できませんでした。一部のプロジェクトをまったく確認できませんでした。

結論

そのため、テスト結果は、このような大量のコードに対して期待したものではありませんでした。率直に言って、私は少なくとも数百のエラーを見つけると予想していましたが、15件ほどありました。

ただし、PVS-StudioアナライザーがTizenプロジェクトのC＃コードを分析するタスクに対処することが重要です。したがって、C＃言語を使用して記述された新しいコンポーネントがTizenに表示されるようになった場合、現在ではなく、将来的には便利です。潜在的な利点の確認は、アナライザーが他のオープンソースプロジェクトで既に発見した膨大な数のエラーです（記事のリストを参照）。

さらに、繰り返すことにうんざりしていないため、アナライザーを使用した単一チェックのシナリオは最適ではありません。エラーはすでにバージョン管理システムに含まれていますが、これは悪いことです。静的アナライザーを定期的に使用する方がはるかに効率的です。これにより、コードを記述する段階で、バージョン管理システムに入るまでエラーを修正できます。

写真17