Docotic.Pdf: एक परिपक्व परियोजना में पीवीएस-स्टूडियो क्या समस्याओं का पता लगाता है?

हमारे लिए गुणवत्ता महत्वपूर्ण है। और हमने पीवीएस-स्टूडियो के बारे में सुना। इसने डॉकॉटिक.एफडी की जांच करने और यह पता लगाने की इच्छा पैदा की कि और क्या सुधार किया जा सकता है।

Docotic.Pdf पीडीएफ फाइलों के साथ काम करने के लिए एक सामान्य प्रयोजन पुस्तकालय है। यह C # में लिखा गया है, कोई असुरक्षित कोड नहीं है। .NET रनटाइम के अलावा कोई बाहरी निर्भरता नहीं है। यह .NET 4+ और .NET मानक 2+ के तहत दोनों काम करता है।

पुस्तकालय का विकास 10 वर्षों से थोड़ा अधिक समय से चल रहा है और इसमें बिना किसी परीक्षण, उदाहरण और अन्य बातों को ध्यान में रखे बिना कोड की 110 हजार लाइनें हैं। स्थैतिक विश्लेषण के लिए, हम लगातार कोड विश्लेषण और स्टाइलकॉप का उपयोग करते हैं। कई हजार स्वचालित परीक्षण हमें प्रतिगमन से बचाते हैं। विभिन्न देशों और विभिन्न उद्योगों के हमारे ग्राहक पुस्तकालय की गुणवत्ता पर भरोसा करते हैं।

पीवीएस-स्टूडियो क्या समस्याओं का पता लगाएगा?

स्थापना और पहली छाप

मैंने पीवीएस-स्टूडियो वेबसाइट से परीक्षण संस्करण डाउनलोड किया। संस्थापक के छोटे आकार से सुखद आश्चर्य हुआ। डिफ़ॉल्ट सेटिंग्स के साथ स्थापित: विश्लेषण इंजन, एक अलग पीवीएस-स्टूडियो वातावरण, विज़ुअल स्टूडियो 2017 में एकीकरण।

स्थापना के बाद, कुछ भी शुरू नहीं हुआ, और एक ही आइकन वाले दो शॉर्टकट स्टार्ट मेनू में जोड़े गए: स्टैंडअलोन और पीवीएस-स्टूडियो। एक पल के लिए मुझे लगा कि क्या शुरू करना है। स्टैंडअलोन लॉन्च किया और इंटरफ़ेस द्वारा अप्रिय रूप से आश्चर्यचकित किया गया। मेरे विंडोज के लिए निर्धारित 200% पैमाना कुटिल तरीके से समर्थित है। पाठ का हिस्सा बहुत छोटा है, पाठ का हिस्सा इसके लिए दिए गए स्थान में फिट नहीं होता है। नाम, यूनिकॉर्न और क्रियाएँ सूची किसी भी विंडो आकार के लिए क्रॉप की जाती हैं। फुल स्क्रीन के साथ भी।



खैर, ठीक है, मैंने अपनी परियोजना फ़ाइल खोलने का फैसला किया। अचानक, फ़ाइल मेनू को ऐसा अवसर नहीं मिला। वहाँ मुझे केवल व्यक्तिगत फाइलें खोलने की पेशकश की गई थी। धन्यवाद, मैंने सोचा, मैं एक और विकल्प की कोशिश करूँगा। पीवीएस-स्टूडियो लॉन्च किया - उन्होंने मुझे धुंधली पाठ वाली एक खिड़की दिखाई। 200% के पैमाने ने फिर से खुद को महसूस किया। पाठ ने बताया: थ्री क्राउन में मेरे लिए देखें, विजुअल स्टूडियो में पीवीएस-स्टूडियो मेनू देखें। ठीक है, स्टूडियो खोला।

खोला हुआ हल। वास्तव में, एक पीवीएस-स्टूडियो मेनू है, और इसमें "वर्तमान परियोजना" की जांच करने की क्षमता है। उन्होंने उस परियोजना को बनाया जिसे मुझे वर्तमान की आवश्यकता है और एक चेक लॉन्च किया। विश्लेषण के परिणामों के साथ एक विंडो स्टूडियो में पॉप अप हुई। स्कैन की प्रगति के साथ एक खिड़की पृष्ठभूमि में दिखाई दी, लेकिन मुझे तुरंत नहीं मिला। पहले तो ऐसा एहसास हुआ कि चेक शुरू नहीं हुआ या तुरंत खत्म नहीं हुआ।

पहले चेक रिजल्ट

विश्लेषक ने सभी 1253 प्रोजेक्ट फाइलों को लगभग 9 मिनट और 30 सेकंड में चेक किया। चेक के अंत तक, फ़ाइल काउंटर शुरुआत में उतनी तेजी से नहीं बदला। शायद स्कैन की गई फ़ाइलों की संख्या पर स्कैन अवधि की कुछ गैर-निर्भरता है।

परिणाम विंडो में 81 उच्च, 109 मध्यम और 175 कम चेतावनियों की जानकारी दिखाई दी। यदि आप आवृत्ति की गणना करते हैं, तो आपको 0.06 उच्च चेतावनी / फ़ाइल, 0.09 मध्यम चेतावनी / फ़ाइल और 0.14 कम चेतावनी / फ़ाइल मिलती है। या
कोड के प्रति हजार लाइनों में 0.74 उच्च चेतावनी, कोड के प्रति हजार लाइनों में 0.99 मध्यम चेतावनी और कोड के प्रति हजार लाइनों में 1.59 कम चेतावनी।

यहां इस लेख में , यह इंगित किया गया है कि क्रूज़कंट्रोल.नेट में, कोड की 256 हजार पंक्तियों के साथ, विश्लेषक ने 15 उच्च, 151 मध्यम और 32 कम चेतावनी पाई।

यह पता चला है कि Docotic.Pdf के प्रतिशत के संदर्भ में प्रत्येक समूह में अधिक चेतावनी जारी की गई थी।

क्या पाया है?

मैंने इस स्तर पर कम चेतावनियों को नजरअंदाज करने का फैसला किया।

मैंने कोड कॉलम द्वारा चेतावनी को छांटा और यह पता चला कि आवृत्ति के लिए पूर्ण रिकॉर्ड धारक V3022 थे "अभिव्यक्ति हमेशा सही / गलत होती है" और V3063 "सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सही / गलत होता है यदि उसका मूल्यांकन किया जाता है"। मेरी राय में, वे एक बात के बारे में हैं। कुल में, ये दो चेतावनी 190 मामलों में से 92 देते हैं। सापेक्ष आवृत्ति = 48%।

हाई और मीडियम में विभाजित होने का तर्क पूरी तरह से स्पष्ट नहीं है। मैं V3072 की उम्मीद कर रहा था " IDSperia सदस्यों वाले 'A' वर्ग खुद ही IDisposable को लागू नहीं करता है" और V3073 "सभी IDisposable सदस्य ठीक से निपट नहीं पाते हैं। उदाहरण के लिए, उच्च समूह में 'A' वर्ग का निपटान करते समय 'Dispose' को कॉल करें। लेकिन यह स्वाद है, बिल्कुल।

आश्चर्य है कि V3095 “ऑब्जेक्ट का उपयोग करने से पहले इसे शून्य के खिलाफ सत्यापित किया गया था। चेक लाइनें: N1, N2 ”को दो बार उच्च और एक बार माध्यम के रूप में चिह्नित किया गया है। बग?

भरोसा करें लेकिन सत्यापन करें

चेतावनियाँ कितनी उचित हैं, यह जाँचने का समय है। क्या कोई वास्तविक त्रुटियां पाई गई हैं? क्या कोई गलत चेतावनी है?

मैंने नीचे समूहों में पाई गई चेतावनियों को विभाजित किया।

महत्वपूर्ण चेतावनी

उनके सुधार ने स्थिरता बढ़ाई, मेमोरी लीक के साथ समस्याओं को हल किया, आदि। वास्तविक गलतियाँ / खामियाँ।

इनमें से 16 जारी किए गए, जो सभी चेतावनियों का लगभग 8% है।

मैं कुछ उदाहरण दूंगा।

V3019 "संभवतः एक गलत चर की तुलना 'प्रकार' कीवर्ड के उपयोग से टाइप रूपांतरण के बाद की जाती है। चर 'रंग', 'अनुक्रमित' »की जाँच करें

public override bool IsCompatible(ColorImpl color) { IndexedColorImpl indexed = color as IndexedColorImpl; if (color == null) return false; return indexed.ColorSpace.Equals(this); } 

जैसा कि आप देख सकते हैं, अनुक्रमित के बजाय, चर रंग की तुलना नल के साथ की जाती है। यह गलत है और इससे एनआरई को नुकसान हो सकता है।

V3080 “संभावित अशांति । 'Cstr_index.tile_index' का निरीक्षण करने पर विचार करें »

वर्णन करने के लिए एक छोटा सा टुकड़ा:

 if (cstr_index.tile_index == null) { if (cstr_index.tile_index[0].tp_index == null) { // .. } } 

जाहिर है, पहली शर्त निहित है! = अशक्त। वर्तमान रूप में, कोड प्रत्येक कॉल के साथ एनआरई को फेंक देगा।

V3083 "ऑनप्रोग्रेड ', NullReferenceException घटना का असुरक्षित आह्वान संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। ”

 public void Updated() { if (OnProgress != null) OnProgress(this, new EventArgs()); } 

एक चेतावनी ने एक संभावित अपवाद को ठीक करने में मदद की। यह क्यों उत्पन्न हो सकता है? Stackoverflow की एक अच्छी व्याख्या है ।

V3106 “संभवतः सूचकांक सीमा से बाहर है। '0' सूचकांक 'v' बाउंड से परे इंगित कर रहा है »

 var result = new List<FontStringPair>(); for (int i = 0; i < text.Length; ++i) { var v = new List<FontStringPair>(); createPairs(text[i].ToString(CultureInfo.InvariantCulture)); result.Add(v[0]); } 

त्रुटि यह है कि createPairs का परिणाम नजरअंदाज कर दिया जाता है, और इसके बजाय एक खाली सूची तक पहुँचा जाता है। जाहिर है, शुरू में createPairs ने एक पैरामीटर के रूप में सूची को स्वीकार किया था, लेकिन विधि को बदलने की प्रक्रिया में एक त्रुटि हुई थी।

V3117 'कंस्ट्रक्टर पैरामीटर' वैलिडेट टाइप 'का उपयोग नहीं किया गया है

इसी के समान कोड के लिए चेतावनी जारी की गई थी

 public SomeClass(IDocument document, bool validateType = true) : base(document, true) { m_provider = document; } 

स्वयं चेतावनी महत्वपूर्ण नहीं लगती। लेकिन यह समस्या पहली नज़र में लगने से ज्यादा गंभीर है। वैकल्पिक मान्यप्रकार पैरामीटर को जोड़ने की प्रक्रिया में, वे बेस क्लास कंस्ट्रक्टर को कॉल को ठीक करना भूल गए।

V3127 „दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो और 'रेंज' वैरिएबल का उपयोग 'डोमेन' के बजाय किया जाना चाहिए।

 private void fillTransferFunction(PdfStreamImpl function) { // .. PdfArrayImpl domain = new PdfArrayImpl(); domain.AddReal(0); domain.AddReal(1); function.Add(Field.Domain, domain); PdfArrayImpl range = new PdfArrayImpl(); range.AddReal(0); range.AddReal(1); function.Add(Field.Range, domain); // .... } 

यदि कोड के हिस्से थोड़े अलग हैं तो शायद चेतावनी जारी नहीं की जाएगी। लेकिन इस मामले में, कॉपी-पेस्ट का उपयोग करते समय एक त्रुटि पाई गई थी।

सैद्धांतिक / औपचारिक चेतावनी

वे या तो सही हैं, लेकिन उनका सुधार किसी विशिष्ट त्रुटि को ठीक नहीं करता है और कोड की पठनीयता को प्रभावित नहीं करता है। या वे उन जगहों की ओर इशारा करते हैं जहां कोई गलती हो सकती है, लेकिन यह मौजूद नहीं है। उदाहरण के लिए, मापदंडों का क्रम जानबूझकर बदला जाता है। ऐसी चेतावनियों के लिए, आपको कार्यक्रम में कुछ भी बदलने की आवश्यकता नहीं है।

इनमें से 57 जारी किए गए, जो सभी चेतावनियों का लगभग 30% है। मैं उन मामलों के लिए उदाहरण दूंगा जो ध्यान देने योग्य हैं।

V3013 odd यह विचित्र है कि 'आरंभ' समारोह का शरीर 'एंडटेक्स्ट' फ़ंक्शन (166, लाइन 171) के शरीर के समतुल्य है।

 public override void BeginText() { m_state.ResetTextParameters(); } public override void EndText() { m_state.ResetTextParameters(); } 

दोनों शरीर के कार्य वास्तव में समान हैं। लेकिन यह सही है। और क्या यह वास्तव में बहुत अजीब है अगर एक पंक्ति से कार्यों के शरीर मेल खाते हैं?

V3106 negative संभावित नकारात्मक सूचकांक मूल्य। 'C1' इंडेक्स का मान -1 तक पहुंच सकता है

 freq[256] = 1; // .... c1 = -1; v = 1000000000L; for (i = 0; i <= 256; i++) { if (freq[i] != 0 && freq[i] <= v) { v = freq[i]; c1 = i; } } // .... freq[c1] += freq[c2]; 

मैं सहमत हूं, मैंने नॉट-क्लियर एल्गोरिदम का एक टुकड़ा दिया। लेकिन, मेरी राय में, इस मामले में, विश्लेषक व्यर्थ में चिंता करता है।

V3107 बाईं ओर और यौगिक असाइनमेंट के दाईं ओर "समान अभिव्यक्ति"

चेतावनी काफी सामान्य कोड के कारण होती है:

 neighsum += neighsum; 

हां, इसे गुणा के माध्यम से फिर से लिखा जा सकता है। लेकिन कोई गलती नहीं है।

V3109 l ऑपरेटर के दोनों ओर 'l_cblk.data_current_size' उप-अभिव्यक्ति मौजूद है। अभिव्यक्ति गलत है या इसे सरल बनाया जा सकता है। ”

 /* Check possible overflow on size */ if ((l_cblk.data_current_size + l_seg.newlen) < l_cblk.data_current_size) { // ... } 

कोड में टिप्पणी इरादे को स्पष्ट करती है। फिर से गलत अलार्म।

न्यायोचित चेतावनी

उनके सुधार ने कोड की पठनीयता को सकारात्मक रूप से प्रभावित किया। यही है, इसने अनावश्यक परिस्थितियों, जांचों आदि को कम कर दिया। कोड कैसे काम करता है इस पर प्रभाव स्पष्ट नहीं है।

इनमें से, 103 जारी किए गए, जो सभी चेतावनियों का लगभग 54% है।

V3008 l 'l_mct_deco_data' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है ”

 if (m_nb_mct_records == m_nb_max_mct_records) { ResizeMctRecords(); l_mct_deco_data = (OPJ_INT32)m_nb_mct_records; } l_mct_deco_data = (OPJ_INT32)m_nb_mct_records; 

अधिकार विश्लेषक: यदि आवश्यक नहीं है तो अंदर असाइनमेंट।

V3009 300 यह अजीब है कि यह विधि हमेशा एक और समान मान लौटाती है ”

 private static bool opj_dwt_decode_tile(opj_tcd_tilecomp_t tilec, OPJ_UINT32 numres) { if (numres == 1U) return true; // ... return true; } 

विश्लेषक की सलाह पर, विधि बदल दी गई है और अधिक कुछ नहीं लौटाता है।

V3022 "अभिव्यक्ति '! जोड़ें' हमेशा सच है"

 private void addToFields(PdfDictionaryImpl controlDict, bool add) { // ... if (add) { // .. return; } if (!add) { // ... } // ... } 

वास्तव में, दूसरे में कोई मतलब नहीं है अगर। शर्त हमेशा सच होगी।

V3029 "एक दूसरे के साथ स्थित 'यदि' के सशर्त अभिव्यक्ति समान हैं"

 if (stroke) extGState.OpacityStroke = opacity; if (stroke) state.AddReal(Field.CA, opacity); 

यह स्पष्ट नहीं है कि इस तरह के कोड की उत्पत्ति कैसे हुई। लेकिन अब हमने इसे ठीक कर दिया।

V3031 check एक अत्यधिक जांच को सरल बनाया जा सकता है। '' '' ऑपरेटर विपरीत भावों से घिरा हुआ है ”

यह एक बुरा सपना है:

 if (!(cp.m_enc.m_tp_on != 0 && ((!opj_codec_t.OPJ_IS_CINEMA(cp.rsiz) && (t2_mode == J2K_T2_MODE.FINAL_PASS)) || opj_codec_t.OPJ_IS_CINEMA(cp.rsiz)))) { // ... } 

परिवर्तनों के बाद यह बहुत बेहतर हो गया

 if (!(cp.m_enc.m_tp_on != 0 && (opj_codec_t.OPJ_IS_CINEMA(cp.rsiz) || t2_mode == J2K_T2_MODE.FINAL_PASS))) { // ... } 

V3063 "सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सही होता है यदि उसका मूल्यांकन किया जाता है: x! = Null"
V3022 "अभिव्यक्ति 'x! = अशक्त' हमेशा सत्य है"

यहां मैंने चेतावनियों को शामिल किया है कि अशक्तता की जांच करने का कोई मतलब नहीं है। क्या ऐसा करना सही है या नहीं यह विवादास्पद प्रश्न है। नीचे मैंने मुद्दे का सार वर्णित किया है।

आधारहीन चेतावनी

झूठी सकारात्मकता किसी विशेष परीक्षण या किसी प्रकार के विश्लेषक दोष के कार्यान्वयन में त्रुटियों के कारण।

इनमें से 14 जारी किए गए, जो सभी चेतावनियों का लगभग 7% है।

V3081 “I’ काउंटर का उपयोग नेस्टेड लूप के अंदर नहीं किया जाता है। 'जे' काउंटर के उपयोग के निरीक्षण पर विचार करें

कोड का थोड़ा सरलीकृत संस्करण जिसके लिए यह चेतावनी जारी की गई थी:

 for (uint i = 0; i < initialGlyphsCount - 1; ++i) { for (int j = 0; j < initialGlyphsCount - i - 1; ++j) { // ... } } 

जाहिर है, मैं एक नेस्टेड लूप में उपयोग किया जाता है।

V3125 was ऑब्जेक्ट को शून्य के खिलाफ सत्यापित होने के बाद उपयोग किया गया था ”

कोड जिसके लिए चेतावनी जारी की गई है:

 private static int Compare_SecondGreater(cmapEncodingRecord er1, cmapEncodingRecord er2) { if (er1 == er2) return 0; if (er1 != null && er2 == null) return 1; if (er1 == null && er2 != null) return -1; return er1.CompareTo(er2); } 

er1 को null नहीं किया जा सकता है जब तुलना () कहा जाता है।

एक और कोड जिसके लिए यह चेतावनी जारी की गई है:

 private static void realloc(ref int[][] table, int newSize) { int[][] newTable = new int[newSize][]; int existingSize = 0; if (table != null) existingSize = table.Length; for (int i = 0; i < existingSize; i++) newTable[i] = table[i]; for (int i = existingSize; i < newSize; i++) newTable[i] = new int[4]; table = newTable; } 

तालिका लूप में शून्य नहीं हो सकती है।

V3134 by शिफ्ट द्वारा [32..255] बिट्स 'UInt32' प्रकार की अभिव्यक्ति के आकार से अधिक है (uint) 1 ''

कोड का एक टुकड़ा जिसके लिए यह चेतावनी जारी की गई है:

 byte bitPos = (byte)(numBits & 0x1F); uint mask = (uint)1 << bitPos; 

यह देखा जा सकता है कि बिटपोस का मूल्य सीमा [0..31] से हो सकता है, लेकिन विश्लेषक का मानना ​​है कि इसका रेंज [0..31] से मूल्य हो सकता है, जो गलत है।

मैं अन्य समान मामलों को नहीं दूंगा, क्योंकि वे समान हैं।

कुछ जाँचों पर अतिरिक्त विचार

मुझे यह चेतावनी देना अवांछनीय लगा कि 'x! = Null' हमेशा उन मामलों में सही होता है जहाँ x किसी विधि को कॉल करने का परिणाम है। एक उदाहरण:

 private X GetX(int y) { if (y > 0) return new X(...); if (y == 0) return new X(...); throw new ArgumentOutOfRangeException(nameof(x)); } private Method() { // ... X x = GetX(..); if (x != null) { // ... } } 

हां, औपचारिक रूप से, विश्लेषक सही है: x हमेशा शून्य नहीं होगा, क्योंकि गेटएक्स या तो एक पूर्ण उदाहरण वापस कर देगा या एक अपवाद फेंक देगा। लेकिन क्या नाल द्वारा चेक को हटाने से कोड में सुधार होगा? क्या होगा अगर गेटएक्स बाद में बदल जाए? क्या विधि को गेटएक्स कार्यान्वयन को जानना है?

टीम के अंदर, राय विभाजित थे। यह सुझाव दिया गया है कि वर्तमान पद्धति का एक अनुबंध है जिसके द्वारा इसे वापस नहीं लौटना चाहिए। और हर कॉल के साथ "भविष्य के लिए" अनावश्यक कोड लिखने का कोई मतलब नहीं है। और यदि अनुबंध बदलता है, तो कॉलिंग कोड को अपडेट किया जाना चाहिए।

इस राय के समर्थन में, निम्नलिखित निर्णय किया गया था: अशक्त के लिए जाँच हर कॉल को कोशिश / पकड़ में लपेटने की तरह है यदि भविष्य में विधि अपवादों को फेंकना शुरू कर देती है।

परिणामस्वरूप, YAGNI सिद्धांत के अनुसार, उन्होंने चेक पर पकड़ नहीं रखने का फैसला किया और उन्हें हटा दिया। सभी चेतावनियाँ सैद्धांतिक / औपचारिक से औचित्य में स्थानांतरित कर दी गईं।

मुझे टिप्पणियों में आपकी राय पढ़ने में खुशी होगी।

निष्कर्ष

स्थैतिक विश्लेषण एक अच्छी बात है। पीवीएस-स्टूडियो आपको वास्तविक त्रुटियों को खोजने की अनुमति देता है।

हां, अनुचित / गलत चेतावनी हैं। लेकिन फिर भी पीवीएस-स्टूडियो को एक परियोजना में वास्तविक त्रुटियां मिलीं जो पहले से ही कोड विश्लेषण का उपयोग करती हैं। हमारे उत्पाद को परीक्षणों द्वारा काफी अच्छी तरह से कवर किया गया है, यह एक तरह से या हमारे ग्राहकों द्वारा परीक्षण किया गया है, लेकिन रोबोट इसे बेहतर स्थैतिक विश्लेषण करते हैं फिर भी फायदेमंद है।

अंत में, कुछ आंकड़े।

शीर्ष 3 अनुचित चेतावनी

V3081 inside नेस्टेड लूप के अंदर 'X' काउंटर का उपयोग नहीं किया जाता है। 'Y' काउंटर के उपयोग के निरीक्षण पर विचार करें
1 में से 1 अनुचित पाया गया

V3125 was ऑब्जेक्ट का उपयोग नल के खिलाफ सत्यापित होने के बाद किया गया था। चेक लाइनें: N1, N2 "
10 में से 9 को निराधार घोषित किया गया है

V3134 "N बिट द्वारा शिफ्ट प्रकार के आकार से अधिक है"
5 में से 4 निराधार पाए गए

शीर्ष 3 महत्वपूर्ण चेतावनियाँ

V3083 “घटना का असुरक्षित आह्वान, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर के लिए घटना को असाइन करने पर विचार करें "
5 में से 5 को महत्वपूर्ण माना गया।

V3020 “लूप के भीतर बिना शर्त„ ब्रेक / जारी / रिटर्न / गेटो ’
V3080 "संभावित अशांति "
2 में से 2 को महत्वपूर्ण माना गया।

V3019 3 यह संभव है कि एक गलत वैरिएबल की तुलना नल के साथ रूपांतरण के बाद 'कीवर्ड' के रूप में करके की जाती है।
V3127 „दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'Y' के बजाय 'X' वेरिएबल का उपयोग किया जाना चाहिए।
1 में से 1 को महत्वपूर्ण माना गया।