Ik seach in publikaasje dy't PVS hie leard te analysearjen ûnder Linux, en besleat it te besykjen op myn eigen projekten. En dit is wat der út kaam.
Ynhâld
Responsive stipe
Ik frege in proefkaai en se stjoerde it deselde dei nei my.
Redelijk dúdlike dokumintaasje
It slagge ús om de analysator sûnder problemen te starten. Help foar konsole-kommando's is ek beskikber (hoewol't d'r hjir wat klachten binne, sjoch seksje ).
Mooglikheid fan multi-threaded analyze
De analyzer hat in "standert" opsje -j, wêrtroch analyse parallel yn ferskate taken wurde kin wurde útfierd. Dit besparret in soad tiid.
Goede fisualisaasje
In protte ferskillende útfierformaten, fan tekst oant in lyts webmuzel. .
Maklike yntegraasje yn 'e gearkomste
Alle dokumintaasje is op har webside, ik kin allinich sizze dat as jo projekt is boud mei CMake, dan is alles heul ienfâldich.
Goede diagnostyske beskriuwingen
As jo generearje útfier yn modus fullhtml, dan hat elk berjocht in keppeling nei in diagnostyske beskriuwing, mei taljochtingen, koadefoarbylden en ekstra keppelings.
Ûnwittendheid fan de C ++ taal troch de analysator
Spitigernôch makket PVS soms syntaksisflaters en generearret falske positive berjochten as de koade folslein korrekt is.
Der is bygelyks in funksje dy't weromkomt 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));
}Ja is it kaaiwurd auto Kin betsjutte void, dêr is it foar auto. Mar PVS produsearre de folgjende berjochten:
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.Hiel trage side
Ja, yn 'e webynterface neist elk berjocht is d'r in keppeling nei de byhearrende diagnostyske beskriuwing mei foarbylden. Mar as jo op in keppeling klikke, moatte jo nochal lang wachtsje, en soms bart it .
Taal
Alle beskriuwingen binne yn it Russysk, dat is geweldich. Mar keppelings út it rapport liede altyd nei de Ingelske ferzje. It soe moai wêze om de taal te wikseljen sadat jo diagnoaze daliks yn it Russysk besjen kinne. Ik fûn sa'n opsje net yn 'e ynterface.
It is ûngemaklik om te wurkjen mei diagnostyske nivo's fia de konsole
Litte wy begjinne mei it feit dat de twa brûkte kommando's (dit pvs-studio-analyzer и plog-converter) ferskate formaten foar it opjaan fan diagnostyk.
Help foar pvs-studio-analyzer lêst:
-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: 4Ik besocht in lange tiid út te finen wêr't ik hinne moast add ("de wearden tafoegje") toetsen. Ik besocht se skieden troch komma's te listjen:
pvs-studio-analyzer analyze ... -a 1,4,16Ik besocht de kaai ferskate kearen te registrearjen:
pvs-studio-analyzer analyze ... -a 1 -a 4 -a 16En pas doe besefte ik dat dit bitmaskers wiene! En jo moatte opsomje, en net add betsjuttings. Bygelyks, om algemiene diagnoaze, diagnoaze foar mikro-optimisaasjes en MISRA te krijen, moatte jo se gearfetsje (4 + 8 + 32 = 44):
pvs-studio-analyzer analyze ... -a 44It brûken fan bitmasks yn brûkersynterfaces is oer it algemien minne foarm. Dit alles koe wurde gearfette yntern, en in set fan flaggen koe wurde ynsteld foar de brûker.
Derneist is d'r ek in nutsfoarsjenning plog-converter, dy't minsklik lêsbere statyske analyseynformaasje genereart. Se hat oare problemen.
Help foar it programma plog-converter ferslaggen:
-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,2Guon "nivo's" ferskynden hjir dy't der net earder wiene, en ik fûn der ek neat oer yn 'e dokumintaasje.
Yn it algemien is it net dúdlik. Dêrom set ik alles op it maksimum.
In bulte domme swarren op Catch
Twa fan 'e trije projekten dy't ik analysearre brûke in ienheidstestbibleteek . En it liuw syn oandiel berjochten (!!! 90 fan 138 yn ien en 297 fan 344 yn de oare!!!) hawwe de folgjende foarm:
Nimt gjin rekken mei multithreading
D'r binne in protte falske positiven oer sabeare ûnferoarjende fariabelen of einleaze loops, wylst wurk mei dizze fariabelen komt fan ferskate triedden, en as dit net sa wie, dan soe ienheidtests net wurkje.
Kin in statyske analysator dit lykwols sels rekken hâlde? Wit net.
PVS fûn gjin echte bugs yn myn iepen boarne-projekten и , likegoed as yn in wurkûntwerp, dat ik om foar de hân lizzende redenen net presintearje kin. Wier, it is de muoite wurdich om te hâlden yn gedachten dat guon tekoartkommingen binne al fongen en korrizjearre earder mei help и .
Yn 't algemien is de yndruk fan al dizze analysators sawat itselde: ja, se fange wat, soms sels wat wichtichs, mar oer it algemien is de kompilator genôch.
It is mooglik (en ik tink it persoanlik graach) dat ús team software-ûntwikkelingspraktiken brûkt dy't ús in minimum oantal shitty-koade kinne generearje. It is better gjin problemen te meitsjen as se heroysk te oerwinnen.
Dêrom nim ik de frijheid om wat advys te jaan oer hoe't jo yn C++ skriuwe kinne op sa'n manier dat ik gjinien syn skonken ôfsjitte of immen mei in hark yn 'e foarholle slaan.
Meitsje it measte út kompilerdiagnostyk
Us team brûkt (en advisearret jo) de folgjende kompilaasjeopsjes:
-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-promoAktivearje se yn jo projekt en lear in protte oer jo koade.
Hâld de standert
Besykje net platfoarm-ôfhinklike dingen te brûken as d'r standert analogen binne, en as jo perfoarst net sûnder har kinne, wrap se dan yn spesjale blokken foar makro's (as wat oars) en lit jo koade gewoan net kompilearje ûnder net-stipe betingsten.
Hâld oan standert operaasje semantyk
Tafoeging moat tafoeging wêze, fermannichfâldigje moat fermannichfâldigje, funksjeoprop moat funksjeoprop wêze, kopy moat kopiearje, drage moat drage, kontener moat iterabel wêze, iterator moat promoasje hawwe ++ en ôfwiking *. En sa fierder.
Ik tink dat it idee dúdlik is. D'r binne fêststelde konvinsjes dy't net binend binne, mar dat alle brûkers en lêzers fan jo koade ferwachtsje te sjen. Besykje net oaren te oertsjûgjen, oars silst dysels oerlêst.
Skriuw kompatibele koade
As earste bedoel ik de standertbibleteek. It is tige winsklik dat de ynterfaces fan jo klassen en funksjes kinne wurde brûkt mei standert en oare bibleteken (bygelyks Boost).
Fiel jo frij om de STL- en Boost-ynterfaces te besjen. Mei seldsume útsûnderingen sille jo dêr in weardich rolmodel sjen.
Meitsje it measte út iepen boarne ark
Foar deselde statyske analyse binne d'r teminsten twa iepen fergese ark dy't mar ien kear kinne wurde ferbûn oan elk projekt mei it CMake-bousysteem.
.
Uteinlik wol ik beklamje dat ik net pleite om PVS of oare statyske analysatoren net te brûken. Mar ik moedigje jo oan om nei te tinken oer hoe't it barde dat de statyske analysator konstant wichtige flaters fynt yn jo koade.
Dit is gewoan in gefolch. Wy moatte de oarsaak sykje en eliminearje.
Boarne: www.habr.com