Saya melihat publikasi yang dipelajari oleh PVS di Linux, dan memutuskan untuk mencoba proyek-proyeknya. Dan inilah yang terjadi.
Isi
- Pro
- Cons
- Ringkasan
- Kata penutup
Dukungan Responsif
Saya meminta kunci percobaan, mereka mengirimkannya kepada saya pada hari yang sama.
Dokumentasi yang cukup jelas
Dimungkinkan untuk memulai penganalisa tanpa masalah. Bantuan untuk perintah konsol juga tersedia (meskipun ada keluhan, lihat bagian Kontra ).
Kemampuan analisis multi-utas
Alat analisis memiliki opsi "standar" -j , yang memungkinkan menganalisis secara paralel dalam beberapa tugas. Ini menghemat banyak waktu.
Visualisasi yang baik
Banyak format output yang berbeda, dari teks ke moncong web kecil. Wajah web nyaman, ringkas, dengan kiat di sebelah baris dalam kode dan tautan ke deskripsi diagnostik .
Integrasi perakitan yang mudah
Semua dokumentasi ada di situs web mereka, saya hanya bisa mengatakan bahwa jika proyek Anda dibuat menggunakan CMake, maka semuanya sangat sederhana.
Deskripsi diagnostik yang baik
Jika Anda menghasilkan keluaran dalam mode fullhtml , maka setiap pesan memiliki tautan ke deskripsi diagnosis, dengan penjelasan, contoh kode, dan tautan tambahan.
Ketidaktahuan Penganalisa Bahasa C ++
Sayangnya, PVS terkadang salah dalam sintaksis dan menghasilkan pesan positif palsu dengan kode yang benar-benar sempurna.
Misalnya, ada fungsi yang mengembalikan void :
template <typename T> auto copy (const void * source, void * destination) -> std::enable_if_t < std::is_copy_constructible<T>::value > { new (destination) T(*static_cast<const T *>(source)); }
Ya, kata kunci auto dapat berarti void , itu sebabnya otomatis . Tetapi PVS mengeluarkan pesan-pesan ini:
dynamic_tuple_management.hpp:29:1: error: V591 Non-void function should return a value. dynamic_tuple_management.hpp:29:1: error: V2542 Function with a non-void return type should return a value from all exit paths.
Situs sangat lambat
Ya, di moncong web di sebelah setiap pesan ada tautan ke deskripsi diagnosis yang sesuai dengan contoh. Tetapi ketika Anda mengklik tautan, Anda harus menunggu cukup lama, dan kadang-kadang itu terjadi 504 Waktu habis Gateway .
Bahasa
Semua deskripsi dalam bahasa Rusia, itu hebat. Tetapi tautan dari laporan selalu mengarah ke versi bahasa Inggris. Alangkah baiknya untuk dapat beralih bahasa sehingga Anda dapat melihat diagnostik segera dalam bahasa Rusia. Saya tidak menemukan peluang seperti itu di antarmuka.
Nyaman untuk bekerja dengan level diagnostik melalui konsol
Untuk mulai dengan, dua perintah yang digunakan ( pvs-studio-analyzer dan plog-converter ) memiliki format pekerjaan diagnostik yang berbeda.
Bantuan untuk pvs-studio-analyzer berbunyi:
-a [MODE], --analysis-mode [MODE] MODE defines the type of warnings: 1 - 64-bit errors; 2 - reserved; 4 - General Analysis; 8 - Micro-optimizations; 16 - Customers Specific Requests; 32 - MISRA. Modes can be combined by adding the values Default: 4
Untuk waktu yang lama saya mencoba memahami di mana menambahkan ("menambahkan nilai") kunci. Mencoba mendaftar dengan koma:
pvs-studio-analyzer analyze ... -a 1,4,16
Saya mencoba mendaftarkan kunci beberapa kali:
pvs-studio-analyzer analyze ... -a 1 -a 4 -a 16
Dan baru kemudian saya menyadari bahwa ini adalah topeng bit! Dan Anda perlu meringkas , bukan menambahkan nilai. Misalnya, untuk mendapatkan diagnostik umum, diagnostik untuk optimasi mikro dan MISRA, Anda perlu menjumlahkannya (4 + 8 + 32 = 44):
pvs-studio-analyzer analyze ... -a 44
Menggunakan bitmask di antarmuka pengguna biasanya merupakan ide yang buruk. Semua ini dapat diringkas di dalam, dan pengguna menetapkan satu set bendera.
Selain itu, ada juga utilitas plog-converter , yang menghasilkan informasi yang dapat dibaca manusia tentang analisis statis. Dia memiliki masalah lain.
Bantuan untuk laporan program plog-converter :
-a, --analyzer Specifies analyzer(s) and level(s) to be used for filtering, ie 'GA:1,2;64:1;OP:1,2,3;CS:1;MISRA:1,2' Default: GA:1,2
Semacam "level" muncul di sini, yang belum pernah terlihat sebelumnya, dan saya juga tidak menemukan apa pun tentang mereka dalam dokumentasi.
Secara umum, tidak jelas. Karena itu, saya mengatur semuanya secara maksimal.
Sekelompok sumpah bodoh di Catch
Dua dari tiga proyek yang saya analisis menggunakan perpustakaan pengujian unit Catch2 . Dan bagian terbesar dari pesan (!!! 90 dari 138 dalam satu dan 297 dari 344 dalam yang lain !!!) memiliki bentuk berikut:
Tidak mempertimbangkan multithreading
Ada banyak kesalahan positif tentang variabel yang seharusnya tidak berubah atau loop tak terbatas, sementara bekerja dengan variabel-variabel ini berasal dari utas yang berbeda, dan jika tidak demikian, maka unit test tidak akan berfungsi.
Namun, dapatkah penganalisa statis mempertimbangkan ini sama sekali? Saya tidak tahu.
PVS tidak menemukan kesalahan nyata dalam proyek terbuka saya Burst dan Proxima , serta dalam draft kerja, yang saya, karena alasan yang jelas, tidak dapat hadir. Benar, harus diingat bahwa beberapa kekurangan sudah ditangkap dan diperbaiki sebelumnya menggunakan Cppcheck dan scan-build .
Secara umum, kesan semua analisis ini hampir sama: ya, mereka menangkap sesuatu, kadang-kadang bahkan sesuatu yang penting, tetapi secara keseluruhan kompiler sudah cukup.
Adalah mungkin (dan secara pribadi saya senang berpikir demikian) bahwa tim kami menggunakan praktik pengembangan perangkat lunak seperti itu yang memungkinkan kami untuk menghasilkan jumlah kotoran minimum. Lebih baik tidak menciptakan masalah daripada mengatasinya dengan heroik.
Oleh karena itu, saya mengambil kebebasan memberikan beberapa saran tentang cara menulis dalam C ++ sedemikian rupa agar tidak menembak kaki siapa pun dan tidak menyapu dahi.
Gunakan diagnostik kompiler secara maksimal
Tim kami menggunakan (dan memberi tahu Anda) opsi kompilasi berikut:
-Werror -Wall -Wextra -Wpedantic -Wcast-align -Wcast-qual -Wconversion -Wctor-dtor-privacy -Wenum-compare -Wfloat-equal -Wnon-virtual-dtor -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wsign-conversion -Wsign-promo
Masukkan mereka dalam proyek Anda, pelajari banyak tentang kode Anda.
Tetap pada standar
Cobalah untuk tidak menggunakan hal-hal yang bergantung pada platform jika ada analog standar, dan jika Anda tidak dapat melakukannya tanpa semuanya, bungkus dalam blok khusus untuk pemotretan makro (atau yang lain) dan jangan biarkan kami mengkompilasi kode Anda dalam kondisi yang tidak didukung.
Tetap menggunakan semantik operasi standar
Penambahan harus berupa penambahan, perkalian demi perkalian, pemanggilan fungsi dengan pemanggilan fungsi, salin harus menyalin, transfer harus ditransfer, wadah harus dapat diubah, iterator harus memiliki ++ promosi dan dereferensi * . Dan seterusnya dan seterusnya.
Saya pikir idenya jelas. Ada perjanjian yang dibuat yang tidak mengikat tetapi semua pengguna dan pembaca kode Anda berharap untuk melihatnya. Jangan mencoba mengakali orang lain, atau mengakali diri sendiri.
Tulis kode yang kompatibel
Pertama-tama, maksud saya perpustakaan standar. Sangat diinginkan bahwa antarmuka kelas dan fungsi Anda dapat digunakan dengan perpustakaan standar dan lainnya (misalnya, Bust).
Silakan mengintip antarmuka STL dan Boost. Dengan pengecualian langka, Anda akan melihat panutan yang layak di sana.
Manfaatkan alat terbuka sebaik mungkin
Untuk analisis statis yang sama, setidaknya ada dua alat gratis terbuka yang terhubung ke proyek apa pun dengan sistem bangun CMake dengan mengorbankan "waktu".
Anda dapat membaca lebih lanjut tentang ini di publikasi terbaru saya .
Sebagai kesimpulan, saya menekankan bahwa saya tidak mendesak untuk tidak menggunakan PVS atau analisa statis lainnya. Tetapi saya mendesak Anda untuk memikirkan bagaimana ternyata penganalisa statis terus-menerus menemukan kesalahan signifikan dalam kode Anda.
Ini hanya konsekuensi. Perlu untuk mencari dan menghilangkan penyebabnya.