WinForms: त्रुटियां, होम्स

हम Microsoft प्रोजेक्ट्स में त्रुटियों की खोज करना पसंद करते हैं। क्यों? यह सरल है: उनकी परियोजनाएं आमतौर पर जांचना आसान है (आप विज़ुअल स्टूडियो वातावरण में काम कर सकते हैं जिसके लिए पीवीएस-स्टूडियो में एक सुविधाजनक प्लगइन है) और उनमें कुछ त्रुटियां हैं। यही कारण है कि सामान्य कार्य एल्गोरिथ्म इस प्रकार है: एमएस से एक ओपन सोर्स प्रोजेक्ट ढूंढें और डाउनलोड करें; इसे जांचें; दिलचस्प त्रुटियों का चयन करें; सुनिश्चित करें कि उनमें से कुछ हैं; डेवलपर्स की प्रशंसा करने के लिए भूल के बिना एक लेख लिखें। वाह! विन-विन-विन: इसमें थोड़ा समय लगा, ब्लॉग में नई सामग्री देखकर बॉस खुश हैं, और कर्म ठीक है। लेकिन इस बार "कुछ गलत हो गया"। आइए देखें कि हमने विंडोज फॉर्म के स्रोत कोड में क्या पाया है और क्या हमें इस बार Microsoft से अत्यधिक बोलना चाहिए।

परिचय

दिसंबर 2018 की शुरुआत में, Microsoft ने .NET कोर 3 पूर्वावलोकन 1 की रिलीज की घोषणा की। थोड़ी देर पहले (लगभग अक्टूबर के मध्य में), GitHub ने विंडोज फॉर्मेट्स के स्रोतों का सक्रिय रूप से खुलासा करना शुरू कर दिया - .NET कोर यूआई प्लेटफॉर्म विंडोज डेस्कटॉप एप्लिकेशन बनाने के लिए । आप यहां कमिटमेंट के आंकड़े देख सकते हैं। अब कोई भी रिव्यू के लिए WinForms सोर्स कोड डाउनलोड कर सकता है।

मैंने पीवीएस-स्टूडियो के साथ वहाँ त्रुटियों की खोज करने के लिए स्रोत भी डाउनलोड किए। जाँच में कोई कठिनाई नहीं हुई। हमें ज़रूरत थी: विज़ुअल स्टूडियो 2019, .NET कोर 3.0 एसडीके पूर्वावलोकन, पीवीएस-स्टूडियो। और यहां हमारे पास विश्लेषक की चेतावनी का लॉग है।

पीवीएस-स्टूडियो रिपोर्ट प्राप्त करने के बाद, मैं आमतौर पर आरोही क्रम में नैदानिक ​​संख्याओं द्वारा इसे सॉर्ट करता हूं (विजुअल स्टूडियो वातावरण में पीवीएस-स्टूडियो संदेश लॉग के साथ विंडो में सूची को सॉर्ट करने और फ़िल्टर करने के विभिन्न विकल्प हैं)। यह आपको समान त्रुटियों के समूहों के साथ काम करने की अनुमति देता है, जो स्रोत कोड विश्लेषण को सरल करता है। मैं सूची में एक "स्टार" के साथ दिलचस्प त्रुटियों को चिह्नित करता हूं और उसके बाद ही पूरे लॉग का विश्लेषण करने के बाद, मैं कोड के टुकड़े लिखता हूं और उनका वर्णन करता हूं। चूंकि आमतौर पर कुछ त्रुटियां होती हैं, इसलिए मैं उन्हें लेख की शुरुआत और अंत में सबसे दिलचस्प जगह देने की कोशिश कर रहा हूं। लेकिन इस बार यह बहुत सारी त्रुटियों के रूप में निकला (एह, साज़िश को लंबे समय तक नहीं बचाया गया है) और मैं उन्हें निदान की संख्या के क्रम में उद्धृत करूंगा।

हमने क्या पाया? 1633 सीएस फाइलों में 833 उच्च और मध्यम चेतावनियाँ (क्रमशः 249 और 584,) कोड की 540,000 लाइनों के लिए जारी की गईं (खाली नहीं हैं)। और हां, पारंपरिक रूप से मैंने परीक्षणों की जांच नहीं की और कम चेतावनियों पर विचार नहीं किया (उनमें से 215 थे)। मेरी पिछली टिप्पणियों के अनुसार, एमएस परियोजना के लिए चेतावनी बहुत अधिक हैं। लेकिन सभी चेतावनी त्रुटियां नहीं हैं।

इस परियोजना के लिए झूठे अलार्म की संख्या लगभग 30% थी। लगभग 20% मामलों में, मैं सिर्फ एक सटीक निष्कर्ष नहीं निकाल सका कि क्या यह एक त्रुटि थी या नहीं क्योंकि मैं कोड से अच्छी तरह परिचित नहीं था। और कम से कम 20% त्रुटियों को मैंने "मानव कारक" के रूप में लिखा जा सकता है: जल्दबाजी, थकान, आदि। वैसे, विपरीत प्रभाव भी संभव है: कुछ समान-प्रकार के ट्रिगर, जिनकी संख्या 70-80 तक पहुंच सकती है, मैंने "अगला लेकिन एक" देखा, जो कभी-कभी उन त्रुटियों की संख्या बढ़ा सकता है जो मुझे लगता था कि वास्तविक थे।

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

इसलिए, मैं जिन त्रुटियों को खोजने में कामयाब रहा, उनकी संख्या लगभग 240 थी, जो दिए गए आँकड़ों की सीमा के भीतर है। फिर से, मेरी राय में, यह एमएस प्रोजेक्ट के लिए सबसे उत्कृष्ट परिणाम नहीं है (हालांकि यह प्रति 1000 कोड लाइनों में केवल 0.44 त्रुटियां करेगा) और शायद WinForms कोड में भी अधिक वास्तविक त्रुटियां हैं। मैं लेख के अंत में कारणों पर विचार करने का सुझाव देता हूं और अब सबसे दिलचस्प त्रुटियों को देखते हैं।

त्रुटियाँ

PVS-Studio: V3003 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। चेक लाइन: 213, 224. ButtonStandardAdapter.cs 213

void PaintWorker(PaintEventArgs e, bool up, CheckState state) { up = up && state == CheckState.Unchecked; .... if (up & IsHighContrastHighlighted()) { .... } else if (up & IsHighContrastHighlighted()) { .... } else { .... } .... } 

यदि और यदि ब्लॉक समान स्थिति की जांच करते हैं। यह कॉपी-पेस्ट जैसा दिखता है। क्या यह एक त्रुटि है? यदि आप IsHighContrastHighlighted विधि की घोषणा को देखते हैं , तो आपको इस पर संदेह हो सकता है:

 protected bool IsHighContrastHighlighted() { return SystemInformation.HighContrast && Application.RenderWithVisualStyles && (Control.Focused || Control.MouseIsOver || (Control.IsDefault && Control.Enabled)); } 

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

PVS-Studio: V3004 'तत्कालीन' कथन 'और' कथन के बराबर है। RichTextBox.cs 1018

 public int SelectionCharOffset { get { int selCharOffset = 0; .... NativeMethods.CHARFORMATA cf = GetCharFormat(true); // if the effects member contains valid info if ((cf.dwMask & RichTextBoxConstants.CFM_OFFSET) != 0) { selCharOffset = cf.yOffset; // <= } else { // The selection contains characters of different offsets, // so we just return the offset of the first character. selCharOffset = cf.yOffset; // <= } .... } .... } 

और यहाँ निश्चित रूप से एक कॉपी-पेस्ट त्रुटि है। शर्त के बावजूद, selCharOffset वैरिएबल को हमेशा समान मूल्य मिलेगा।

WinForms कोड में ऐसी दो और त्रुटियां हैं:

• V3004 'तत्कालीन' कथन 'और' कथन के बराबर है। स्प्लिटकोन्टर। एससी 1700
• V3004 'तत्कालीन' कथन 'और' कथन के बराबर है। ToolstripProfessionalRenderer.cs 371

PVS-Studio: V3008 चर को क्रमिक रूप से दो बार दिया जाता है। शायद यह एक गलती है। लाइनों की जाँच करें: 681, 680. ProfessionalColorTable.cs 681

 internal void InitSystemColors(ref Dictionary<KnownColors, Color> rgbTable) { .... rgbTable[ProfessionalColorTable.KnownColors.msocbvcrCBBdrOuterDocked] = buttonFace; rgbTable[ProfessionalColorTable.KnownColors.msocbvcrCBBdrOuterDocked] = buttonShadow; .... } 

विधि rgbTable शब्दकोश भरता है। विश्लेषक ने एक कोड के टुकड़े को इंगित किया जहां अनुक्रम में एक ही कुंजी पर दो बार अलग-अलग मान लिखे गए हैं। चीजें ठीक होंगी लेकिन इस पद्धति में अभी भी ऐसे 16 टुकड़े हैं। यह अब एक-की-एक त्रुटि की तरह नहीं दिखता है। लेकिन वे ऐसा क्यों करते हैं यह मेरे लिए एक रहस्य बना हुआ है। मुझे ऑटोजेनरेटेड कोड के कोई संकेत नहीं मिले। यह संपादक में इस तरह दिखता है:

मैं आपको सूची में पहले दस चेतावनियाँ दूंगा:

1. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच लाइनें: 785, 784। ProfessionalColorTable.cs 785
2. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच लाइनें: 787, 786। ProfessionalColorTable.cs 787
3. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच लाइनें: 789, 788
4. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइन्स: 791, 790. प्रोफेशनलकॉन्फ़र्टेबल .cs 791
5. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइन्स: 797, 796. प्रोफेशनलकॉन्स्टेबल .cs 797
6. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइनें: 799, 798. प्रोफेशनलकॉन्स्टेबल .cs 799
7. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। चेक लाइन्स: 807, 806. प्रोफेशनल क्योरबल .cs 807
8. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच लाइनें: 815, 814। ProfessionalColorTable.cs 815
9. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच लाइनें: 817, 816
10. V3008 चर को क्रमिक रूप से दो बार मान दिया जाता है। शायद यह एक गलती है। जाँच रेखाएँ: 823, 822. प्रोफेशनलकॉन्स्टेबल .cs 823

PVS-Studio: V3011 दो विपरीत परिस्थितियों का सामना करना पड़ा। दूसरी स्थिति हमेशा झूठी होती है। लाइनों की जाँच करें: 5242, 5240। DataGrid.cs 5242

 private void CheckHierarchyState() { if (checkHierarchy && listManager != null && myGridTable != null) { if (myGridTable == null) // <= { // there was nothing to check return; } for (int j = 0; j < myGridTable.GridColumnStyles.Count; j++) { DataGridColumnStyle gridColumn = myGridTable.GridColumnStyles[j]; } checkHierarchy = false; } } 

रिटर्न ऑपरेटर को कभी भी निष्पादित नहीं किया जाएगा। सबसे अधिक संभावना है, myGridTable! = बाहरी में अशक्त स्थिति अगर ब्लॉक को बाद में रिफैक्टिंग के दौरान जोड़ा गया था। और अब myGridTable == नल की जांच निरर्थक है। कोड की गुणवत्ता में सुधार करने के लिए, आपको इस चेक को हटा देना चाहिए।

PVS-Studio: V3019 संभवतः एक गलत वैरिएबल की तुलना 'कीवर्ड' के रूप में उपयोग करके टाइप रूपांतरण के बाद की जाती है। चर 'वाम', 'cscLeft' की जाँच करें। TypeCodeDomSerializer.cs 611

PVS-Studio: V3019 संभवतः एक गलत वैरिएबल की तुलना 'कीवर्ड' के रूप में उपयोग करके टाइप रूपांतरण के बाद की जाती है। चर 'सही', 'cscRight' की जाँच करें। TypeCodeDomSerializer.cs 615

 public int Compare(object left, object right) { OrderedCodeStatementCollection cscLeft = left as OrderedCodeStatementCollection; OrderedCodeStatementCollection cscRight = right as OrderedCodeStatementCollection; if (left == null) { return 1; } else if (right == null) { return -1; } else if (right == left) { return 0; } return cscLeft.Order - cscRight.Order; // <= } 

विश्लेषक ने एक ही बार में तुलना विधि के लिए दो चेतावनी दी। क्या समस्या है? यह है कि cscLeft और cscRight मानों को शून्य के लिए जाँच नहीं किया जाता है। ऑर्डर किए गए कोडेस्टेमेंटमेंट को हटाने के लिए असफल कास्टिंग के बाद उन्हें यह मान मिल सकता है। फिर अंतिम रिटर्न अभिव्यक्ति में एक अपवाद फेंक दिया जाएगा। यह स्थिति तब संभव है जब बाएं और दाएं पास के लिए सभी जांच और विधि से प्रारंभिक निकास न हो।

कोड को ठीक करने के लिए, आपको हर जगह बाएं / दाएं के बजाय cscLeft / cscRight का उपयोग करना चाहिए।

पीवीएस-स्टूडियो: वी 3020 एक लूप के भीतर बिना शर्त 'ब्रेक'। SelectionService.cs 421

 void ISelectionService.SetSelectedComponents( ICollection components, SelectionTypes selectionType) { .... // Handle the click case object requestedPrimary = null; int primaryIndex; if (fPrimary && 1 == components.Count) { foreach (object o in components) { requestedPrimary = o; if (o == null) { throw new ArgumentNullException(nameof(components)); } break; } } .... } 

यह खंड "कोड गंध" के बजाय संदर्भित करता है। यहां कोई त्रुटि नहीं है। लेकिन जिस तरह से फॉरेस्ट लूप का आयोजन होता है, उस पर सवाल उठते हैं। यह स्पष्ट है कि यहां इसकी आवश्यकता क्यों है: संग्रह के तत्वों को निकालने की आवश्यकता के कारण, ICollection के रूप में पारित किया गया। लेकिन लूप ने शुरुआत में एकल पुनरावृत्ति के लिए डिज़ाइन क्यों किया (संग्रह घटकों में एकल तत्व की उपस्थिति है), ब्रेक जैसे अतिरिक्त समर्थन की आवश्यकता है? संभवतः, उत्तर को इस प्रकार माना जा सकता है: "ऐतिहासिक रूप से, यह हो गया है।" कोड बदसूरत लग रहा है।

PVS-Studio: V3022 एक्सप्रेशन 'ocxState! = Null' हमेशा सच होता है। AxHost.cs 2186

 public State OcxState { .... set { .... if (value == null) { return; } .... ocxState = value; if (ocxState != null) // <= { axState[manualUpdate] = ocxState._GetManualUpdate(); licenseKey = ocxState._GetLicenseKey(); } else { axState[manualUpdate] = false; licenseKey = null; } .... } } 

एक तार्किक त्रुटि के कारण, इस टुकड़े में "मृत कोड" उत्पन्न हुआ। अन्य ब्लॉक में अभिव्यक्तियों को कभी भी निष्पादित नहीं किया जाएगा।

PVS-Studio: V3027 वैरिएबल 'e' को तार्किक अभिव्यक्ति में उपयोग किया गया था, क्योंकि यह उसी तार्किक अभिव्यक्ति में शून्य के खिलाफ सत्यापित था। ImageEditor.cs 99

 public override object EditValue(....) { .... ImageEditor e = ....; Type myClass = GetType(); if (!myClass.Equals(e.GetType()) && e != null && myClass.IsInstanceOfType(e)) { .... } .... } 

हालत में चर ई पहले प्रयोग किया जाता है और फिर अशक्त के खिलाफ जाँच की जाती है। हैलो, NullReferenceException ।

इस तरह की एक और त्रुटि:

PVS-Studio: V3027 चर 'dropDownItem' का तार्किक अभिव्यक्ति में उपयोग किया गया था, क्योंकि यह उसी तार्किक अभिव्यक्ति में शून्य के खिलाफ सत्यापित था। ToolStripMenuItemDesigner.cs 1351

 internal void EnterInSituEdit(ToolStripItem toolItem) { .... ToolStripDropDownItem dropDownItem = toolItem as ToolStripDropDownItem; if (!(dropDownItem.Owner is ToolStripDropDownMenu) && dropDownItem != null && dropDownItem.Bounds.Width < commitedEditorNode.Bounds.Width) { .... } .... } 

स्थिति पिछले एक के समान है लेकिन ड्रॉपडाउन इटेम चर के साथ। मुझे लगता है कि इस तरह की त्रुटियां लापरवाह परावर्तन के परिणामस्वरूप दिखाई देती हैं। शायद, हालत का एक हिस्सा ! (DropDownItem.Owner ToolStripDropDownMenu) कोड में बाद में जोड़ा गया था।

PVS-Studio: V3030 आवर्ती जाँच। 'कॉलमकाउंट> 0' की स्थिति पहले से ही 3900 लाइन में सत्यापित की गई थी। सूची दृश्य। 3903

 internal ColumnHeader InsertColumn( int index, ColumnHeader ch, bool refreshSubItems) { .... // Add the column to our internal array int columnCount = (columnHeaders == null ? 0 : columnHeaders.Length); if (columnCount > 0) { ColumnHeader[] newHeaders = new ColumnHeader[columnCount + 1]; if (columnCount > 0) { System.Array.Copy(columnHeaders, 0, newHeaders, 0, columnCount); } .... } .... } 

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

PVS-Studio: V3061 पैरामीटर 'lprcClipRect' का उपयोग करने से पहले हमेशा विधि निकाय में फिर से लिखा जाता है। WebBrowserSiteBase.cs 281

 int UnsafeNativeMethods.IOleInPlaceSite.GetWindowContext( out UnsafeNativeMethods.IOleInPlaceFrame ppFrame, out UnsafeNativeMethods.IOleInPlaceUIWindow ppDoc, NativeMethods.COMRECT lprcPosRect, NativeMethods.COMRECT lprcClipRect, NativeMethods.tagOIFI lpFrameInfo) { ppDoc = null; ppFrame = Host.GetParentContainer(); lprcPosRect.left = Host.Bounds.X; lprcPosRect.top = Host.Bounds.Y; .... lprcClipRect = WebBrowserHelper.GetClipRect(); // <= if (lpFrameInfo != null) { lpFrameInfo.cb = Marshal.SizeOf<NativeMethods.tagOIFI>(); lpFrameInfo.fMDIApp = false; .... } return NativeMethods.S_OK; } 

एक अनजानी गलती। हां, lprcClipRect पैरामीटर वास्तव में किसी भी तरह से इसका उपयोग किए बिना एक नए मूल्य के साथ आरंभिक है। लेकिन यह अंत में क्या करता है? मुझे लगता है कि कॉलिंग कोड में इस पैरामीटर के माध्यम से पारित संदर्भ अपरिवर्तित रहेगा, हालाँकि ऐसा करने का इरादा नहीं था। वास्तव में, इस विधि में अन्य चर की हैंडलिंग की सराहना करें। यहां तक ​​कि इसका नाम ("गेट" उपसर्ग) यह संकेत देता है कि पारित किए गए मापदंडों के माध्यम से विधि के अंदर कुछ आरंभीकरण किया जाएगा। और ऐसा है। पहले दो पैरामीटर ( ppFrame और ppDoc ) आउट मॉडिफायर के साथ पास किए जाते हैं और उन्हें नए मान मिलते हैं। संदर्भ lprcPosRect और lpFrameInfo का उपयोग क्लास फ़ील्ड्स को एक्सेस और इनिशियलाइज़ करने के लिए किया जाता है। केवल lprcClipRect बाहर खड़ा है। संभवतः, इस पैरामीटर के लिए आउट या रेफ मॉडिफ़ायर आवश्यक है।

PVS-Studio: V3066 संभावित गलत आदेशों का तर्क 'AdjustCellBorderStyle' पद्धति से पारित हुआ:'FirstDisplayedRow 'और'FirstDisplayedColumn'। DataGridViewComboBoxCell.cs 1934

 protected override void OnMouseMove(DataGridViewCellMouseEventArgs e) { .... dgvabsEffective = AdjustCellBorderStyle( DataGridView.AdvancedCellBorderStyle, dgvabsPlaceholder, singleVerticalBorderAdded, singleHorizontalBorderAdded, isFirstDisplayedRow, // <= isFirstDisplayedColumn); // <= .... } 

विश्लेषक को संदेह था कि अंतिम दो तर्क मिश्रित थे। चलिए एडजस्टमेंट कंट्रोलर विधि की घोषणा पर एक नज़र डालते हैं :

 public virtual DataGridViewAdvancedBorderStyle AdjustCellBorderStyle( DataGridViewAdvancedBorderStyledataGridViewAdvancedBorderStyleInput, DataGridViewAdvancedBorderStyle dataGridViewAdvancedBorderStylePlaceholder, bool singleVerticalBorderAdded, bool singleHorizontalBorderAdded, bool isFirstDisplayedColumn, bool isFirstDisplayedRow) { .... } 

गलती लगती है। हां, कुछ तर्क अक्सर रिवर्स ऑर्डर में पारित किए जाते हैं, उदाहरण के लिए, कुछ चर का आदान-प्रदान करने के लिए। लेकिन मुझे नहीं लगता कि यह मामला है। कॉलर या कैली विधियों में कुछ भी इस उपयोग पैटर्न को इंगित नहीं करता है। सबसे पहले, बूल प्रकार के चर को मिलाया जाता है। दूसरा, विधियों के नाम भी नियमित हैं: कोई "स्वैप" या "रिवर्स" नहीं। इसके अलावा, इस तरह की गलती करना इतना मुश्किल नहीं है। लोग अक्सर "पंक्ति / स्तंभ" जोड़ी के क्रम को अलग तरह से समझते हैं। मेरे लिए, उदाहरण के लिए, यह "पंक्ति / स्तंभ" है जो परिचित है। लेकिन AdjustCellBorderStyle नामक विधि के लेखक के लिए, जाहिर है, अधिक सामान्य क्रम "कॉलम / पंक्ति" है।

पीवीएस-स्टूडियो: 'LOCALE_USER_DEFAULT' वैरिएबल को प्रारंभ करते समय V3070 Uninitialized चर 'LANG_USER_DEFAULT' का उपयोग किया जाता है। NativeMethods.cs 890

 internal static class NativeMethods { .... public static readonly int LOCALE_USER_DEFAULT = MAKELCID(LANG_USER_DEFAULT); public static readonly int LANG_USER_DEFAULT = MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT); .... } 

दुर्लभ गलती। वर्ग क्षेत्रों का प्रारंभिक क्रम मिला-जुला है। LOCALE_USER_DEFAULT फ़ील्ड के मान की गणना करने के लिए LANG_USER_DEFAULT फ़ील्ड का उपयोग किया जाता है, जो अभी तक आरंभीकृत नहीं है और इसका मान 0. है। वैसे, LANG_USER_DEFAULT फ़ील्ड का उपयोग कोड में कहीं और नहीं किया जाता है। मैं एक अतिरिक्त मील गया और एक छोटा सांत्वना कार्यक्रम लिखा जो स्थिति का अनुकरण करता है। मैंने WinForms कोड में प्रयुक्त कुछ स्थिरांक को उनके वास्तविक मूल्यों के साथ प्रतिस्थापित किया:

 internal static class NativeMethods { public static readonly int LOCALE_USER_DEFAULT = MAKELCID(LANG_USER_DEFAULT); public static readonly int LANG_USER_DEFAULT = MAKELANGID(0x00, 0x01); public static int MAKELANGID(int primary, int sub) { return ((((ushort)(sub)) << 10) | (ushort)(primary)); } public static int MAKELCID(int lgid) { return MAKELCID(lgid, 0x0); } public static int MAKELCID(int lgid, int sort) { return ((0xFFFF & lgid) | (((0x000f) & sort) << 16)); } } class Program { static void Main() { System.Console.WriteLine(NativeMethods.LOCALE_USER_DEFAULT); } } 

परिणामस्वरूप, कंसोल प्रदर्शित करेगा: 0. अब LOCALE_USER_DEFAULT और LANG_USER_DEFAULT फ़ील्ड की घोषणाओं को स्वैप करें। कार्यक्रम के निष्पादन का परिणाम निम्नानुसार है: 1024। मुझे लगता है कि यहां पर टिप्पणी करने के लिए अधिक कुछ नहीं है।

पीवीएस-स्टूडियो: वी 3080 संभावित अशक्तता । 'सेस' का निरीक्षण करने पर विचार करें। कोडडोमसेरिलाइज़रबेस .cs 562

 protected void DeserializeStatement( IDesignerSerializationManager manager, CodeStatement statement) { .... CodeExpressionStatement ces = statement as CodeExpressionStatement; if (ces != null) { .... } else { .... DeserializeExpression(manager, null, ces.Expression); // <= .... } .... } 

कोड जो नियमित रूप से "क्रैश" होना चाहिए, क्योंकि आप दूसरी शाखा में तभी जा सकते हैं जब ces संदर्भ शून्य के बराबर हो।

इसी तरह का एक और उदाहरण:

पीवीएस-स्टूडियो: वी 3080 संभावित अशक्तता । 'कॉम्बो बॉक्स' का निरीक्षण करने पर विचार करें। ComboBox.cs 6610

 public void ValidateOwnerDrawRegions(ComboBox comboBox, ....) { .... if (comboBox != null) { return; } Rectangle topOwnerDrawArea = new Rectangle(0, 0, comboBox.Width, innerBorder.Top); .... } 

विरोधाभासी कोड। जाहिरा तौर पर, अगर (comboBox! = Null) चेक if (comboBox == null) से भ्रमित था। और इसलिए, हम एक और NullReferenceException प्राप्त करेंगे ।

हमने दो स्पष्ट वी 3080 त्रुटियों पर विचार किया है, जहां आप एक विधि के भीतर संभावित अशक्त संदर्भ उपयोग को देख सकते हैं। लेकिन V3080 डायग्नोस्टिक अधिक कुशल है और विधि कॉल श्रृंखला के लिए ऐसी त्रुटियां पा सकता है। ऐसा नहीं है कि बहुत पहले हमने डेटाफ्लो और इंटरप्रोडेक्टल एनालिसिस मैकेनिज्म में काफी सुधार किया है। आप इसके बारे में लेख " Nullable Reference types in C # 8.0 और static analysis " में पढ़ सकते हैं। लेकिन यहाँ WinForms में इस तरह की त्रुटि पाई गई है:

PVS- स्टूडियो: V3080 'n.TT' पर विधि के अंदर संभव अशांति को रोकने। 1 तर्क का निरीक्षण करने पर विचार करें: contentReader। ResXResourceReader.cs 267

 private void EnsureResData() { .... XmlTextReader contentReader = null; try { if (fileContents != null) { contentReader = new XmlTextReader(....); } else if (reader != null) { contentReader = new XmlTextReader(....); } else if (fileName != null || stream != null) { .... contentReader = new XmlTextReader(....); } SetupNameTable(contentReader); // <= .... } finally { .... } .... } 

देखो क्या होता है सामग्री शरीर में चर चर। नल के साथ आरंभीकरण के बाद, इसे एक चेक में फिर से इनिशियलाइज़ किया जाएगा। लेकिन चेकों की श्रृंखला अन्य ब्लॉक के साथ समाप्त नहीं होती है। इसका मतलब यह है कि कुछ दुर्लभ मामलों में (या भविष्य में रिफ्लेक्टरिंग के कारण) संदर्भ अभी भी अशक्त रह सकता है। फिर इसे SetupNameTable पद्धति में पास किया जाएगा जहाँ इसका उपयोग बिना किसी जाँच के किया जाता है:

 private void SetupNameTable(XmlReader reader) { reader.NameTable.Add(ResXResourceWriter.TypeStr); reader.NameTable.Add(ResXResourceWriter.NameStr); .... } 

यह संभावित असुरक्षित कोड है।

और एक और त्रुटि जहां विश्लेषक को समस्या का पता लगाने के लिए कॉल श्रृंखला से गुजरना पड़ा:

पीवीएस-स्टूडियो: वी 3080 संभावित अशक्तता । निरीक्षण 'लेआउट' पर विचार करें। DockAndAnchorLayout.cs 156

 private static Rectangle GetAnchorDestination( IArrangedElement element, Rectangle displayRect, bool measureOnly) { .... AnchorInfo layout = GetAnchorInfo(element); int left = layout.Left + displayRect.X; .... } 

विश्लेषक का दावा है कि GetAnchorInfo विधि से एक शून्य संदर्भ प्राप्त करना संभव है, जो बाएं मान की गणना करते समय एक अपवाद का कारण होगा। चलिए पूरी कॉल चेन से गुजरते हैं और जाँचते हैं कि क्या यह सच है:

 private static AnchorInfo GetAnchorInfo(IArrangedElement element) { return (AnchorInfo)element.Properties.GetObject(s_layoutInfoProperty); } public object GetObject(int key) => GetObject(key, out _); public object GetObject(int key, out bool found) { short keyIndex = SplitKey(key, out short element); if (!LocateObjectEntry(keyIndex, out int index)) { found = false; return null; } // We have found the relevant entry. See if // the bitmask indicates the value is used. if (((1 << element) & s_objEntries[index].Mask) == 0) { found = false; return null; } found = true; switch (element) { case 0: return s_objEntries[index].Value1; .... default: Debug.Fail("Invalid element obtained from LocateObjectEntry"); return null; } } 

दरअसल, कुछ मामलों में, कॉल श्रृंखला को समाप्त करने वाली GetObject विधि शून्य हो जाएगी, जिसे बिना किसी अतिरिक्त जांच के कॉलर विधि को पास कर दिया जाएगा। संभवतः, GetAnchorDestination पद्धति में ऐसी स्थिति को कवर करना आवश्यक है।

WinForms कोड में 70 से अधिक ऐसी बहुत सी त्रुटियाँ हैं। वे सभी एक जैसे दिखते हैं और मैं उन्हें लेख में वर्णित नहीं करूंगा।

पीवीएस-स्टूडियो: V3091 अनुभवजन्य विश्लेषण। यह संभव है कि एक टाइपो स्ट्रिंग शाब्दिक के अंदर मौजूद है: "ShowCheckMargin"। 'ShowCheckMargin' शब्द संदिग्ध है। संपत्ति नाम। 136

 internal class PropertyNames { .... public static readonly string ShowImageMargin = "ShowCheckMargin"; ... public static readonly string ShowCheckMargin = "ShowCheckMargin"; .... } 

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

इस तरह की त्रुटियों का पता लगाना स्थैतिक विश्लेषण उपकरणों की सभी शक्ति और अंतहीन ध्यान अवधि को प्रदर्शित करता है।

PVS-Studio: V3095 नल के खिलाफ सत्यापित होने से पहले ' currentForm ' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 3386, 3404. Application.cs 3386

 private void RunMessageLoopInner(int reason, ApplicationContext context) { .... hwndOwner = new HandleRef( null, UnsafeNativeMethods.GetWindowLong( new HandleRef(currentForm, currentForm.Handle), // <= NativeMethods.GWL_HWNDPARENT)); .... if (currentForm != null && ....) .... } 

यह क्लासिक है। CurrentForm चर का उपयोग बिना किसी जाँच के किया जाता है। लेकिन फिर यह कोड में अशक्त के लिए जाँच की है। इस मामले में मैं आपको सलाह दे सकता हूं कि संदर्भ प्रकारों के साथ काम करते समय आप अधिक चौकस रहें और स्थैतिक विश्लेषक का भी उपयोग करें :)।

इस तरह की एक और त्रुटि:

पीवीएस-स्टूडियो: V3095 'बैकग्राउंडब्रश' ऑब्जेक्ट का उपयोग इससे पहले किया गया था कि इसे शून्य के खिलाफ सत्यापित किया गया था। जाँच रेखाएँ: 2331, 2334। DataGrid.cs 2331

 public Color BackgroundColor { .... set { .... if (!value.Equals(backgroundBrush.Color)) // <= { if (backgroundBrush != null && BackgroundBrush != DefaultBackgroundBrush) .... } } } 

WinForms कोड में, मैं 60 से अधिक ऐसी त्रुटियों के साथ आया था। मेरी राय में, उनमें से सभी महत्वपूर्ण हैं और डेवलपर्स के ध्यान की आवश्यकता है। लेकिन अब लेख में उनके बारे में बताना इतना दिलचस्प नहीं है, इसलिए मैं खुद को ऊपर वर्णित दो तक सीमित करूंगा।

PVS-Studio: V3125 '_propInfo' ऑब्जेक्ट का उपयोग किया गया था और इसे विभिन्न निष्पादन शाखाओं में नल के खिलाफ सत्यापित किया गया था। चेक लाइनें: 996, 982. बाइंडिंग.के 996

 private void SetPropValue(object value) { .... if (....) { if .... else if (_propInfo != null) .... } else { _propInfo.SetValue(_control, value); } .... } 

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

और इस तरह की एक और त्रुटि:

PVS-Studio: V3125 'मालिक' ऑब्जेक्ट का उपयोग नल के खिलाफ सत्यापित होने के बाद किया गया था। रेखाएँ जांचें: 64, 60. फ्लैटबटन एपियरेंस .cs 64

 public int BorderSize { .... set { .... if (owner != null && owner.ParentInternal != null) { LayoutTransaction.DoLayoutIf(....); } owner.Invalidate(); // <= .... } } 

लवली। लेकिन यह एक बाहरी शोधकर्ता का दृष्टिकोण है। आखिरकार, विश्लेषक को इन दो V3125 के अलावा WinForms कोड में 50 से अधिक ऐसे पैटर्न मिले । डेवलपर्स के पास काम करने के लिए बहुत कुछ है।

और अंत में, एक दिलचस्प त्रुटि है, मेरी राय में।

PVS-Studio: V3137 'hCurrentFont' वैरिएबल असाइन किया गया है, लेकिन फ़ंक्शन के अंत तक उपयोग नहीं किया गया है। DeviceContext2.cs 241

 sealed partial class DeviceContext : .... { WindowsFont selectedFont; .... internal void DisposeFont(bool disposing) { if (disposing) { DeviceContexts.RemoveDeviceContext(this); } if (selectedFont != null && selectedFont.Hfont != IntPtr.Zero) { IntPtr hCurrentFont = IntUnsafeNativeMethods.GetCurrentObject( new HandleRef(this, hDC), IntNativeMethods.OBJ_FONT); if (hCurrentFont == selectedFont.Hfont) { // select initial font back in IntUnsafeNativeMethods.SelectObject(new HandleRef(this, Hdc), new HandleRef(null, hInitialFont)); hCurrentFont = hInitialFont; // <= } selectedFont.Dispose(disposing); selectedFont = null; } } .... } 

आइए देखें कि विश्लेषक ने क्या सतर्क किया, और यह एक समस्या का संकेत क्यों दे सकता है कि एक चर को एक मान सौंपा गया है, लेकिन कोड में इसका उपयोग कभी नहीं किया जाता है।

DeviceContext2.cs फ़ाइल में एक आंशिक वर्ग है। DisposeFont विधि का उपयोग ग्राफिक्स के साथ काम करने के बाद संसाधनों को मुक्त करने के लिए किया जाता है: डिवाइस संदर्भ और फ़ॉन्ट। बेहतर समझ के लिए मैंने पूरी डिस्पोज़न्ट विधि दी है। स्थानीय चर hCurrentFont पर ध्यान दें । समस्या यह है कि विधि में इस चर की घोषणा उसी नाम के वर्ग क्षेत्र को छुपाती है। मुझे DeviceContext क्लास के दो तरीके मिले जहाँ hCurrentFont नाम वाले फ़ील्ड का उपयोग किया जाता है:

 public IntPtr SelectFont(WindowsFont font) { .... hCurrentFont = font.Hfont; .... } public void ResetFont() { .... hCurrentFont = hInitialFont; } 

ResetFont विधि को देखें। अंतिम पंक्ति बिल्कुल वही है जो डिस्पोज़ल विधि सबब्लॉक में करती है अगर (यह वही है जो विश्लेषक बताते हैं)। इसी नाम का hCurrentFont फ़ील्ड DeviceContext.cs फ़ाइल में आंशिक वर्ग के किसी अन्य भाग में घोषित किया गया है:

 sealed partial class DeviceContext : .... { .... IntPtr hInitialFont; .... IntPtr hCurrentFont; // <= .... } 

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

निष्कर्ष

इसलिए, इस बार, मुझे एमएस की थोड़ी आलोचना करनी होगी। WinForms में, बहुत सारी त्रुटियां हैं जिनके लिए डेवलपर्स का पूरा ध्यान आवश्यक है। शायद यह कुछ जल्दबाजी का दोष है जिसके साथ MS .NET .NET 3 और घटकों पर काम करता है, जिसमें WinForms भी शामिल है। मेरी राय में, WinForms कोड अभी भी "कच्चा" है, लेकिन मुझे उम्मीद है कि स्थिति जल्द ही बेहतर होगी।

बड़ी संख्या में त्रुटियों का दूसरा कारण यह हो सकता है कि हमारा विश्लेषक केवल उनकी खोज में बेहतर हो गया है :)।

वैसे, मेरे सहयोगी सर्गेई वासिलिव का एक लेख जल्द ही प्रकाशित किया जाएगा जिसमें वह .NET कोर पुस्तकालयों के कोड में बहुत सारी समस्याओं की खोज और खोज करता है। मुझे उम्मीद है कि उनका काम .NET प्लेटफॉर्म की विशेषताओं को बेहतर बनाने में भी योगदान देगा, क्योंकि हम हमेशा डेवलपर्स को उनकी परियोजनाओं के विश्लेषण के परिणामों के बारे में सूचित करने का प्रयास करते हैं।

और जो लोग अपने उत्पादों को अपने दम पर सुधारना चाहते हैं या अन्य लोगों की परियोजनाओं में त्रुटियों की खोज करना चाहते हैं, मैं सुझाव देता हूं कि आप पीवीएस-स्टूडियो डाउनलोड करें और प्रयास करें ।

सभी को क्लीन कोड!