Dari waktu ke waktu, programmer yang mulai berkenalan dengan penganalisa kode PVS-Studio bertanya: "Apakah ada daftar peringatan yang secara akurat menunjukkan kesalahan?" Tidak ada daftar dengan alasan bahwa peringatan yang tidak menarik (salah) dalam satu proyek dan yang lain ternyata sangat penting dan berguna. Namun, untuk memulai berkenalan dengan analis dengan peringatan paling menarik adalah sangat mungkin. Mari kita lihat lebih dekat topik ini.
Masalahnya adalah bahwa selama peluncuran pertama, programmer, sebagai suatu peraturan, menerima sejumlah besar peringatan di mana ia "tenggelam". Secara alami, ia mulai ingin berkenalan dengan peringatan yang paling menarik untuk memahami apakah ia harus menghabiskan waktu selama ini. Hebat, berikut adalah tiga langkah sederhana yang akan memungkinkan Anda untuk berkenalan dengan hal-hal positif yang paling menarik.
Langkah 1
Nonaktifkan semua jenis peringatan kecuali umum (GA). Kesalahan umum: aktifkan semua jenis peringatan. Untuk pengguna yang tidak berpengalaman tampaknya semakin Anda menyalakannya, semakin baik. Ini tidak benar! Ada serangkaian diagnostik, seperti pemeriksaan 64-bit dan aturan MISRA, yang harus digunakan hanya dengan gagasan yang jelas tentang apa itu dan bagaimana cara mengatasinya. Misalnya, dengan mengaktifkan diagnostik MISRA untuk program aplikasi biasa, Anda akan menenggelamkan puluhan, ribuan, atau ratusan ribu pesan 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 tidak menunjukkan kesalahan, tetapi kode berbau. Secara alami, seseorang mulai mengajukan pertanyaan. Bagaimana menemukan sesuatu yang menarik dalam massa semua peringatan ini? Diagnostik di bawah nomor berapa dia harus mencari? Ini adalah pertanyaan yang salah. Anda hanya perlu menonaktifkan kit MISRA. Ini adalah standar untuk menulis kode kualitas untuk perangkat yang disematkan. Inti dari standar: untuk membuat kode sangat sederhana dan mudah dimengerti. Jangan mencoba menerapkannya di tempat yang tidak pantas.
Catatan Ya, ada aturan dalam standar MISRA yang bertujuan mengidentifikasi kesalahan nyata. Contoh:
V2538 - Nilai variabel tidak diinisialisasi tidak boleh digunakan. Tetapi jangan takut untuk menonaktifkan standar MISRA. Anda tidak akan kehilangan apapun. Kesalahan sejati masih akan ditemukan dalam diagnostik tujuan umum (GA). Misalnya, variabel yang tidak diinisialisasi akan ditemukan berkat diagnostik
V614 .
Langkah 2
Analyzer statis apa pun menghasilkan positif palsu selama permulaan pertama dan membutuhkan konfigurasi tertentu. Tidak ada yang bisa dilakukan dengan ini, tetapi tidak seseram kelihatannya. Bahkan pengaturan cepat sederhana memungkinkan Anda untuk menghapus sebagian besar peringatan palsu dan mulai berkenalan dengan laporan yang sudah cukup memadai. Kami tidak akan membicarakan hal ini lebih terinci, karena saya menulisnya berulang kali, misalnya, dalam artikel ini: "
Karakteristik penganalisis PVS-Studio menggunakan contoh EFL Core Libraries, 10-15% positif palsu ."
Luangkan sedikit waktu untuk menonaktifkan peringatan yang tidak relevan secara eksplisit dan melawan positif palsu karena makro. Makro umumnya merupakan sumber utama false positive, karena peringatan muncul di mana pun makro gagal digunakan. Untuk menekan peringatan di makro, jenis komentar khusus dapat ditempatkan di sebelah deklarasi mereka. Format untuk menulis komentar dibahas lebih rinci dalam
dokumentasi .
Ya, pengaturan awal akan memakan waktu sedikit, tetapi secara dramatis meningkatkan persepsi laporan dengan menghilangkan kebisingan yang mengganggu. Luangkan waktu untuk ini. Jika ada kesulitan atau pertanyaan, kami selalu siap membantu dan menyarankan cara terbaik untuk mengonfigurasi penganalisis. Jangan ragu untuk
menulis dan mengajukan pertanyaan kepada kami.
Langkah 3
Mulai pelajari peringatan dari level 1. Dan hanya kemudian melihat 2 dan 3. Tingkat peringatan tidak lebih dari keandalan peringatan. Peringatan Level 1 lebih cenderung mengindikasikan kesalahan sebenarnya daripada 2.
Kita dapat mengatakan bahwa memilih "menonton level 1", Anda menekan tombol "menonton kesalahan paling menarik".
Klasifikasi peringatan PVS-Studio berdasarkan level dijelaskan lebih rinci dalam artikel “
Bagaimana dan mengapa analisa statis berurusan dengan false positive ”.
Jadi mengapa masih belum ada daftar?
Namun, ide dengan daftar peringatan yang paling berguna mungkin tampak masuk akal. Izinkan saya menunjukkan dengan contoh praktis bahwa kegunaan diagnostik relatif dan tergantung pada proyek.
Pertimbangkan peringatan
V550 . Peringatan mengungkapkan potensi kesalahan karena fakta bahwa operator == atau! = Digunakan untuk membandingkan angka floating-point.
Sebagian besar pengembang yang saya ajak bicara percaya bahwa diagnosis ini tidak banyak berguna dan mematikannya, karena semua positif untuk proyek mereka salah. Dan itulah mengapa diagnosis ini memiliki keandalan yang rendah dan terletak di tingkat ke-3.
Memang, di sebagian besar aplikasi, tipe float / double digunakan dalam algoritma yang sangat sederhana. Dan seringkali perbandingan dengan konstanta digunakan hanya untuk memeriksa apakah nilai default disetel, atau apakah telah berubah. Dalam hal ini, pemeriksaan yang akurat cukup tepat. Saya akan menjelaskan ini dengan pseudo-code.
float value = 1.0f; if (IsUserInputNewValue()) value = GetUserValue(); if (value == 1.0f) DefaultBehavior(); else Foo(value);
Di sini perbandingan
(nilai ==1f) benar dan aman.
Apakah ini berarti bahwa V550 adalah diagnosis yang tidak menarik? Tidak. Itu semua tergantung pada proyek. Saya akan mengutip sebagian dari artikel "
Bagaimana kami menguji analisis statis pada proyek kami dari simulator pelatihan operasi endovaskular, " yang ditulis oleh salah satu pengguna kami.
Jadi, apa yang dianalisis oleh penganalisa statis adalah:
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 serupa berulang cukup sering di perpustakaan ini. Saya tidak akan mengatakan bahwa ini mengejutkan saya. Sebelumnya saya menemukan pekerjaan yang salah dengan angka floating-point dalam proyek ini. Namun, tidak ada sumber daya untuk secara sistematis memeriksa sumber untuk ini. Menurut hasil verifikasi, menjadi jelas bahwa Anda perlu memberikan pengembang sesuatu untuk dibaca untuk memperluas wawasannya dalam hal bekerja dengan angka floating-point. Saya melemparkan dia tautan ke beberapa artikel bagus. Mari kita lihat hasilnya. Sulit untuk mengatakan dengan jelas apakah kesalahan ini menyebabkan kegagalan fungsi nyata dalam program. Solusi saat ini menetapkan sejumlah persyaratan untuk jaringan arteri poligonal awal, di mana penyebaran zat radiopak disimulasikan. Jika persyaratan tidak terpenuhi, maka program mungkin macet, atau operasi yang jelas salah. Beberapa persyaratan ini diperoleh secara analitis, dan sebagian lagi secara empiris. Ada kemungkinan bahwa bagian kedua dari persyaratan ini tumbuh hanya dari pekerjaan yang salah dengan angka floating-point. Perlu dicatat bahwa tidak semua kasus yang ditemukan menggunakan perbandingan angka floating-point yang tepat adalah kesalahan.
Seperti yang Anda lihat, apa yang tidak menarik dalam beberapa proyek menarik bagi yang lain. Ini membuatnya mustahil untuk membuat daftar "paling menarik."
Catatan Dimungkinkan untuk mengatur tingkat peringatan menggunakan pengaturan. Misalnya, jika Anda berpikir bahwa diagnostik V550 layak mendapat perhatian, Anda dapat memindahkannya dari tingkat ketiga ke yang pertama. Jenis pengaturan ini dijelaskan dalam
dokumentasi (lihat "Cara mengatur level Anda untuk diagnostik tertentu").
Kesimpulan
Sekarang Anda tahu cara mulai mempelajari peringatan penganalisa, mengingat yang paling menarik dari itu. Dan jangan lupa melihat di dokumentasi untuk berkenalan dengan deskripsi rinci tentang peringatan. Kadang-kadang terjadi bahwa di balik pandangan yang tidak memiliki, pada pandangan pertama, adalah neraka. Contoh diagnostik tersebut:
V597 ,
V1026 . Terima kasih atas perhatian anda
Jika Anda ingin berbagi artikel ini dengan audiens yang berbahasa Inggris, silakan gunakan tautan ke terjemahan: Andrey Karpov.
Bagaimana cara cepat memeriksa peringatan menarik yang diberikan oleh alat analisa PVS-Studio untuk kode C dan C ++?