ஒரு மரபு திட்டத்தில் ஒரு நிலையான குறியீடு பகுப்பாய்வியை எவ்வாறு செயல்படுத்துவது, குழுவைத் தாழ்த்தாமல்

நிலையான குறியீடு பகுப்பாய்வியை முயற்சிப்பது எளிது. ஆனால் அதை செயல்படுத்த, குறிப்பாக ஒரு பெரிய பழைய திட்டத்தின் வளர்ச்சியில், திறமை தேவை. தவறாகச் செய்தால், பகுப்பாய்வி வேலையைச் சேர்க்கலாம், வளர்ச்சியைக் குறைக்கலாம் மற்றும் குழுவைத் தாழ்த்தலாம். வளர்ச்சி செயல்முறையில் நிலையான பகுப்பாய்வின் ஒருங்கிணைப்பை எவ்வாறு சரியாக அணுகுவது மற்றும் அதை CI/CD இன் பகுதியாகப் பயன்படுத்தத் தொடங்குவது பற்றி சுருக்கமாகப் பேசுவோம்.

அறிமுகம்

சமீபத்தில் எனது கவனத்தை வெளியீட்டில் ஈர்த்தது "குழுவை அதிகப்படுத்தாமல் நிலையான பகுப்பாய்வுடன் தொடங்குதல்". இது ஒருபுறம், நன்கு தெரிந்துகொள்ள வேண்டிய ஒரு நல்ல கட்டுரை, மறுபுறம், ஒரு திட்டத்தில் நிலையான பகுப்பாய்வை எவ்வாறு வலியின்றி செயல்படுத்துவது என்பது பற்றிய முழுமையான பதிலை இது இன்னும் வழங்கவில்லை என்று எனக்குத் தோன்றுகிறது. மரபுக் குறியீடு. நீங்கள் தொழில்நுட்பக் கடனை ஏற்றுக்கொண்டு புதிய குறியீட்டில் மட்டுமே வேலை செய்ய முடியும் என்று கட்டுரை கூறுகிறது, ஆனால் இந்த தொழில்நுட்பக் கடனை பின்னர் என்ன செய்வது என்பதற்கு பதில் இல்லை.

எங்கள் PVS-ஸ்டுடியோ குழு இந்த தலைப்பில் அதன் பார்வையை வழங்குகிறது. ஒரு நிலையான குறியீடு பகுப்பாய்வியை செயல்படுத்துவதில் சிக்கல் எவ்வாறு முதலில் எழுகிறது, இந்த சிக்கலை எவ்வாறு சமாளிப்பது மற்றும் தொழில்நுட்பக் கடனை எவ்வாறு வலியின்றி படிப்படியாக அகற்றுவது என்பதைப் பார்ப்போம்.

சிக்கல்கள்

ஒரு நிலையான பகுப்பாய்வி எவ்வாறு செயல்படுகிறது என்பதைப் பார்ப்பது பொதுவாக கடினமாக இருக்காது.1]. குறியீட்டில் சுவாரஸ்யமான பிழைகள் அல்லது பயமுறுத்தும் சாத்தியமான பாதிப்புகளைக் கூட நீங்கள் காணலாம். நீங்கள் எதையாவது சரிசெய்யலாம், ஆனால் பல புரோகிராமர்கள் கைவிடுகிறார்கள்.

அனைத்து நிலையான பகுப்பாய்விகளும் தவறான நேர்மறைகளை உருவாக்குகின்றன. இது நிலையான குறியீடு பகுப்பாய்வு முறையின் ஒரு அம்சமாகும், மேலும் இதைப் பற்றி எதுவும் செய்ய முடியாது. பொது வழக்கில், இது ரைஸின் தேற்றத்தால் உறுதிப்படுத்தப்பட்ட தீர்க்க முடியாத பிரச்சனையாகும்.2]. இயந்திர கற்றல் வழிமுறைகளும் உதவாது [3]. இந்த அல்லது அந்த குறியீடு தவறானதா என்பதை ஒரு நபர் எப்போதும் சொல்ல முடியாவிட்டாலும், நிரலிலிருந்து இதை நீங்கள் எதிர்பார்க்கக்கூடாது :).

நிலையான பகுப்பாய்வி ஏற்கனவே உள்ளமைக்கப்பட்டிருந்தால் தவறான நேர்மறைகள் ஒரு பிரச்சனையாக இருக்காது:

• பொருத்தமற்ற விதிகளை முடக்கியது;
• சில பொருத்தமற்ற நோயறிதல்கள் முடக்கப்பட்டுள்ளன;
• நாம் C அல்லது C++ பற்றி பேசுகிறோம் என்றால், மேக்ரோக்கள் பயன்படுத்தப்படும் ஒவ்வொரு இடத்திலும் பயனற்ற எச்சரிக்கைகள் தோன்றும் குறிப்பிட்ட கட்டுமானங்களைக் கொண்டிருக்கும் மேக்ரோக்கள் குறிக்கப்படுகின்றன;
• கணினி செயல்பாடுகளைப் போன்ற செயல்களைச் செய்யும் சொந்த செயல்பாடுகள் குறிக்கப்பட்டுள்ளன (அதன் சொந்த அனலாக் மெம்கிபி அல்லது வைட்டமின்) [4];
• கருத்துகளைப் பயன்படுத்தி தவறான நேர்மறைகள் குறிப்பாக முடக்கப்பட்டுள்ளன;
• அதனால் தான்.

இந்த வழக்கில், 10-15% குறைவான தவறான நேர்மறை விகிதத்தை நாம் எதிர்பார்க்கலாம்.5]. வேறு வார்த்தைகளில் கூறுவதானால், 9 இல் 10 பகுப்பாய்வி எச்சரிக்கைகள் குறியீட்டில் உண்மையான சிக்கலைக் குறிக்கும், அல்லது குறைந்தபட்சம் "வலுவான வாசனை குறியீடு". ஒப்புக்கொள்கிறேன், இந்த காட்சி மிகவும் இனிமையானது, மேலும் பகுப்பாய்வி புரோகிராமரின் உண்மையான நண்பர்.

உண்மையில், ஒரு பெரிய திட்டத்தில், ஆரம்ப படம் முற்றிலும் வேறுபட்டதாக இருக்கும். பகுப்பாய்வி மரபுக் குறியீட்டிற்கு நூற்றுக்கணக்கான அல்லது ஆயிரக்கணக்கான எச்சரிக்கைகளை வெளியிடுகிறது. இந்த எச்சரிக்கைகளில் எது பொருத்தமானது மற்றும் எது பொருந்தாது என்பதை விரைவாக புரிந்து கொள்ள முடியாது. உட்கார்ந்து இந்த எச்சரிக்கைகள் அனைத்தையும் கையாள்வது பகுத்தறிவற்றது, ஏனெனில் இந்த வழக்கில் முக்கிய வேலை நாட்கள் அல்லது வாரங்களுக்கு நிறுத்தப்படும். பொதுவாக, ஒரு குழு அத்தகைய சூழ்நிலையை வாங்க முடியாது. மாற்ற வரலாற்றைக் கெடுக்கும் பெரிய எண்ணிக்கையிலான வேறுபாடுகளும் இருக்கும். குறியீட்டில் உள்ள பல துண்டுகளை விரைவாகத் திருத்துவது தவிர்க்க முடியாமல் புதிய எழுத்துப்பிழைகள் மற்றும் பிழைகளை ஏற்படுத்தும்.

மற்றும் மிக முக்கியமாக, எச்சரிக்கைகளுக்கு எதிரான போராட்டத்தில் இதுபோன்ற ஒரு சாதனை சிறிது அர்த்தமுள்ளதாக இல்லை. திட்டம் பல ஆண்டுகளாக வெற்றிகரமாக இயங்கி வருவதால், அதில் உள்ள பெரும்பாலான முக்கியமான பிழைகள் ஏற்கனவே சரி செய்யப்பட்டுள்ளன என்பதை ஒப்புக்கொள்கிறேன். ஆம், இந்த திருத்தங்கள் மிகவும் விலை உயர்ந்தவை, பிழைத்திருத்தம் செய்யப்பட வேண்டும், பிழைகள் பற்றிய எதிர்மறையான பயனர் கருத்துக்களைப் பெற்றன, மற்றும் பல. ஒரு நிலையான பகுப்பாய்வி இந்த பிழைகளில் பலவற்றை குறியீட்டு நிலையில் விரைவாகவும் மலிவாகவும் சரிசெய்ய உதவும். ஆனால் இந்த நேரத்தில், ஒரு வழி அல்லது வேறு, இந்த பிழைகள் சரி செய்யப்பட்டுள்ளன, மேலும் பகுப்பாய்வி முக்கியமாக பழைய குறியீட்டில் முக்கியமற்ற பிழைகளைக் கண்டறிகிறது. இந்த குறியீடு பயன்படுத்தப்படாமல் இருக்கலாம், இது மிகவும் அரிதாகவே பயன்படுத்தப்படலாம், மேலும் அதில் உள்ள பிழை குறிப்பிடத்தக்க விளைவுகளுக்கு வழிவகுக்காது. ஒருவேளை எங்காவது பொத்தானின் நிழல் தவறான நிறமாக இருக்கலாம், ஆனால் இது தயாரிப்பின் யாருடைய பயன்பாட்டிலும் தலையிடாது.

நிச்சயமாக, சிறிய தவறுகள் கூட இன்னும் தவறுகள். சில நேரங்களில் ஒரு தவறு உண்மையான பாதிப்பை மறைத்துவிடும். இருப்பினும், எல்லாவற்றையும் விட்டுவிட்டு, தங்களை வெளிப்படுத்தாத குறைபாடுகளைக் கையாள்வதில் நாட்கள்/வாரங்கள் செலவிடுவது சந்தேகத்திற்குரிய யோசனையாகத் தெரிகிறது.

புரோகிராமர்கள் பழைய வேலைக் குறியீட்டைப் பற்றிய அனைத்து எச்சரிக்கைகளையும் பாருங்கள், பாருங்கள், பாருங்கள்... மேலும் அவர்கள் நினைக்கிறார்கள்: நிலையான பகுப்பாய்வு இல்லாமல் செய்யலாம். சில புதிய பயனுள்ள செயல்பாடுகளை எழுதுவோம்.

அவர்களின் சொந்த வழியில், அவர்கள் சொல்வது சரிதான். முதலில் எப்படியாவது இந்த எச்சரிக்கைகளில் இருந்து விடுபட வேண்டும் என்று அவர்கள் எண்ணுகிறார்கள். அப்போதுதான் அவர்கள் குறியீடு பகுப்பாய்வியை தொடர்ந்து பயன்படுத்துவதன் மூலம் பயனடைய முடியும். இல்லையெனில், புதிய எச்சரிக்கைகள் பழையவற்றில் மூழ்கிவிடும், யாரும் அவர்களுக்கு கவனம் செலுத்த மாட்டார்கள்.

இது கம்பைலர் எச்சரிக்கைகளின் அதே ஒப்புமையாகும். கம்பைலர் எச்சரிக்கைகளின் எண்ணிக்கையை 0 ஆக வைக்க அவர்கள் பரிந்துரைப்பது காரணமின்றி இல்லை. 1000 எச்சரிக்கைகள் இருந்தால், 1001 இருக்கும் போது, ​​யாரும் அதை கவனிக்க மாட்டார்கள், மேலும் இந்த புதிய எச்சரிக்கையை எங்கு தேடுவது என்பது தெளிவாகத் தெரியவில்லை.

இந்தக் கதையில் உள்ள மோசமான விஷயம் என்னவென்றால், இந்த நேரத்தில் மேலே இருந்து யாராவது உங்களை நிலையான குறியீடு பகுப்பாய்வைப் பயன்படுத்தும்படி கட்டாயப்படுத்தினால். இது அணியைக் குறைமதிப்பிற்கு உட்படுத்தும், ஏனெனில் அவர்களின் பார்வையில் கூடுதல் அதிகாரத்துவ சிக்கலானது மட்டுமே வழிக்கு வரும். பகுப்பாய்வியின் அறிக்கைகளை யாரும் பார்க்க மாட்டார்கள், மேலும் அனைத்து பயன்பாடுகளும் "காகிதத்தில்" மட்டுமே இருக்கும். அந்த. முறையாக, பகுப்பாய்வு DevOps செயல்முறையில் கட்டமைக்கப்பட்டுள்ளது, ஆனால் நடைமுறையில் இது யாருக்கும் பயனளிக்காது. மாநாட்டில் கலந்து கொண்டவர்களிடமிருந்து விரிவான கதைகளை நாங்கள் சாவடிகளில் கேட்டோம். இத்தகைய அனுபவம் புரோகிராமர்களை நீண்ட காலத்திற்கு நிலையான பகுப்பாய்வுக் கருவிகளைப் பயன்படுத்துவதை ஊக்கப்படுத்தலாம், இல்லையென்றாலும்.

தொழில்நுட்ப கடனை செயல்படுத்துதல் மற்றும் நீக்குதல்

உண்மையில், ஒரு பெரிய பழைய திட்டத்தில் கூட நிலையான பகுப்பாய்வை அறிமுகப்படுத்துவதில் கடினமான அல்லது பயமுறுத்தும் எதுவும் இல்லை.

சிஐ / சிடி

மேலும், பகுப்பாய்வி உடனடியாக தொடர்ச்சியான வளர்ச்சி செயல்முறையின் ஒரு பகுதியாக மாற்றப்படலாம். எடுத்துக்காட்டாக, PVS-ஸ்டுடியோ விநியோகத்தில் உங்களுக்குத் தேவையான வடிவத்தில் அறிக்கையை வசதியாகப் பார்ப்பதற்கான பயன்பாடுகள் மற்றும் குறியீட்டின் சிக்கலான பிரிவுகளை எழுதிய டெவலப்பர்களுக்கான அறிவிப்புகள் உள்ளன. CI/CD அமைப்புகளில் இருந்து PVS-ஸ்டுடியோவைத் தொடங்குவதில் அதிக ஆர்வமுள்ளவர்கள், தொடர்புடையவற்றைப் பற்றி நன்கு தெரிந்துகொள்ளுமாறு பரிந்துரைக்கிறேன். பிரிவு ஆவணங்கள் மற்றும் தொடர் கட்டுரைகள்:

• பிவிஎஸ்-ஸ்டுடியோ மேகங்களுக்குச் செல்கிறது: அஸூர் டெவொப்ஸ்
• பிவிஎஸ்-ஸ்டுடியோ மேகங்களுக்கு செல்கிறது: டிராவிஸ் சிஐ
• PVS-ஸ்டுடியோ மேகங்களுக்குச் செல்கிறது: GitLab CI/CD
• PVS-ஸ்டுடியோ மேகங்களுக்கு செல்கிறது: CircleCI

ஆனால் குறியீடு பகுப்பாய்வு கருவிகளை செயல்படுத்துவதற்கான முதல் கட்டங்களில் ஏராளமான தவறான நேர்மறைகளின் சிக்கலுக்குத் திரும்புவோம்.

தற்போதுள்ள தொழில்நுட்ப கடனை சரிசெய்தல் மற்றும் புதிய எச்சரிக்கைகளை கையாளுதல்

நவீன வணிக நிலையான பகுப்பாய்விகள் புதிய அல்லது மாற்றப்பட்ட குறியீட்டில் தோன்றும் புதிய எச்சரிக்கைகளை மட்டுமே படிக்க அனுமதிக்கின்றன. இந்த பொறிமுறையை செயல்படுத்துவது மாறுபடும், ஆனால் சாராம்சம் ஒன்றுதான். PVS-Studio நிலையான பகுப்பாய்வியில், இந்த செயல்பாடு பின்வருமாறு செயல்படுத்தப்படுகிறது.

நிலையான பகுப்பாய்வைப் பயன்படுத்துவதை விரைவாகத் தொடங்க, PVS-ஸ்டுடியோ பயனர்கள் எச்சரிக்கைகளை பெருமளவில் அடக்குவதற்கான பொறிமுறையைப் பயன்படுத்த பரிந்துரைக்கிறோம்.6]. பொதுவான யோசனை பின்வருமாறு. பயனர் பகுப்பாய்வியைத் தொடங்கினார் மற்றும் பல எச்சரிக்கைகளைப் பெற்றார். பல ஆண்டுகளாக வளர்ச்சியில் உள்ள ஒரு திட்டம் உயிருடன் இருப்பதால், வளர்ச்சியடைந்து பணம் சம்பாதிப்பதால், அறிக்கையில் முக்கியமான குறைபாடுகளைக் குறிக்கும் பல எச்சரிக்கைகள் இருக்காது. வேறு வார்த்தைகளில் கூறுவதானால், மிகவும் விலையுயர்ந்த முறைகள் அல்லது வாடிக்கையாளர்களின் கருத்துக்களுக்கு நன்றி, முக்கியமான பிழைகள் ஏற்கனவே ஒரு வழியில் சரி செய்யப்பட்டுள்ளன. அதன்படி, பகுப்பாய்வி தற்போது கண்டுபிடிக்கும் அனைத்தையும் தொழில்நுட்பக் கடனாகக் கருதலாம், இது உடனடியாக அகற்ற முயற்சிப்பது சாத்தியமற்றது.

இந்த எச்சரிக்கைகளை இப்போதைக்கு பொருத்தமற்றதாகக் கருதுமாறு நீங்கள் PVS-ஸ்டுடியோவிடம் கூறலாம் (தொழில்நுட்பக் கடனை பின்னர் சேமிக்கவும்), அது இனி அவற்றைக் காட்டாது. பகுப்பாய்வி ஒரு சிறப்பு கோப்பை உருவாக்குகிறது, அங்கு அது இன்னும் சுவாரஸ்யமான பிழைகள் பற்றிய தகவலைச் சேமிக்கிறது. இப்போது PVS-ஸ்டுடியோ புதிய அல்லது மாற்றப்பட்ட குறியீட்டிற்கு மட்டுமே எச்சரிக்கைகளை வழங்கும். மேலும், இவை அனைத்தும் புத்திசாலித்தனமாக செயல்படுத்தப்படுகின்றன. எடுத்துக்காட்டாக, மூலக் குறியீடு கோப்பின் தொடக்கத்தில் வெற்று வரி சேர்க்கப்பட்டால், உண்மையில், எதுவும் மாறவில்லை, தொடர்ந்து அமைதியாக இருக்கும் என்பதை பகுப்பாய்வி புரிந்துகொள்கிறார். இந்த மார்க்அப் கோப்பை பதிப்பு கட்டுப்பாட்டு அமைப்பில் வைக்கலாம். கோப்பு பெரியது, ஆனால் இது ஒரு பிரச்சனையல்ல, ஏனெனில் அதை அடிக்கடி சேமிப்பதில் எந்த அர்த்தமும் இல்லை.

இப்போது அனைத்து புரோகிராமர்களும் புதிய அல்லது மாற்றப்பட்ட குறியீடு தொடர்பான எச்சரிக்கைகளை மட்டுமே பார்ப்பார்கள். எனவே, அவர்கள் சொல்வது போல், அடுத்த நாளிலிருந்து நீங்கள் பகுப்பாய்வியைப் பயன்படுத்தத் தொடங்கலாம். நீங்கள் பின்னர் தொழில்நுட்ப கடனுக்குத் திரும்பலாம், மேலும் படிப்படியாக பிழைகளை சரிசெய்து பகுப்பாய்வியை உள்ளமைக்கலாம்.

எனவே, ஒரு பெரிய பழைய திட்டத்தில் பகுப்பாய்வியை செயல்படுத்துவதில் முதல் சிக்கல் தீர்க்கப்பட்டது. தொழில்நுட்ப கடனை என்ன செய்வது என்று இப்போது கண்டுபிடிப்போம்.

பிழை திருத்தங்கள் மற்றும் மறுசீரமைப்புகள்

பாரியளவில் அடக்கப்பட்ட பகுப்பாய்வி எச்சரிக்கைகளை பகுப்பாய்வு செய்ய சிறிது நேரம் ஒதுக்கி படிப்படியாக அவற்றைக் கையாள்வதே எளிமையான மற்றும் மிகவும் இயல்பான விஷயம். எங்காவது நீங்கள் குறியீட்டில் உள்ள பிழைகளை சரிசெய்ய வேண்டும், எங்காவது குறியீட்டில் சிக்கல் இல்லை என்று பகுப்பாய்விக்குச் சொல்ல நீங்கள் மறுபரிசீலனை செய்ய வேண்டும். எளிய உதாரணம்:

if (a = b)

பெரும்பாலான C++ கம்பைலர்கள் மற்றும் பகுப்பாய்விகள் அத்தகைய குறியீட்டைப் பற்றி புகார் செய்கின்றன, ஏனெனில் அவர்கள் உண்மையில் எழுத விரும்பியதற்கான அதிக நிகழ்தகவு உள்ளது. (a == b). ஆனால் ஒரு பேசப்படாத ஒப்பந்தம் உள்ளது, மேலும் இது பொதுவாக ஆவணத்தில் குறிப்பிடப்பட்டுள்ளது, கூடுதல் அடைப்புக்குறிகள் இருந்தால், புரோகிராமர் வேண்டுமென்றே அத்தகைய குறியீட்டை எழுதியதாகக் கருதப்படுகிறது, மேலும் சத்தியம் செய்ய வேண்டிய அவசியமில்லை. எடுத்துக்காட்டாக, நோயறிதலுக்கான பிவிஎஸ்-ஸ்டுடியோ ஆவணத்தில் V559 (CWE-481) பின்வரும் வரி சரியானதாகவும் பாதுகாப்பானதாகவும் கருதப்படும் என்று தெளிவாக எழுதப்பட்டுள்ளது:

if ((a = b))

மற்றொரு உதாரணம். இந்த C++ குறியீட்டில் அது மறந்துவிட்டதா? இடைவெளி அல்லது இல்லை?

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

PVS-Studio பகுப்பாய்வி இங்கே ஒரு எச்சரிக்கையை வெளியிடும் V796 (CWE-484). இது ஒரு பிழையாக இருக்காது, இந்தச் சந்தர்ப்பத்தில் நீங்கள் பண்புக்கூறைச் சேர்ப்பதன் மூலம் பாகுபடுத்திக்கு ஒரு குறிப்பைக் கொடுக்க வேண்டும். [[விழ]] அல்லது எடுத்துக்காட்டாக __பண்பு__((வீழ்ச்சி)):

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

இத்தகைய குறியீடு மாற்றங்கள் பிழையை சரி செய்யாது என்று கூறலாம். ஆம், இது உண்மைதான், ஆனால் இது இரண்டு பயனுள்ள விஷயங்களைச் செய்கிறது. முதலாவதாக, பகுப்பாய்வி அறிக்கை தவறான நேர்மறைகளிலிருந்து விடுபடுகிறது. இரண்டாவதாக, அதன் பராமரிப்பில் ஈடுபட்டுள்ள மக்களுக்கு குறியீடு மிகவும் புரிந்துகொள்ளக்கூடியதாகிறது. மேலும் இது மிகவும் முக்கியமானது! இதற்கு மட்டும், குறியீட்டை தெளிவாகவும் பராமரிக்கவும் எளிதாக்க சிறிய மறுசீரமைப்புகளை மேற்கொள்வது மதிப்பு. "பிரேக்" தேவையா இல்லையா என்பதை பகுப்பாய்வி புரிந்து கொள்ளாததால், சக புரோகிராமர்களுக்கும் அது தெளிவாக இருக்காது.

பிழை திருத்தங்கள் மற்றும் மறுசீரமைப்புகளுக்கு கூடுதலாக, நீங்கள் குறிப்பாக தவறான பகுப்பாய்வி எச்சரிக்கைகளை அடக்கலாம். சில பொருத்தமற்ற நோயறிதல்கள் முடக்கப்படலாம். உதாரணமாக, எச்சரிக்கைகள் அர்த்தமற்றவை என்று ஒருவர் நினைக்கிறார் V550 மிதவை/இரட்டை மதிப்புகளை ஒப்பிடுவது பற்றி. மேலும் சிலர் அவற்றை முக்கியமானவை மற்றும் ஆய்வுக்கு தகுதியானவை என வகைப்படுத்துகின்றனர்.7]. எந்த எச்சரிக்கைகள் பொருத்தமானதாகக் கருதப்படுகின்றன மற்றும் எது இல்லை என்பதை வளர்ச்சிக் குழு முடிவு செய்ய வேண்டும்.

தவறான எச்சரிக்கைகளை அடக்குவதற்கு வேறு வழிகள் உள்ளன. எடுத்துக்காட்டாக, மேக்ரோ மார்க்அப் முன்பு குறிப்பிடப்பட்டது. இவை அனைத்தும் ஆவணத்தில் இன்னும் விரிவாக விவரிக்கப்பட்டுள்ளன. மிக முக்கியமான விஷயம் என்னவென்றால், தவறான நேர்மறைகளுடன் வேலை செய்வதை நீங்கள் படிப்படியாகவும் முறையாகவும் அணுகினால், அவற்றில் எந்தத் தவறும் இல்லை என்பதைப் புரிந்துகொள்வது. பெரும்பாலான ஆர்வமற்ற எச்சரிக்கைகள் உள்ளமைவுக்குப் பிறகு மறைந்துவிடும், மேலும் கவனமாக ஆய்வு மற்றும் குறியீட்டில் சில மாற்றங்கள் தேவைப்படும் இடங்கள் மட்டுமே உள்ளன.

மேலும், ஏதேனும் சிரமங்கள் ஏற்பட்டால், நாங்கள் எப்போதும் எங்கள் வாடிக்கையாளர்களுக்கு PVS-ஸ்டுடியோவை அமைக்க உதவுகிறோம். மேலும், தவறான எச்சரிக்கைகளை நாமே அகற்றி பிழைகளை சரிசெய்த சந்தர்ப்பங்களும் இருந்தன.8]. ஒரு வேளை, நீட்டிக்கப்பட்ட ஒத்துழைப்புக்கான இந்த விருப்பமும் சாத்தியம் என்று குறிப்பிட முடிவு செய்தேன் :).

ராட்செட் முறை

நிலையான பகுப்பாய்வி எச்சரிக்கையை நீக்குவதன் மூலம் குறியீட்டின் தரத்தை படிப்படியாக மேம்படுத்த மற்றொரு சுவாரஸ்யமான அணுகுமுறை உள்ளது. இதன் முக்கிய அம்சம் என்னவென்றால், எச்சரிக்கைகளின் எண்ணிக்கை மட்டுமே குறையும்.

நிலையான பகுப்பாய்வி மூலம் வழங்கப்பட்ட எச்சரிக்கைகளின் எண்ணிக்கை பதிவு செய்யப்பட்டுள்ளது. இப்போது நீங்கள் செயல்பாடுகளின் எண்ணிக்கையை அதிகரிக்காத குறியீட்டை மட்டுமே உள்ளிடக்கூடிய வகையில் தரமான கேட் கட்டமைக்கப்பட்டுள்ளது. இதன் விளைவாக, அலாரங்களின் எண்ணிக்கையை படிப்படியாகக் குறைக்கும் செயல்முறை பகுப்பாய்வியை சரிசெய்தல் மற்றும் பிழைகளை சரிசெய்வதன் மூலம் தொடங்குகிறது.

ஒரு நபர் கொஞ்சம் ஏமாற்ற விரும்பினாலும், தனது புதிய குறியீட்டில் உள்ள எச்சரிக்கைகளை நீக்குவதன் மூலம் அல்ல, ஆனால் பழைய மூன்றாம் தரப்பு குறியீட்டை மேம்படுத்துவதன் மூலம் தர வாயிலைக் கடக்க முடிவு செய்தாலும், இது பயமாக இல்லை. எல்லாவற்றிற்கும் மேலாக, ராட்செட் ஒரு திசையில் சுழலும், படிப்படியாக குறைபாடுகளின் எண்ணிக்கை குறையும். ஒரு நபர் தனது சொந்த புதிய குறைபாடுகளை சரிசெய்ய விரும்பவில்லை என்றாலும், அவர் இன்னும் அண்டை குறியீட்டில் ஏதாவது மேம்படுத்த வேண்டும். ஒரு கட்டத்தில், எச்சரிக்கைகளின் எண்ணிக்கையைக் குறைப்பதற்கான எளிதான வழிகள் முடிவடைகின்றன, மேலும் உண்மையான பிழைகள் சரி செய்யப்படும் போது ஒரு புள்ளி வருகிறது.

இவான் பொனோமரேவின் மிகவும் சுவாரஸ்யமான கட்டுரையில் இந்த முறை இன்னும் விரிவாக விவரிக்கப்பட்டுள்ளது "பிழைகளைக் கண்டறிய அதைப் பயன்படுத்துவதை விட, செயல்பாட்டில் நிலையான பகுப்பாய்வைச் செயல்படுத்தவும்", குறியீட்டின் தரத்தை மேம்படுத்த ஆர்வமுள்ள எவருக்கும் படிக்க பரிந்துரைக்கிறேன்.

கட்டுரையின் ஆசிரியருக்கும் இந்த தலைப்பில் ஒரு அறிக்கை உள்ளது: "தொடர்ச்சியான நிலையான பகுப்பாய்வு".

முடிவுக்கு

இந்தக் கட்டுரைக்குப் பிறகு, வாசகர்கள் நிலையான பகுப்பாய்வுக் கருவிகளை ஏற்றுக்கொள்வார்கள் மற்றும் அவற்றை மேம்பாட்டுச் செயல்பாட்டில் செயல்படுத்த விரும்புவார்கள் என்று நம்புகிறேன். உங்களிடம் ஏதேனும் கேள்விகள் இருந்தால், நாங்கள் எப்போதும் தயாராக இருக்கிறோம் ஆலோசனை எங்கள் நிலையான பகுப்பாய்வி PVS-ஸ்டுடியோவின் பயனர்கள் மற்றும் அதை செயல்படுத்த உதவுங்கள்.

நிலையான பகுப்பாய்வு உண்மையில் வசதியாகவும் பயனுள்ளதாகவும் இருக்க முடியுமா என்பது பற்றி மற்ற பொதுவான சந்தேகங்கள் உள்ளன. "PVS-Studio நிலையான குறியீடு பகுப்பாய்வியை வளர்ச்சி செயல்பாட்டில் அறிமுகப்படுத்துவதற்கான காரணங்கள்" என்ற வெளியீட்டில் இந்த சந்தேகங்களில் பெரும்பாலானவற்றை அகற்ற முயற்சித்தேன்.9].

உங்கள் கவனத்திற்கு நன்றி மற்றும் வாருங்கள் скачать மற்றும் PVS-ஸ்டுடியோ பகுப்பாய்வியை முயற்சிக்கவும்.

கூடுதல் இணைப்புகள்

1. ஆண்ட்ரி கார்போவ். C மற்றும் C++ குறியீட்டிற்கு PVS-Studio பகுப்பாய்வி உருவாக்கும் சுவாரஸ்யமான எச்சரிக்கைகளை எப்படி விரைவாகப் பார்ப்பது?
2. விக்கிபீடியா. அரிசி தேற்றம்.
3. ஆண்ட்ரி கார்போவ், விக்டோரியா கனீவா. நிரல் மூலக் குறியீட்டின் நிலையான பகுப்பாய்வில் இயந்திர கற்றலைப் பயன்படுத்துதல்.
4. பிவிஎஸ்-ஸ்டுடியோ. ஆவணப்படுத்தல். கூடுதல் கண்டறியும் அமைப்புகள்.
5. ஆண்ட்ரி கார்போவ். EFL கோர் லைப்ரரிகளின் உதாரணத்தைப் பயன்படுத்தி PVS-ஸ்டுடியோ பகுப்பாய்வியின் சிறப்பியல்புகள், 10-15% தவறான நேர்மறைகள்.
6. பிவிஎஸ்-ஸ்டுடியோ. ஆவணப்படுத்தல். பகுப்பாய்வி செய்திகளை பெருமளவில் அடக்குதல்.
7. இவான் ஆண்ட்ரியாஷின். எக்ஸ்ரே எண்டோவாஸ்குலர் அறுவை சிகிச்சையின் கல்வி சிமுலேட்டரின் எங்கள் திட்டத்தில் நிலையான பகுப்பாய்வை நாங்கள் எவ்வாறு சோதித்தோம் என்பது பற்றி.
8. பாவெல் எரெமீவ், ஸ்வயடோஸ்லாவ் ரஸ்மிஸ்லோவ். பிவிஎஸ்-ஸ்டுடியோ குழு அன்ரியல் என்ஜின் குறியீட்டை எவ்வாறு மேம்படுத்தியது.
9. ஆண்ட்ரி கார்போவ். வளர்ச்சி செயல்பாட்டில் நிலையான குறியீடு பகுப்பாய்வி PVS-ஸ்டுடியோவை அறிமுகப்படுத்துவதற்கான காரணங்கள்.

ஆங்கிலம் பேசும் பார்வையாளர்களுடன் இந்தக் கட்டுரையைப் பகிர விரும்பினால், மொழிபெயர்ப்பு இணைப்பைப் பயன்படுத்தவும்: Andrey Karpov. ஒரு மரபு திட்டத்தில் நிலையான குறியீடு பகுப்பாய்வியை எவ்வாறு அறிமுகப்படுத்துவது மற்றும் குழுவை ஊக்கப்படுத்தாமல் இருக்க வேண்டும்.

ஆதாரம்: www.habr.com