టీమ్‌ను డీమోటివేట్ చేయకుండా లెగసీ ప్రాజెక్ట్‌లో స్టాటిక్ కోడ్ ఎనలైజర్‌ని ఎలా అమలు చేయాలి

స్టాటిక్ కోడ్ ఎనలైజర్‌ని ప్రయత్నించడం చాలా సులభం. కానీ దానిని అమలు చేయడానికి, ముఖ్యంగా పెద్ద పాత ప్రాజెక్ట్ అభివృద్ధిలో, నైపుణ్యం అవసరం. తప్పుగా చేసినట్లయితే, ఎనలైజర్ పనిని జోడించగలదు, అభివృద్ధిని నెమ్మదిస్తుంది మరియు జట్టును నిరుత్సాహపరుస్తుంది. డెవలప్‌మెంట్ ప్రాసెస్‌లో స్టాటిక్ అనాలిసిస్ యొక్క ఏకీకరణను ఎలా సరిగ్గా చేరుకోవాలో మరియు CI/CDలో భాగంగా ఉపయోగించడం ప్రారంభించడం గురించి క్లుప్తంగా మాట్లాడుదాం.

పరిచయం

ఇటీవల నా దృష్టిని ప్రచురణపై ఆకర్షించింది "బృందాన్ని ముంచెత్తకుండా స్టాటిక్ అనాలిసిస్‌తో ప్రారంభించడం". ఇది ఒక వైపు, పరిచయం పొందడానికి విలువైన మంచి వ్యాసం. మరోవైపు, చాలా ఉన్న ప్రాజెక్ట్‌లో స్టాటిక్ విశ్లేషణను నొప్పిలేకుండా ఎలా అమలు చేయాలి అనే దానిపై ఇప్పటికీ పూర్తి సమాధానం ఇవ్వలేదని నాకు అనిపిస్తుంది. లెగసీ కోడ్ యొక్క కథనం మీరు సాంకేతిక రుణాన్ని అంగీకరించవచ్చు మరియు కొత్త కోడ్‌పై మాత్రమే పని చేయవచ్చు, అయితే ఈ సాంకేతిక రుణాన్ని తర్వాత ఏమి చేయాలనే దానికి సమాధానం లేదు.

మా PVS-స్టూడియో బృందం ఈ అంశంపై తన అభిప్రాయాన్ని అందిస్తుంది. స్టాటిక్ కోడ్ ఎనలైజర్‌ను అమలు చేయడంలో సమస్య మొదటి స్థానంలో ఎలా తలెత్తుతుందో, ఈ సమస్యను ఎలా అధిగమించాలో మరియు సాంకేతిక రుణాన్ని నొప్పిలేకుండా ఎలా తొలగించాలో చూద్దాం.

సమస్యలు

లాంచ్ చేయడం మరియు స్టాటిక్ ఎనలైజర్ ఎలా పనిచేస్తుందో చూడడం సాధారణంగా కష్టం కాదు [1]. మీరు కోడ్‌లో ఆసక్తికరమైన లోపాలు లేదా భయానక సంభావ్య దుర్బలత్వాలను కూడా చూడవచ్చు. మీరు ఏదైనా సరిదిద్దవచ్చు, కానీ చాలా మంది ప్రోగ్రామర్లు వదులుకుంటారు.

అన్ని స్టాటిక్ ఎనలైజర్లు తప్పుడు పాజిటివ్‌లను ఉత్పత్తి చేస్తాయి. ఇది స్టాటిక్ కోడ్ విశ్లేషణ పద్దతి యొక్క లక్షణం మరియు దీని గురించి ఏమీ చేయలేము. సాధారణ సందర్భంలో, ఇది రైస్ సిద్ధాంతం ద్వారా నిర్ధారించబడిన ఒక పరిష్కరించలేని సమస్య.2]. మెషిన్ లెర్నింగ్ అల్గారిథమ్‌లు కూడా సహాయపడవు [3]. ఇది లేదా ఆ కోడ్ తప్పు కాదా అని ఒక వ్యక్తి ఎల్లప్పుడూ చెప్పలేనప్పటికీ, మీరు దీన్ని ప్రోగ్రామ్ నుండి ఆశించకూడదు :).

స్టాటిక్ ఎనలైజర్ ఇప్పటికే కాన్ఫిగర్ చేయబడి ఉంటే తప్పుడు పాజిటివ్‌లు సమస్య కాదు:

• అసంబద్ధమైన నియమ సెట్‌లు నిలిపివేయబడ్డాయి;
• కొన్ని అసంబద్ధ డయాగ్నస్టిక్‌లు నిలిపివేయబడ్డాయి;
• మేము C లేదా C++ గురించి మాట్లాడుతున్నట్లయితే, అటువంటి మాక్రోలు ఉపయోగించే ప్రతి స్థలంలో పనికిరాని హెచ్చరికలు కనిపించేలా నిర్దిష్ట నిర్మాణాలను కలిగి ఉన్న మాక్రోలు గుర్తించబడతాయి;
• సిస్టమ్ ఫంక్షన్ల (దాని స్వంత అనలాగ్) వంటి చర్యలను చేసే స్వంత విధులు గుర్తించబడతాయి మెమ్‌పిపి లేదా printf) [4];
• కామెంట్‌లను ఉపయోగించి తప్పుడు పాజిటివ్‌లు ప్రత్యేకంగా నిలిపివేయబడతాయి;
• అందువలన న.

ఈ సందర్భంలో, మేము 10-15% తక్కువ తప్పుడు సానుకూల రేటును ఆశించవచ్చు [5]. మరో మాటలో చెప్పాలంటే, 9లో 10 ఎనలైజర్ హెచ్చరికలు కోడ్‌లో నిజమైన సమస్యను సూచిస్తాయి లేదా కనీసం “బలమైన వాసన వచ్చే కోడ్‌ని” సూచిస్తాయి. అంగీకరిస్తున్నారు, ఈ దృశ్యం చాలా ఆహ్లాదకరంగా ఉంటుంది మరియు ఎనలైజర్ ప్రోగ్రామర్‌కు నిజమైన స్నేహితుడు.

వాస్తవానికి, పెద్ద ప్రాజెక్ట్‌లో, ప్రారంభ చిత్రం పూర్తిగా భిన్నంగా ఉంటుంది. లెగసీ కోడ్ కోసం ఎనలైజర్ వందల లేదా వేల హెచ్చరికలను జారీ చేస్తుంది. ఈ హెచ్చరికలలో ఏది సంబంధితమైనది మరియు ఏది కాదో త్వరగా అర్థం చేసుకోవడం అసాధ్యం. ఈ హెచ్చరికలన్నిటితో కూర్చుని వ్యవహరించడం ప్రారంభించడం అహేతుకం, ఎందుకంటే ఈ సందర్భంలో ప్రధాన పని రోజులు లేదా వారాల పాటు ఆగిపోతుంది. సాధారణంగా, ఒక బృందం అటువంటి దృష్టాంతాన్ని భరించదు. మార్పు చరిత్రను పాడుచేసే భారీ సంఖ్యలో తేడాలు కూడా ఉంటాయి. మరియు కోడ్‌లోని చాలా శకలాలు వేగంగా మాస్ ఎడిటింగ్ చేయడం వల్ల అనివార్యంగా కొత్త అక్షరదోషాలు మరియు లోపాలు ఏర్పడతాయి.

మరియు ముఖ్యంగా, హెచ్చరికలకు వ్యతిరేకంగా పోరాటంలో ఇటువంటి ఫీట్ తక్కువ అర్ధమే. ప్రాజెక్ట్ చాలా సంవత్సరాలుగా విజయవంతంగా నడుస్తున్నందున, దానిలోని చాలా క్లిష్టమైన లోపాలు ఇప్పటికే సరిదిద్దబడ్డాయి. అవును, ఈ పరిష్కారాలు చాలా ఖరీదైనవి, డీబగ్ చేయబడాలి, బగ్‌ల గురించి ప్రతికూల వినియోగదారు అభిప్రాయాన్ని పొందాయి మరియు మొదలైనవి. స్టాటిక్ ఎనలైజర్ కోడింగ్ దశలో ఈ లోపాలను చాలా త్వరగా మరియు చౌకగా పరిష్కరించడంలో సహాయపడుతుంది. కానీ ప్రస్తుతానికి, ఒక మార్గం లేదా మరొకటి, ఈ లోపాలు పరిష్కరించబడ్డాయి మరియు ఎనలైజర్ ప్రధానంగా పాత కోడ్‌లో నాన్-క్రిటికల్ లోపాలను గుర్తిస్తుంది. ఈ కోడ్ ఉపయోగించబడకపోవచ్చు, ఇది చాలా అరుదుగా ఉపయోగించబడుతుంది మరియు దానిలోని లోపం గుర్తించదగిన పరిణామాలకు దారితీయకపోవచ్చు. బహుశా ఎక్కడో బటన్ నుండి నీడ తప్పు రంగు, కానీ ఇది ఉత్పత్తి యొక్క ఎవరి ఉపయోగంతో జోక్యం చేసుకోదు.

వాస్తవానికి, చిన్న తప్పులు కూడా ఇప్పటికీ తప్పులు. మరియు కొన్నిసార్లు పొరపాటు నిజమైన దుర్బలత్వాన్ని దాచవచ్చు. ఏది ఏమైనప్పటికీ, అన్నింటినీ వదిలిపెట్టి, కేవలం తమను తాము వ్యక్తపరిచే లోపాలతో రోజులు/వారాలు గడపడం సందేహాస్పదమైన ఆలోచనగా కనిపిస్తుంది.

ప్రోగ్రామర్లు చూడండి, చూడండి, పాత వర్కింగ్ కోడ్ గురించి ఈ హెచ్చరికలన్నింటినీ చూడండి... మరియు వారు ఆలోచిస్తారు: మేము స్టాటిక్ విశ్లేషణ లేకుండా చేయగలము. కొన్ని కొత్త ఉపయోగకరమైన కార్యాచరణలను వ్రాయడానికి వెళ్దాం.

వారి స్వంత మార్గంలో, వారు సరైనవారు. ముందుగా ఈ హెచ్చరికలన్నింటినీ ఎలాగైనా వదిలించుకోవాలని వారు భావిస్తున్నారు. అప్పుడే వారు కోడ్ ఎనలైజర్‌ను క్రమం తప్పకుండా ఉపయోగించడం ద్వారా ప్రయోజనం పొందగలుగుతారు. లేకపోతే, కొత్త హెచ్చరికలు కేవలం పాత వాటిలో మునిగిపోతాయి మరియు ఎవరూ వాటికి శ్రద్ధ చూపరు.

కంపైలర్ హెచ్చరికలతో ఇదే సారూప్యత. కంపైలర్ హెచ్చరికల సంఖ్యను 0 వద్ద ఉంచాలని వారు సిఫార్సు చేయడం కారణం లేకుండా కాదు. 1000 హెచ్చరికలు ఉంటే, 1001 ఉన్నప్పుడు, ఎవరూ దానిపై శ్రద్ధ చూపరు మరియు ఈ సరికొత్త హెచ్చరిక కోసం ఎక్కడ వెతకాలో స్పష్టంగా లేదు.

ఈ సమయంలో పై నుండి ఎవరైనా స్టాటిక్ కోడ్ విశ్లేషణను ఉపయోగించమని మిమ్మల్ని బలవంతం చేస్తే ఈ కథలోని చెత్త విషయం. ఇది జట్టును బలహీనపరుస్తుంది, ఎందుకంటే వారి దృక్కోణం నుండి అదనపు బ్యూరోక్రాటిక్ సంక్లిష్టత మాత్రమే దారిలోకి వస్తుంది. ఎనలైజర్ యొక్క నివేదికలను ఎవరూ చూడరు మరియు అన్ని ఉపయోగం "కాగితంపై" మాత్రమే ఉంటుంది. ఆ. అధికారికంగా, విశ్లేషణ DevOps ప్రక్రియలో నిర్మించబడింది, కానీ ఆచరణలో ఇది ఎవరికీ ప్రయోజనం కలిగించదు. మేము సమావేశానికి హాజరైన వారి నుండి బూత్‌లలో వివరణాత్మక కథనాలను విన్నాము. అటువంటి అనుభవం ప్రోగ్రామర్‌లను ఎప్పటికీ కాకపోయినా చాలా కాలం పాటు స్టాటిక్ అనాలిసిస్ సాధనాలను ఉపయోగించకుండా నిరుత్సాహపరుస్తుంది.

సాంకేతిక రుణాన్ని అమలు చేయడం మరియు తొలగించడం

నిజానికి, పెద్ద పాత ప్రాజెక్ట్‌లో కూడా స్టాటిక్ అనాలిసిస్‌ని ప్రవేశపెట్టడంలో కష్టం లేదా భయానకంగా ఏమీ లేదు.

CI/CD

అంతేకాకుండా, ఎనలైజర్‌ను తక్షణమే నిరంతర అభివృద్ధి ప్రక్రియలో భాగం చేయవచ్చు. ఉదాహరణకు, PVS-స్టూడియో పంపిణీలో మీకు అవసరమైన ఫార్మాట్‌లో నివేదికను సౌకర్యవంతంగా వీక్షించడానికి మరియు కోడ్ యొక్క సమస్యాత్మక విభాగాలను వ్రాసిన డెవలపర్‌లకు నోటిఫికేషన్‌లను కలిగి ఉంటుంది. CI/CD సిస్టమ్‌ల నుండి PVS-స్టూడియోని ప్రారంభించడం పట్ల ఎక్కువ ఆసక్తి ఉన్న వారి కోసం, సంబంధిత వాటితో మీకు పరిచయం ఉండాలని నేను సిఫార్సు చేస్తున్నాను విభాగం డాక్యుమెంటేషన్ మరియు కథనాల శ్రేణి:

• PVS-స్టూడియో మేఘాలకు వెళుతుంది: Azure Devops
• PVS-స్టూడియో మేఘాలకు వెళుతుంది: ట్రావిస్ CI
• PVS-స్టూడియో మేఘాలకు వెళుతుంది: GitLab CI/CD
• PVS-స్టూడియో మేఘాలకు వెళుతుంది: CircleCI

కానీ కోడ్ విశ్లేషణ సాధనాలను అమలు చేసే మొదటి దశలలో పెద్ద సంఖ్యలో తప్పుడు పాజిటివ్‌ల సమస్యకు తిరిగి వెళ్దాం.

ఇప్పటికే ఉన్న సాంకేతిక రుణాన్ని పరిష్కరించడం మరియు కొత్త హెచ్చరికలతో వ్యవహరించడం

ఆధునిక వాణిజ్య స్టాటిక్ ఎనలైజర్‌లు కొత్త లేదా మార్చబడిన కోడ్‌లో కనిపించే కొత్త హెచ్చరికలను మాత్రమే అధ్యయనం చేయడానికి మిమ్మల్ని అనుమతిస్తాయి. ఈ యంత్రాంగం యొక్క అమలు మారుతూ ఉంటుంది, కానీ సారాంశం అదే. PVS-స్టూడియో స్టాటిక్ ఎనలైజర్‌లో, ఈ కార్యాచరణ క్రింది విధంగా అమలు చేయబడుతుంది.

స్టాటిక్ అనాలిసిస్‌ని త్వరగా ఉపయోగించడం ప్రారంభించడానికి, PVS-స్టూడియో వినియోగదారులు హెచ్చరికలను పెద్దఎత్తున అణిచివేసేందుకు యంత్రాంగాన్ని ఉపయోగించాలని మేము సూచిస్తున్నాము [6]. సాధారణ ఆలోచన క్రిందిది. వినియోగదారు ఎనలైజర్‌ను ప్రారంభించారు మరియు అనేక హెచ్చరికలను అందుకున్నారు. చాలా సంవత్సరాలుగా అభివృద్ధిలో ఉన్న ప్రాజెక్ట్ సజీవంగా ఉన్నందున, అభివృద్ధి చెందుతోంది మరియు డబ్బు సంపాదిస్తుంది, అప్పుడు నివేదికలో క్లిష్టమైన లోపాలను సూచించే అనేక హెచ్చరికలు ఉండవు. మరో మాటలో చెప్పాలంటే, క్లిష్టమైన బగ్‌లు ఇప్పటికే ఒక విధంగా లేదా మరొక విధంగా ఖరీదైన పద్ధతులను ఉపయోగించి పరిష్కరించబడ్డాయి లేదా కస్టమర్‌ల నుండి వచ్చిన అభిప్రాయానికి ధన్యవాదాలు. దీని ప్రకారం, ఎనలైజర్ ప్రస్తుతం కనుగొన్న ప్రతిదీ సాంకేతిక రుణంగా పరిగణించబడుతుంది, ఇది వెంటనే తొలగించడానికి ప్రయత్నించడం అసాధ్యమైనది.

మీరు PVS-స్టూడియోకు ఈ హెచ్చరికలను ప్రస్తుతానికి అసంబద్ధంగా పరిగణించమని చెప్పవచ్చు (తర్వాత సాంకేతిక రుణాన్ని ఆదా చేయండి), మరియు అది ఇకపై వాటిని చూపదు. ఎనలైజర్ ఒక ప్రత్యేక ఫైల్‌ను సృష్టిస్తుంది, ఇక్కడ అది ఇంకా ఆసక్తికరంగా లేని లోపాల గురించి సమాచారాన్ని సేవ్ చేస్తుంది. ఇప్పుడు PVS-స్టూడియో కొత్త లేదా మార్చబడిన కోడ్ కోసం మాత్రమే హెచ్చరికలను జారీ చేస్తుంది. పైగా, ఇదంతా తెలివిగా అమలు చేస్తారు. ఉదాహరణకు, సోర్స్ కోడ్ ఫైల్ ప్రారంభంలో ఖాళీ లైన్ జోడించబడితే, వాస్తవానికి, ఏమీ మారలేదని మరియు నిశ్శబ్దంగా కొనసాగుతుందని ఎనలైజర్ అర్థం చేసుకుంటుంది. ఈ మార్కప్ ఫైల్‌ను వెర్షన్ కంట్రోల్ సిస్టమ్‌లో ఉంచవచ్చు. ఫైల్ పెద్దది, కానీ ఇది సమస్య కాదు, ఎందుకంటే దీన్ని తరచుగా నిల్వ చేయడంలో అర్థం లేదు.

ఇప్పుడు అందరు ప్రోగ్రామర్లు కొత్త లేదా మార్చబడిన కోడ్‌కు సంబంధించిన హెచ్చరికలను మాత్రమే చూస్తారు. అందువల్ల, మీరు మరుసటి రోజు నుండి వారు చెప్పినట్లు ఎనలైజర్‌ను ఉపయోగించడం ప్రారంభించవచ్చు. మరియు మీరు తరువాత సాంకేతిక రుణానికి తిరిగి రావచ్చు మరియు క్రమంగా లోపాలను సరిదిద్దవచ్చు మరియు ఎనలైజర్‌ను కాన్ఫిగర్ చేయవచ్చు.

కాబట్టి, పెద్ద పాత ప్రాజెక్ట్‌లో ఎనలైజర్ అమలుతో మొదటి సమస్య పరిష్కరించబడింది. సాంకేతిక రుణంతో ఏమి చేయాలో ఇప్పుడు తెలుసుకుందాం.

బగ్ పరిష్కారాలు మరియు రీఫ్యాక్టరింగ్‌లు

భారీ స్థాయిలో అణచివేయబడిన ఎనలైజర్ హెచ్చరికలను విశ్లేషించడానికి మరియు క్రమంగా వాటితో వ్యవహరించడానికి కొంత సమయాన్ని కేటాయించడం సరళమైన మరియు అత్యంత సహజమైన విషయం. ఎక్కడా మీరు కోడ్‌లో లోపాలను సరిచేయాలి, ఎక్కడో మీరు కోడ్ సమస్యాత్మకం కాదని ఎనలైజర్‌కి చెప్పడానికి రీఫాక్టర్ చేయాలి. సాధారణ ఉదాహరణ:

if (a = b)

చాలా మంది C++ కంపైలర్‌లు మరియు ఎనలైజర్‌లు అలాంటి కోడ్ గురించి ఫిర్యాదు చేస్తారు, ఎందుకంటే వారు నిజంగా రాయాలనుకుంటున్నారు. (a == b). కానీ చెప్పని ఒప్పందం ఉంది, మరియు ఇది సాధారణంగా డాక్యుమెంటేషన్‌లో గుర్తించబడుతుంది, అదనపు కుండలీకరణాలు ఉంటే, ప్రోగ్రామర్ ఉద్దేశపూర్వకంగా అలాంటి కోడ్‌ను వ్రాసినట్లు పరిగణించబడుతుంది మరియు ప్రమాణం చేయవలసిన అవసరం లేదు. ఉదాహరణకు, డయాగ్నస్టిక్స్ కోసం PVS-స్టూడియో డాక్యుమెంటేషన్‌లో V559 (CWE-481) కింది లైన్ సరైనది మరియు సురక్షితమైనదిగా పరిగణించబడుతుందని స్పష్టంగా వ్రాయబడింది:

if ((a = b))

మరొక ఉదాహరణ. ఈ C++ కోడ్‌లో అది మరచిపోయిందా? విరామం లేదా?

case A:
  foo();
case B:
  bar();
  break;

PVS-స్టూడియో ఎనలైజర్ ఇక్కడ హెచ్చరికను జారీ చేస్తుంది V796 (CWE-484). ఇది లోపం కాకపోవచ్చు, ఈ సందర్భంలో మీరు లక్షణాన్ని జోడించడం ద్వారా పార్సర్‌కు సూచనను ఇవ్వాలి [[పతనం ద్వారా]] లేదా, ఉదాహరణకు, __లక్షణం__((ఫాల్‌త్రూ)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

ఇటువంటి కోడ్ మార్పులు బగ్‌ను పరిష్కరించవని చెప్పవచ్చు. అవును, ఇది నిజం, కానీ ఇది రెండు ఉపయోగకరమైన పనులను చేస్తుంది. ముందుగా, ఎనలైజర్ రిపోర్ట్ తప్పుడు పాజిటివ్‌లను తొలగిస్తుంది. రెండవది, కోడ్ దాని నిర్వహణలో పాల్గొన్న వ్యక్తులకు మరింత అర్థమవుతుంది. మరియు ఇది చాలా ముఖ్యం! దీని కోసం మాత్రమే, కోడ్‌ను స్పష్టంగా మరియు సులభంగా నిర్వహించడానికి చిన్న రీఫ్యాక్టరింగ్‌లను నిర్వహించడం విలువైనదే. "బ్రేక్" అవసరమా కాదా అనేది ఎనలైజర్‌కు అర్థం కానందున, ఇది తోటి ప్రోగ్రామర్‌లకు కూడా అస్పష్టంగా ఉంటుంది.

బగ్ పరిష్కారాలు మరియు రీఫ్యాక్టరింగ్‌లతో పాటు, మీరు స్పష్టంగా తప్పుడు ఎనలైజర్ హెచ్చరికలను ప్రత్యేకంగా అణచివేయవచ్చు. కొన్ని అసంబద్ధమైన డయాగ్నస్టిక్‌లు నిలిపివేయబడవచ్చు. ఉదాహరణకు, హెచ్చరికలు అర్థరహితమని ఎవరైనా అనుకుంటారు V550 ఫ్లోట్/డబుల్ విలువలను పోల్చడం గురించి. మరియు కొందరు వాటిని ముఖ్యమైనవి మరియు అధ్యయనానికి యోగ్యమైనవిగా వర్గీకరిస్తారు [7]. ఏ హెచ్చరికలు సంబంధితంగా పరిగణించబడతాయో మరియు ఏది కాదో డెవలప్‌మెంట్ టీమ్‌పై ఆధారపడి ఉంటుంది.

తప్పుడు హెచ్చరికలను అణచివేయడానికి ఇతర మార్గాలు ఉన్నాయి. ఉదాహరణకు, స్థూల మార్కప్ ముందుగా ప్రస్తావించబడింది. ఇవన్నీ డాక్యుమెంటేషన్‌లో మరింత వివరంగా వివరించబడ్డాయి. అతి ముఖ్యమైన విషయం ఏమిటంటే, మీరు క్రమంగా మరియు క్రమపద్ధతిలో తప్పుడు పాజిటివ్‌లతో పనిచేయడానికి చేరుకుంటే, వాటిలో తప్పు ఏమీ లేదని అర్థం చేసుకోవడం. కాన్ఫిగరేషన్ తర్వాత చాలా వరకు రసహీనమైన హెచ్చరికలు అదృశ్యమవుతాయి మరియు నిజంగా జాగ్రత్తగా అధ్యయనం మరియు కోడ్‌లో కొన్ని మార్పులు అవసరమయ్యే స్థలాలు మాత్రమే మిగిలి ఉన్నాయి.

అలాగే, ఏవైనా ఇబ్బందులు తలెత్తితే మేము ఎల్లప్పుడూ మా క్లయింట్‌లకు PVS-స్టూడియోను సెటప్ చేయడానికి సహాయం చేస్తాము. అంతేకాకుండా, మనమే తప్పుడు హెచ్చరికలను తొలగించి, లోపాలను సరిచేసిన సందర్భాలు ఉన్నాయి [8]. ఒకవేళ, పొడిగించిన సహకారం కోసం ఈ ఎంపిక కూడా సాధ్యమేనని నేను పేర్కొనాలని నిర్ణయించుకున్నాను :).

రాట్చెట్ పద్ధతి

స్టాటిక్ ఎనలైజర్ హెచ్చరికను తొలగించడం ద్వారా కోడ్ నాణ్యతను క్రమంగా మెరుగుపరచడానికి మరొక ఆసక్తికరమైన విధానం ఉంది. బాటమ్ లైన్ హెచ్చరికల సంఖ్య మాత్రమే తగ్గుతుంది.

స్టాటిక్ ఎనలైజర్ జారీ చేసిన హెచ్చరికల సంఖ్య రికార్డ్ చేయబడింది. నాణ్యమైన గేట్ ఇప్పుడు మీరు కార్యకలాపాల సంఖ్యను పెంచని కోడ్‌ను మాత్రమే నమోదు చేయగల విధంగా కాన్ఫిగర్ చేయబడింది. ఫలితంగా, ఎనలైజర్‌ని సర్దుబాటు చేయడం మరియు లోపాలను సరిదిద్దడం ద్వారా అలారాల సంఖ్యను క్రమంగా తగ్గించే ప్రక్రియ ప్రారంభమవుతుంది.

ఒక వ్యక్తి కొంచెం మోసం చేయాలనుకున్నా మరియు తన కొత్త కోడ్‌లోని హెచ్చరికలను తొలగించడం ద్వారా కాకుండా, పాత మూడవ పక్షం కోడ్‌ను మెరుగుపరచడం ద్వారా నాణ్యమైన గేట్‌ను పాస్ చేయాలని నిర్ణయించుకున్నా, ఇది భయానకంగా లేదు. ఒకే విధంగా, రాట్చెట్ ఒక దిశలో తిరుగుతుంది మరియు క్రమంగా లోపాల సంఖ్య తగ్గుతుంది. ఒక వ్యక్తి తన స్వంత కొత్త లోపాలను సరిదిద్దకూడదనుకున్నప్పటికీ, అతను ఇప్పటికీ పొరుగు కోడ్‌లో ఏదైనా మెరుగుపరచవలసి ఉంటుంది. ఏదో ఒక సమయంలో, హెచ్చరికల సంఖ్యను తగ్గించడానికి సులభమైన మార్గాలు ముగుస్తాయి మరియు నిజమైన బగ్‌లు పరిష్కరించబడే పాయింట్ వస్తుంది.

ఇవాన్ పొనోమరేవ్ రాసిన చాలా ఆసక్తికరమైన వ్యాసంలో ఈ పద్దతి మరింత వివరంగా వివరించబడింది "బగ్‌లను కనుగొనడానికి దాన్ని ఉపయోగించకుండా, ప్రక్రియలో స్టాటిక్ విశ్లేషణను అమలు చేయండి", కోడ్ నాణ్యతను మెరుగుపరచడంలో ఆసక్తి ఉన్న ఎవరికైనా చదవమని నేను సిఫార్సు చేస్తున్నాను.

వ్యాసం యొక్క రచయిత ఈ అంశంపై ఒక నివేదికను కూడా కలిగి ఉన్నారు: "నిరంతర స్టాటిక్ విశ్లేషణ".

తీర్మానం

ఈ ఆర్టికల్ తర్వాత, పాఠకులు స్టాటిక్ ఎనాలిసిస్ టూల్స్‌ను ఎక్కువగా అంగీకరిస్తారని మరియు వాటిని అభివృద్ధి ప్రక్రియలో అమలు చేయాలని నేను ఆశిస్తున్నాను. మీకు ఏవైనా ప్రశ్నలు ఉంటే, మేము ఎల్లప్పుడూ సిద్ధంగా ఉన్నాము సలహా ఇవ్వండి మా స్టాటిక్ ఎనలైజర్ PVS-స్టూడియో యొక్క వినియోగదారులు మరియు దాని అమలులో సహాయం చేయండి.

స్టాటిక్ విశ్లేషణ నిజంగా సౌకర్యవంతంగా మరియు ఉపయోగకరంగా ఉంటుందా అనే దానిపై ఇతర సాధారణ సందేహాలు ఉన్నాయి. “PVS-Studio స్టాటిక్ కోడ్ ఎనలైజర్‌ను డెవలప్‌మెంట్ ప్రాసెస్‌లో ప్రవేశపెట్టడానికి కారణాలు” అనే ప్రచురణలో నేను ఈ సందేహాలను చాలా వరకు తొలగించడానికి ప్రయత్నించాను.9].

మీ దృష్టికి ధన్యవాదాలు మరియు రండి скачать మరియు PVS-స్టూడియో ఎనలైజర్‌ని ప్రయత్నించండి.

అదనపు లింకులు

1. ఆండ్రీ కార్పోవ్. C మరియు C++ కోడ్ కోసం PVS-స్టూడియో ఎనలైజర్ ఉత్పత్తి చేసే ఆసక్తికరమైన హెచ్చరికలను నేను త్వరగా ఎలా చూడగలను?
2. వికీపీడియా. రైస్ సిద్ధాంతం.
3. ఆండ్రీ కార్పోవ్, విక్టోరియా ఖనీవా. ప్రోగ్రామ్ సోర్స్ కోడ్ యొక్క స్టాటిక్ విశ్లేషణలో యంత్ర అభ్యాసాన్ని ఉపయోగించడం.
4. PVS-స్టూడియో. డాక్యుమెంటేషన్. అదనపు విశ్లేషణ సెట్టింగ్‌లు.
5. ఆండ్రీ కార్పోవ్. EFL కోర్ లైబ్రరీల ఉదాహరణను ఉపయోగించి PVS-స్టూడియో ఎనలైజర్ యొక్క లక్షణాలు, 10-15% తప్పుడు పాజిటివ్‌లు.
6. PVS-స్టూడియో. డాక్యుమెంటేషన్. ఎనలైజర్ సందేశాల మాస్ అణచివేత.
7. ఇవాన్ ఆండ్రియాషిన్. ఎక్స్-రే ఎండోవాస్కులర్ సర్జరీ యొక్క ఎడ్యుకేషనల్ సిమ్యులేటర్ యొక్క మా ప్రాజెక్ట్‌పై మేము స్టాటిక్ విశ్లేషణను ఎలా పరీక్షించాము అనే దాని గురించి.
8. పావెల్ ఎరెమీవ్, స్వ్యటోస్లావ్ రాజ్మిస్లోవ్. PVS-స్టూడియో బృందం అన్‌రియల్ ఇంజిన్ కోడ్‌ని ఎలా మెరుగుపరిచింది.
9. ఆండ్రీ కార్పోవ్. అభివృద్ధి ప్రక్రియలో స్టాటిక్ కోడ్ ఎనలైజర్ PVS-స్టూడియోను పరిచయం చేయడానికి కారణాలు.

మీరు ఈ కథనాన్ని ఇంగ్లీష్ మాట్లాడే ప్రేక్షకులతో భాగస్వామ్యం చేయాలనుకుంటే, దయచేసి అనువాద లింక్‌ని ఉపయోగించండి: Andrey Karpov. లెగసీ ప్రాజెక్ట్‌లో స్టాటిక్ కోడ్ ఎనలైజర్‌ని ఎలా పరిచయం చేయాలి మరియు టీమ్‌ను నిరుత్సాహపరచకూడదు.

మూలం: www.habr.com