Sesekali, programmer yang mulai berkenalan dengan alat analisa kode PVS-Studio bertanya kepada saya: "Apakah ada daftar peringatan yang secara akurat menunjukkan kesalahan?" Tidak ada daftar seperti itu karena peringatan (salah) yang tidak menarik dalam satu proyek sangat penting dan bermanfaat di proyek lainnya. Namun, orang pasti dapat mulai menggali ke dalam analisa dari peringatan yang paling menarik. Mari kita lihat lebih dekat topik ini.
Masalahnya, sebagai aturan, pada awalnya menjalankan seorang programmer tenggelam dalam sejumlah besar peringatan yang ia dapatkan. Secara alami, dia ingin mulai meninjau peringatan yang paling menarik untuk memahami apakah dia harus menghabiskan waktu untuk menyelesaikan semua ini. Bagus, jadi di sini ada tiga langkah sederhana yang akan membuatnya memeriksa peringatan paling menarik.
Langkah 1
Nonaktifkan semua jenis peringatan kecuali yang umum (GA). Kesalahan umum adalah mengaktifkan semua jenis peringatan. Pengguna yang tidak berpengalaman berpikir bahwa semakin memungkinkan untuk diaktifkan, semakin baik. Bukan itu masalahnya. Ada set diagnostik, seperti pemeriksaan 64-bit dan aturan MISRA, yang seharusnya hanya digunakan ketika seseorang dengan jelas tahu apa yang mereka dan bagaimana bekerja dengannya. Misalnya, dengan mengaktifkan diagnostik MISRA untuk program aplikasi biasa, Anda akan menenggelamkan puluhan, ribuan, atau ratusan ribu peringatan seperti:
- V2506 . Misra. Suatu fungsi harus memiliki satu titik keluar di akhir.
- V2507 . Misra. Isi pernyataan loop \ conditional harus dilampirkan dalam kurung kurawal.
- V2523 . Misra. Semua konstanta integer dari tipe unsigned harus memiliki akhiran 'u' atau 'U'.
Sebagian besar peringatan MISRA menunjukkan bukan kesalahan, tetapi kode berbau. Secara alami, seorang programmer mulai mengajukan pertanyaan. Bagaimana Anda menemukan sesuatu yang menarik di tumpukan semua peringatan ini? Nomor apa yang harus dia tonton? Ini adalah pertanyaan yang salah. Anda hanya perlu menonaktifkan set MISRA. Ini adalah standar untuk menulis kode kualitas untuk perangkat yang disematkan. Inti dari standar ini adalah membuat kode ini sangat sederhana dan mudah dipahami. Jangan mencoba menerapkannya di tempat yang tidak pantas.
Catatan Ya, MISRA memiliki aturan yang dirancang untuk mengidentifikasi bug nyata. Contoh:
V2538 - Nilai variabel tidak diinisialisasi tidak boleh digunakan. Tetapi jangan takut untuk menonaktifkan standar MISRA. Anda tidak akan kehilangan apapun. Kesalahan nyata masih akan ditemukan sebagai bagian dari General Diagnostics (GA). Misalnya, variabel tidak diinisialisasi akan ditemukan oleh diagnostik
V614 .
Langkah 2
Setiap penganalisa statis mengeluarkan false positive pada putaran pertama dan membutuhkan beberapa konfigurasi. Tidak ada yang bisa dilakukan tentang hal itu, tetapi tidak seseram kelihatannya. Bahkan pengaturan cepat sederhana memungkinkan Anda untuk menghapus sebagian besar kesalahan positif dan mulai melihat laporan yang cukup relevan. Saya tidak akan membicarakannya lagi, seperti yang telah saya tulis berkali-kali, misalnya, dalam artikel ini: "
Karakteristik PVS-Studio Analyzer dengan Contoh EFL Core Libraries, 10-15% False Positive ".
Luangkan sedikit waktu untuk menonaktifkan peringatan yang jelas tidak relevan dan berperang melawan positif palsu yang terkait dengan makro. Secara umum, makro adalah alasan utama false positive, karena peringatan muncul dalam semua kasus ketika makro yang diimplementasikan dengan buruk digunakan. Untuk menekan peringatan di makro, Anda dapat menulis komentar dari tipe khusus di sebelah deklarasi mereka. Semakin banyak format komentar tercakup dalam
dokumentasi .
Ya, pengaturan awal akan membutuhkan sedikit waktu, tetapi secara drastis akan meningkatkan persepsi laporan dengan menghilangkan kebisingan yang mengganggu. Luangkan waktu untuk melakukannya. Jika ada kesulitan atau pertanyaan, kami selalu siap membantu dan memberi tahu Anda cara mengatur analisa dengan cara terbaik. Jangan ragu untuk
menulis dan mengajukan pertanyaan kepada kami.
Langkah 3
Mulai melihat peringatan dari Level 1. Hanya setelah itu menonton 2 dan 3. Level peringatan tidak lebih dari kebenaran suatu peringatan. Peringatan Level 1 lebih cenderung mengindikasikan kesalahan aktual daripada peringatan Level 2.
Anda dapat mengatakan, ketika Anda memilih untuk "menonton Level 1," Anda menekan tombol "menonton kesalahan paling menarik".
Secara lebih rinci, klasifikasi peringatan PVS-Studio berdasarkan level dijelaskan dalam artikel "
Cara analis statis melawan positif palsu, dan mengapa mereka melakukannya ".
Jadi mengapa tidak ada daftar?
Namun, gagasan memiliki daftar peringatan paling berguna mungkin masih masuk akal. Izinkan saya menunjukkan kepada Anda dalam contoh praktis bahwa kegunaan diagnostik relatif dan tergantung pada proyek.
Mari kita perhatikan peringatan
V550 . Peringatan mendeteksi kesalahan potensial yang terkait dengan fakta bahwa untuk membandingkan angka dengan floating-point operator == atau! = Digunakan.
Sebagian besar pengembang yang saya ajak bicara, berpikir bahwa diagnostik ini tidak berguna dan mereka menonaktifkannya karena semua pemicunya untuk proyek mereka salah. Karena itulah diagnostik ini memiliki tingkat kepastian yang rendah dan terkait dengan Tingkat 3.
Memang, di sebagian besar aplikasi, tipe float / double digunakan dalam algoritma yang sangat sederhana. Seringkali perbandingan dengan konstanta digunakan semata-mata untuk memeriksa apakah nilai tertentu diatur secara default, atau apakah telah berubah. Dalam hal ini, pemeriksaan yang tepat cukup tepat. Saya akan menjelaskannya dengan pseudo-code.
float value = 1.0f; if (IsUserInputNewValue()) value = GetUserValue(); if (value == 1.0f) DefaultBehavior(); else Foo(value);
Di sini perbandingan
(nilai 1.0f) benar dan aman.
Apakah ini berarti diagnostik V550 tidak menarik? Tidak. Itu semua tergantung pada proyek. Izinkan saya mengutip cuplikan dari artikel "
Bagaimana Kami Mencoba Analisis Statis pada Proyek Simulator Pelatihan Bedah Endovaskular X-Ray Kami ", yang ditulis oleh pengguna kami.
Jadi, apa analisa statis kami memperhatikan di sini:
V550 Perbandingan presisi yang aneh: t! = 0. Mungkin lebih baik menggunakan perbandingan dengan presisi yang ditentukan: fabs (A - B)> Epsilon. objectextractpart.cpp 3401
D3DXVECTOR3 N = VectorMultiplication( VectorMultiplication(V-VP, VN), VN); float t = Qsqrt(Scalar(N, N)); if (t!=0) { N/=t; V = V - N * DistPointToSurface(V, VP, N); }
Kesalahan seperti itu cukup sering berulang di perpustakaan ini. Saya tidak bisa mengatakan itu mengejutkan saya. Sebelumnya, saya telah menemukan penanganan angka yang salah dengan titik mengambang di proyek ini. Namun, tidak ada sumber daya untuk memverifikasi sumber secara sistematis. Sebagai hasil dari pemeriksaan, menjadi jelas bahwa pengembang perlu memberikan sesuatu untuk memperluas wawasannya dalam hal bekerja dengan angka floating point. Dia telah dikaitkan dengan beberapa artikel bagus. Kita akan lihat bagaimana hasilnya nanti. Sulit untuk mengatakan dengan pasti apakah kesalahan ini menyebabkan gangguan nyata dalam program. Solusi saat ini memperlihatkan sejumlah persyaratan untuk mesh poligonal asli dari arteri, yang mensimulasikan penyebaran materi kontras sinar-X. Jika persyaratan tidak terpenuhi, program mungkin jatuh, atau pekerjaan itu jelas salah. Beberapa persyaratan ini diperoleh secara analitis, dan beberapa - secara empiris. Ada kemungkinan bahwa kelompok persyaratan empiris ini bertambah hanya karena penanganan angka yang salah dengan titik mengambang. Perlu dicatat bahwa tidak semua kasus yang ditemukan menggunakan perbandingan angka yang tepat dengan floating point adalah kesalahan.
Seperti yang Anda lihat, apa yang tidak menarik dalam beberapa proyek menarik bagi yang lain. Ini membuat tidak mungkin membuat daftar yang "paling menarik".
Catatan Anda juga dapat mengatur tingkat peringatan menggunakan pengaturan. Misalnya, jika Anda berpikir bahwa diagnostik V550 layak mendapat perhatian, Anda dapat memindahkannya dari Level 3 ke 1. Jenis pengaturan ini dijelaskan dalam
dokumentasi (lihat "Cara Mengatur Level Anda untuk Diagnostik Khusus").
Kesimpulan
Sekarang Anda tahu cara mulai mempelajari peringatan penganalisa dengan melihat yang paling menarik. Dan jangan lupa untuk melihat dokumentasi untuk mendapatkan deskripsi rinci tentang peringatan. Kadang-kadang terjadi bahwa di balik naskah yang tidak mencolok, pada pandangan pertama, peringatan adalah neraka. Contoh diagnostik tersebut:
V597 ,
V1026 . Terima kasih atas perhatian anda