Videl som publikáciu, ktorú sa PVS naučil analyzovať pod Linuxom, a rozhodol som sa ju vyskúšať na svojich vlastných projektoch. A toto je to, čo z toho vyšlo.
Bohužiaľ, PVS niekedy robí chyby v syntaxi a generuje falošne pozitívne správy, keď je kód úplne správny.
Existuje napríklad funkcia, ktorá vracia 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));
}
Áno je kľúčové slovo auto Môže znamenať void, na to to je auto. PVS však vytvorila nasledujúce správy:
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.
Veľmi pomalá stránka
Áno, vo webovom rozhraní je vedľa každej správy odkaz na príslušný diagnostický popis s príkladmi. Ale keď kliknete na odkaz, musíte čakať pomerne dlho a niekedy sa to stane 504 Časový limit brány.
Jazyk
Všetky popisy sú v ruštine, čo je skvelé. Odkazy zo správy však vždy vedú na anglickú verziu. Bolo by pekné mať možnosť prepnúť jazyk, aby ste si diagnostiku mohli okamžite pozrieť v ruštine. V rozhraní som takúto možnosť nenašiel.
Je nepohodlné pracovať s diagnostickými úrovňami cez konzolu
Začnime tým, že dva použité príkazy (toto pvs-studio-analyzer и plog-converter) rôzne formáty pre špecifikáciu diagnostiky.
Pomoc pre pvs-studio-analyzer znie:
-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
Dlho som sa snažil zistiť, kam ísť pridať (“pridanie hodnôt”). Pokúsil som sa ich uviesť oddelené čiarkami:
pvs-studio-analyzer analyze ... -a 1,4,16
Pokúsil som sa niekoľkokrát zaregistrovať kľúč:
pvs-studio-analyzer analyze ... -a 1 -a 4 -a 16
A až potom som si uvedomil, že to boli trochu masky! A potrebujete zhrnúťA nie pridať významy. Napríklad, ak chcete získať všeobecnú diagnostiku, diagnostiku pre mikrooptimalizácie a MISRA, musíte ich zhrnúť (4 + 8 + 32 = 44):
pvs-studio-analyzer analyze ... -a 44
Používanie bitových masiek v používateľských rozhraniach je vo všeobecnosti zlou formou. Toto všetko by sa dalo interne zhrnúť a pre používateľa by sa dala nastaviť sada príznakov.
Okrem toho existuje aj užitočnosť plog-converter, ktorý generuje informácie o statickej analýze čitateľné pre človeka. Má iné problémy.
Pomoc k programu plog-converter správy:
-a, --analyzer Specifies analyzer(s) and level(s) to be
used for filtering, i.e.
'GA:1,2;64:1;OP:1,2,3;CS:1;MISRA:1,2'
Default: GA:1,2
Objavili sa tu niektoré „úrovne“, ktoré tam predtým neboli, a ani som o nich v dokumentácii nič nenašiel.
Vo všeobecnosti to nie je jasné. Preto som všetko nastavil na maximum.
Kopa hlúpych nadávok na Catcha
Dva z troch projektov, ktoré som analyzoval, používajú knižnicu na testovanie jednotiek Catch2. A leví podiel správ (!!! 90 zo 138 v jednej a 297 z 344 v druhej!!!) má tento tvar:
Neberie do úvahy multithreading
Existuje veľa falošných pozitív o údajne nemenných premenných alebo nekonečných slučkách, pričom práca s týmito premennými prebieha z rôznych vlákien, a ak by to tak nebolo, testy jednotiek by nefungovali.
Môže to však statický analyzátor vôbec zohľadniť? neviem.
PVS nenašiel žiadne skutočné chyby v mojich open source projektoch Výbuch и Ďalšie, ako aj v pracovnom návrhu, ktorý z pochopiteľných dôvodov nemôžem predložiť. Je pravda, že stojí za to mať na pamäti, že niektoré nedostatky už boli zachytené a opravené skôr Cppcheck и scan-build.
Vo všeobecnosti je dojem zo všetkých týchto analyzátorov približne rovnaký: áno, niečo zachytia, niekedy aj niečo dôležité, ale celkovo stačí kompilátor.
Je možné (a ja si to osobne rád myslím), že náš tím používa postupy vývoja softvéru, ktoré nám umožňujú generovať minimálne množstvo posratého kódu. Je lepšie problémy nevytvárať, ako ich hrdinsky prekonávať.
Preto si dovoľujem dať pár rád, ako písať v C++ tak, aby som nikomu neodstrelil nohy alebo nikoho neudrel hrabľami do čela.
Využite diagnostiku kompilátora na maximum
Náš tím používa (a odporúča vám to) nasledujúce možnosti kompilácie:
Povoľte ich vo svojom projekte a naučte sa veľa o svojom kóde.
Držte sa štandardu
Pokúste sa nepoužívať veci závislé od platformy, ak existujú štandardné analógy, a ak sa bez nich absolútne nemôžete zaobísť, zabaľte ich do špeciálnych blokov pre makrá (alebo niečo iné) a jednoducho nenechajte svoj kód skompilovať za nepodporovaných podmienok.
Držte sa štandardnej sémantiky operácií
Sčítanie musí byť sčítanie, násobenie musí byť násobenie, volanie funkcie musí byť volanie funkcie, kópia musí byť kópia, prenášanie musí byť prenášané, kontajner musí byť opakovateľný, iterátor musí mať propagáciu ++ a dereferencovanie *. A tak ďalej a tak ďalej.
Myslím, že myšlienka je jasná. Existujú zavedené konvencie, ktoré nie sú záväzné, ale očakávajú, že ich uvidia všetci používatelia a čitatelia vášho kódu. Nesnažte sa prekabátiť ostatných, inak preľstíte aj seba.
Napíšte kompatibilný kód
V prvom rade mám na mysli štandardnú knižnicu. Je veľmi žiaduce, aby sa rozhrania vašich tried a funkcií dali použiť so štandardnými a inými knižnicami (napríklad Boost).
Neváhajte sa pozrieť na rozhrania STL a Boost. Až na vzácne výnimky tam uvidíte dôstojný vzor.
Využite čo najlepšie nástroje s otvoreným zdrojom
Pre rovnakú statickú analýzu existujú aspoň dva otvorené bezplatné nástroje, ktoré možno len raz pripojiť k akémukoľvek projektu so systémom zostavovania CMake.
Na záver by som rád zdôraznil, že neobhajujem nepoužívanie PVS ani iných statických analyzátorov. Odporúčam vám však premýšľať o tom, ako sa stalo, že statický analyzátor neustále nachádza významné chyby vo vašom kóde.
Toto je len dôsledok. Musíme hľadať a odstraňovať príčinu.