रोजलिन सोर्स कोड की जाँच करना

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

हमारे कई पाठकों को रोजलिन (या .NET कंपाइलर प्लेटफॉर्म) के बारे में अच्छी तरह से पता होने की संभावना है। संक्षेप में, यह ओपन सोर्स कंपाइलर्स का सेट है और माइक्रोसॉफ्ट से C # और विजुअल बेसिक .NET भाषाओं के कोड विश्लेषण के लिए एक एपीआई है। परियोजना का स्रोत कोड GitHub पर उपलब्ध है ।

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

जैसा कि मैंने पहले उल्लेख किया है, मेरे सहयोगी एंड्री कारपोव ने रोसेल चेक के बारे में आखिरी लेख " न्यू ईयर पीवीएस-स्टूडियो 6.00 रिलीज: स्कैनिंग रोजलिन " लिखा है, 3 साल से अधिक समय हो गया है। तब से C # PVS-Studio विश्लेषक को कई नई सुविधाएँ मिलीं। दरअसल, एंड्री का लेख एक परीक्षण मामला था, क्योंकि उस समय पीवी # स्टूडियोज में C # विश्लेषक को जोड़ा गया था। इसके बावजूद, हम रोज़लिन परियोजना में त्रुटियों का पता लगाने में कामयाब रहे, जो निश्चित रूप से उच्च गुणवत्ता वाला था। तो इस पल तक सी # कोड के लिए विश्लेषक में क्या बदलाव आया है जो हमें अधिक गहराई से विश्लेषण करने की अनुमति देगा?

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

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

विश्लेषक कोर में भी कई सुधार हुए हैं। मुख्य विशेषताओं में से एक इनपुट और आउटपुट तरीकों के मूल्यों पर विचार करने के साथ एक पूर्ण इंटरप्रोसेरुरल विश्लेषण है, मूल्यांकन (इन मापदंडों के आधार पर) निष्पादन शाखाओं की पुनरावृत्ति और वापसी बिंदु।

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

नोट: आप बुनियादी विश्लेषक तंत्र के बारे में पढ़ सकते हैं, जैसे डेटा-फ्लो और अन्य लेख " बग्स और संभावित कमजोरियों को खोजने के लिए पीवीएस-स्टूडियो कोड विश्लेषक में उपयोग की जाने वाली तकनीक "।

PVS-Studio C # में इंटरप्रोसेसर का विश्लेषण न तो इनपुट मापदंडों, और न ही गहराई तक सीमित है। केवल सीमा कक्षाओं में आभासी विधियां हैं, वंशानुक्रम के लिए खुला है, साथ ही पुनरावृत्ति में हो रहा है (विश्लेषण पहले से ही मूल्यांकन की गई विधि के बार-बार कॉल पर ठोकर खाने पर बंद हो जाता है)। ऐसा करने के बाद, पुनरावर्ती विधि का स्वयं ही यह मानकर मूल्यांकन किया जाएगा कि इसकी पुनरावृत्ति का प्रतिफल अज्ञात है।

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

अब विश्लेषक इस तथ्य से अवगत है कि चर निष्पादन शाखाओं में से एक में शून्य हो सकता है (उदाहरण के लिए, एक निश्चित अगर शर्त के तहत)। यदि यह बिना किसी चेक के ऐसे वैरिएबल तक पहुँच प्राप्त करता है, तो यह V3080 चेतावनी जारी करेगा, लेकिन निश्चितता के निचले स्तर पर, यदि यह सभी शाखाओं में अशक्त दिखाई देता है। बेहतर इंटरप्रोडेक्टोरल विश्लेषण के साथ, इस तरह के एक तंत्र में त्रुटियों को खोजने की अनुमति मिलती है जो कि पता लगाना बहुत मुश्किल है। यहां एक उदाहरण है - विधि कॉल की एक लंबी श्रृंखला की कल्पना करें, जिनमें से अंतिम आपके लिए अपरिचित है। कुछ परिस्थितियों में, यह कैच ब्लॉक में अशक्त हो जाता है, लेकिन आप इससे सुरक्षित नहीं हैं, जैसा कि आप सरल जानते हैं। इस मामले में, विश्लेषक केवल शिकायत करता है, जब यह वास्तव में अशक्त असाइनमेंट देखता है। हमारे विचार में, यह गुणात्मक रूप से हमारे दृष्टिकोण को C # 8.0 की ऐसी विशेषता से अशक्त प्रकार के संदर्भ के रूप में अलग करता है, जो वास्तव में, प्रत्येक विधि के लिए अशक्त के लिए चेक सेट करने तक सीमित है। हालांकि, हम विकल्प का सुझाव देते हैं - केवल उन स्थानों पर जांच करने के लिए जहां नल वास्तव में हो सकते हैं, और हमारे विश्लेषक अब ऐसे मामलों की खोज कर सकते हैं।

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

मैं निश्चित स्तर के मध्यम स्तर की V3080 त्रुटियों के साथ शुरू करूंगा, जिसमें विश्लेषक ने अशक्त संदर्भ द्वारा एक संभावित पहुंच का पता लगाया है, लेकिन सभी संभावित मामलों (कोड शाखाओं) में नहीं।

संभावित अशक्तता - मध्यम

V3080 संभव अशक्तता। 'वर्तमान' का निरीक्षण करने पर विचार करें। CSharpSyntaxTreeFactoryService.PositionalSyntaxReference.cs 70

private SyntaxNode GetNode(SyntaxNode root) { var current = root; .... while (current.FullSpan.Contains(....)) // <= { .... var nodeOrToken = current.ChildThatContainsPosition(....); .... current = nodeOrToken.AsNode(); // <= } .... } public SyntaxNode AsNode() { if (_token != null) { return null; } return _nodeOrParent; } 

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

अब एक समान मामले पर विचार करते हैं, जिसमें दो विधि कॉल के माध्यम से इंटरप्रोडेक्टल विश्लेषण किया गया था।

V3080 संभव अशक्तता। 'निर्देशिका' का निरीक्षण करने पर विचार करें। CommonCommandLineParser.cs 911

 private IEnumerable<CommandLineSourceFile> ExpandFileNamePattern(string path, string baseDirectory, ....) { string directory = PathUtilities.GetDirectoryName(path); .... var resolvedDirectoryPath = (directory.Length == 0) ? // <= baseDirectory : FileUtilities.ResolveRelativePath(directory, baseDirectory); .... } public static string GetDirectoryName(string path) { return GetDirectoryName(path, IsUnixLikePlatform); } internal static string GetDirectoryName(string path, bool isUnixLike) { if (path != null) { .... } return null; } 

ExpandFileNamePattern विधि के मुख्य भाग में निर्देशिका चर GetDirectoryName (स्ट्रिंग) विधि से मान प्राप्त करता है। बदले में, अतिभारित विधि GetDirectoryName (स्ट्रिंग, बूल) का परिणाम देता है जिसका मूल्य शून्य हो सकता है। चूँकि चर निर्देशिका का विस्तार विधि के शरीर में नल के लिए प्रारंभिक जाँच के बिना किया जाता है। हम चेतावनी जारी करने के बारे में सही तरीके से विश्लेषक की घोषणा कर सकते हैं। यह एक संभावित असुरक्षित निर्माण है।

V3080 त्रुटि के साथ एक और कोड टुकड़ा, अधिक सटीक रूप से, दो त्रुटियों के साथ, कोड की एक पंक्ति के लिए जारी किया गया। इंटरप्रोडेक्टल विश्लेषण की यहाँ आवश्यकता नहीं थी।

V3080 संभव अशक्तता। 'स्पैनस्टार्टलोकेशन' का निरीक्षण करने पर विचार करें। TestWorkspace.cs 574

V3080 संभव अशक्तता। निरीक्षण करने पर विचार करें 'spanEndLocationExclusive'। TestWorkspace.cs 574

 private void MapMarkupSpans(....) { .... foreach (....) { .... foreach (....) { .... int? spanStartLocation = null; int? spanEndLocationExclusive = null; foreach (....) { if (....) { if (spanStartLocation == null && positionInMarkup <= markupSpanStart && ....) { .... spanStartLocation = ....; } if (spanEndLocationExclusive == null && positionInMarkup <= markupSpanEndExclusive && ....) { .... spanEndLocationExclusive = ....; break; } .... } .... } tempMappedMarkupSpans[key]. Add(new TextSpan( spanStartLocation.Value, // <= spanEndLocationExclusive.Value - // <= spanStartLocation.Value)); } } .... } 

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

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

नोट। ऐसा होता है, किसी दिए गए बिंदु पर ऐसे मामले (इनपुट डेटा) नहीं होते हैं, जब विधि शून्य हो जाती है और कोई वास्तविक त्रुटि नहीं होती है। हालांकि, ऐसा कोड अभी भी विश्वसनीय नहीं है, क्योंकि कुछ कोड परिवर्तन शुरू करते समय सब कुछ बदल सकता है।

V3080 विषय को छोड़ने के लिए, आइए उच्च निश्चितता स्तर की स्पष्ट त्रुटियों को देखें, जब अशक्त संदर्भ द्वारा पहुंच संभव या अपरिहार्य है।

संभावित अशक्तता - उच्च

V3080 संभव अशक्तता। 'CollectionType.Type' के निरीक्षण पर विचार करें। AbstractConvertForToForEachCodeRefactoringProvider.cs 137

 public override async Task ComputeRefactoringsAsync(CodeRefactoringContext context) { .... var collectionType = semanticModel.GetTypeInfo(....); if (collectionType.Type == null && collectionType.Type.TypeKind == TypeKind.Error) { return; } .... } 

स्थिति में टाइपो के कारण ( और ऑपरेटर के बजाय ( &&) का उपयोग किया जाता है।), कोड उद्देश्य से अलग तरह से काम करता है और संग्रह के लिए पहुँच। टाइप वेरिएबल को निष्पादित किया जाएगा जब यह शून्य है । हालत को इस प्रकार ठीक किया जाना चाहिए:

 if (collectionType.Type == null || collectionType.Type.TypeKind == TypeKind.Error) .... 

वैसे, चीजें दूसरे तरीके से सामने आ सकती हैं: हालत के पहले भाग में ऑपरेटर्स == और ! = गड़बड़ हैं । तब सही कोड इस तरह दिखेगा:

 if (collectionType.Type != null && collectionType.Type.TypeKind == TypeKind.Error) .... 

कोड का यह संस्करण कम तार्किक है, लेकिन त्रुटि को भी ठीक करता है। अंतिम समाधान परियोजना के लेखकों को तय करने के लिए टिकी हुई है।

एक और समान त्रुटि।

V3080 संभव अशक्तता। निरीक्षण 'कार्रवाई' पर विचार करें। TextViewWindow_InProc.cs 372

 private Func<IWpfTextView, Task> GetLightBulbApplicationAction(....) { .... if (action == null) { throw new InvalidOperationException( $"Unable to find FixAll in {fixAllScope.ToString()} code fix for suggested action '{action.DisplayText}'."); } .... } 

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

यहां उच्च स्तर की अंतिम V3080 त्रुटि आई है।

V3080 संभव अशक्तता। 'प्रकार' का निरीक्षण करने पर विचार करें। ObjectFormatterHelpers.cs 91

 private static bool IsApplicableAttribute( TypeInfo type, TypeInfo targetType, string targetTypeName) { return type != null && AreEquivalent(targetType, type) || targetTypeName != null && type.FullName == targetTypeName; } 

विधि काफी छोटी है, इसलिए मैं इसे पूरी तरह से उद्धृत करता हूं। रिटर्न ब्लॉक में स्थिति गलत है। कुछ मामलों में, जब accessing.full नाम आता है , तो एक अपवाद हो सकता है। मैं इसे स्पष्ट करने के लिए कोष्ठक का उपयोग करूँगा (वे व्यवहार को नहीं बदलेंगे):

 return (type != null && AreEquivalent(targetType, type)) || (targetTypeName != null && type.FullName == targetTypeName); 

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

 return type != null && (AreEquivalent(targetType, type) || targetTypeName != null && type.FullName == targetTypeName); 

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

टाइपो

V3005 'SourceCodeKind' वेरिएबल को ही सौंपा गया है। डायनामिकफाइलइन्फो .cs 17

 internal sealed class DynamicFileInfo { .... public DynamicFileInfo( string filePath, SourceCodeKind sourceCodeKind, TextLoader textLoader, IDocumentServiceProvider documentServiceProvider) { FilePath = filePath; SourceCodeKind = SourceCodeKind; // <= TextLoader = textLoader; DocumentServiceProvider = documentServiceProvider; } .... } 

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

 public DynamicFileInfo( string _filePath, SourceCodeKind _sourceCodeKind, TextLoader _textLoader, IDocumentServiceProvider _documentServiceProvider) { FilePath = _filePath; SourceCodeKind = _sourceCodeKind; TextLoader = _textLoader; DocumentServiceProvider = _documentServiceProvider; } 

असावधानी

V3006 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है: नया InvalidOperationException (FOO) फेंकें। ProjectBuildManager.cs 61

 ~ProjectBuildManager() { if (_batchBuildStarted) { new InvalidOperationException("ProjectBuilderManager.Stop() not called."); } } 

एक निश्चित स्थिति के तहत, विध्वंसक को एक अपवाद फेंकना चाहिए, लेकिन ऐसा नहीं हो रहा है जबकि अपवाद वस्तु बस बनाई गई है। थ्रो कीवर्ड छूट गया था। यहाँ कोड का सही संस्करण है:

 ~ProjectBuildManager() { if (_batchBuildStarted) { throw new InvalidOperationException("ProjectBuilderManager.Stop() not called."); } } 

सी # में विध्वंसक के साथ मुद्दा और उनसे अपवाद फेंकना एक और चर्चा का विषय है, जो इस लेख के दायरे से बाहर है।

जब परिणाम महत्वपूर्ण नहीं है

सभी मामलों में समान मूल्य प्राप्त करने वाले तरीकों ने एक निश्चित संख्या में V3009 चेतावनियों को चालू किया । कुछ मामलों में यह महत्वपूर्ण नहीं हो सकता है या कॉलिंग कोड में रिटर्न वैल्यू की आसानी से जाँच नहीं की जाती है मैंने ऐसी चेतावनियों को छोड़ दिया। लेकिन कुछ कोड स्निपेट संदिग्ध लग रहे थे। यहाँ उनमें से एक है:

V3009 यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। GoToDefinitionCommandHandler.cs 62

 internal bool TryExecuteCommand(....) { .... using (context.OperationContext.AddScope(....)) { if (....) { return true; } } .... return true; } 

विधि TryExecuteCommand सही लेकिन कुछ भी नहीं देता है । ऐसा करने पर, कॉलिंग कोड में लौटाया गया मान कुछ चेक में शामिल होता है।

 public bool ExecuteCommand(....) { .... if (caretPos.HasValue && TryExecuteCommand(....)) { .... } .... } 

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

इसी तरह के विश्लेषक चेतावनी:

• V3009 यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। CommentUncommentSelectionCommandHandler.cs 86
• V3009 यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। RenameTrackingTaggerProvider.RenameTrackingCommitter.cs 99
• V3009 यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। JsonRpcClient.cs 138
• V3009 यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। AbstractFormatEngine.OperationApplier.cs 164
• V3009 यह विचित्र है कि यह विधि हमेशा एक और 'समान' मूल्य को वापस करती है। TriviaDataFactory.CodeShapeAnalyzer.cs 254
• V3009 यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। ObjectList.cs 173
• V3009 यह विचित्र है कि यह विधि हमेशा एक और 'सही' के समान मान देती है। ObjectList.cs 249

गलत चीज की जांच की

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

 public bool TryPersist(OptionKey optionKey, object value) { .... var valueToSerialize = value as NamingStylePreferences; if (value != null) { value = valueToSerialize.CreateXElement().ToString(); } .... } 

मान वैरिएबल प्रकार NamingStylePreferences के लिए डाली गई है। समस्या इस जाँच में है जो इस प्रकार है। भले ही मान चर गैर शून्य था, लेकिन यह गारंटी नहीं देता है कि टाइपिंग सफल रही थी और valueToSerialize में शून्य नहीं था। अपवाद NullReferenceException का संभावित फेंकना। कोड को निम्नानुसार सही करने की आवश्यकता है:

 var valueToSerialize = value as NamingStylePreferences; if (valueToSerialize != null) { value = valueToSerialize.CreateXElement().ToString(); } 

एक और समान बग:

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

 private void SetDefinitionGroupingPriority(....) { .... foreach (var columnState in ....) { var columnState2 = columnState as ColumnState2; if (columnState?.Name == // <= StandardTableColumnDefinitions2.Definition) { newColumns.Add(new ColumnState2( columnState2.Name, // <= ....)); } .... } .... } 

ColumnState वैरिएबल ColumnState2 टाइप किया जाता है । हालाँकि, ऑपरेशन परिणाम, जो कि चर स्तम्भन 2 है, आगे शून्य के लिए जाँच नहीं है। इसके बजाय, सशर्त अशक्त ऑपरेटर का उपयोग करके कॉलमस्टैट चर की जाँच की जाती है। यह कोड खतरनाक क्यों है? पिछले उदाहरण की तरह, ऑपरेटर के साथ कास्टिंग विफल हो सकती है और चर शून्य हो जाएगा, जिसके परिणामस्वरूप अपवाद होगा। वैसे, यहां एक टाइपो को दोष दिया जा सकता है। इफ ब्लॉक में स्थिति पर एक नजर।

शायद, स्तम्भ के बजाय ??। क्या लेखक स्तम्भ लिखना चाहता था ? 2 .नाम । यह बहुत अधिक संभावना है, बल्कि दोषपूर्ण चर नामों के कॉलमस्टेट और कॉलमस्टैट 2 पर विचार कर रहा है।

निरर्थक जाँच

काफी संख्या में चेतावनी (100 से अधिक) गैर-राजनीतिक पर जारी की गई थी, लेकिन अनावश्यक रूप से अनावश्यक जांच से संबंधित निर्माण। उदाहरण के लिए, यह उनमें से एक है।

V3022 अभिव्यक्ति 'navInfo == null' हमेशा झूठी होती है। AbstractSyncClassViewCommandHandler.cs 101

 public bool ExecuteCommand(....) { .... IVsNavInfo navInfo = null; if (symbol != null) { navInfo = libraryService.NavInfoFactory.CreateForSymbol(....); } if (navInfo == null) { navInfo = libraryService.NavInfoFactory.CreateForProject(....); } if (navInfo == null) // <= { return true; } .... } public IVsNavInfo CreateForSymbol(....) { .... return null; } public IVsNavInfo CreateForProject(....) { return new NavInfo(....); } 

हो सकता है कि यहां कोई वास्तविक बग न हो। यह एक टो में काम करने वाले "इंटरप्रोसेक्शुअल एनालिसिस + डेटाफ्लो एनालिसिस" को प्रदर्शित करने का एक अच्छा कारण है। विश्लेषक दूसरी जांच में बताता है कि navInfo == अशक्त निरर्थक है। वास्तव में, इससे पहले कि यह navInfo को सौंपा गया मूल्य है, उसे पुस्‍तकालय सेवारत से मिल जाएगा। Service.NavInfoFactory.CreateForProject , जो NavInfo वर्ग की एक नई वस्‍तु का निर्माण और वापसी करेगा। किसी भी तरह से यह अशक्त नहीं लौटेगा। यहां यह सवाल उठता है कि विश्लेषक ने पहले चेक के लिए चेतावनी क्यों जारी नहीं की है == अशक्त ? कुछ कारण हैं। सबसे पहले, यदि प्रतीक चर शून्य है , तो navInfo मान एक अशक्त संदर्भ भी रहेगा। दूसरी बात, भले ही navInfo को ूप्स सर्विस से मूल्य मिल जाता है erviceService.NavInfoFactory.CreateForSymbol , यह मान भी शून्य हो सकता है। इस प्रकार, पहला चेक navInfo == नल वास्तव में आवश्यक है।

अपर्याप्त जाँच

अब ऊपर चर्चा से विपरीत स्थिति। कोड के लिए कई V3042 चेतावनी शुरू की गई थी, जिसमें अशक्त संदर्भ तक पहुंच संभव है। यहां तक ​​कि एक या दो छोटे चेक सब कुछ तय कर सकते थे।

आइए एक और दिलचस्प कोड टुकड़ा पर विचार करें, जिसमें दो ऐसी त्रुटियां हैं।

V3042 संभावित NullReferenceException। '?' और '' ऑपरेटरों का उपयोग 'रिसीवर' ऑब्जेक्ट Binder_Expressions.cs 7770 के सदस्यों तक पहुँचने के लिए किया जाता है

V3042 संभावित NullReferenceException। '?' और '' ऑपरेटरों का उपयोग 'रिसीवर' ऑब्जेक्ट Binder_Expressions.cs 7776 के सदस्यों तक पहुँचने के लिए किया जाता है

 private BoundExpression GetReceiverForConditionalBinding( ExpressionSyntax binding, DiagnosticBag diagnostics) { .... BoundExpression receiver = this.ConditionalReceiverExpression; if (receiver?.Syntax != // <= GetConditionalReceiverSyntax(conditionalAccessNode)) { receiver = BindConditionalAccessReceiver(conditionalAccessNode, diagnostics); } var receiverType = receiver.Type; // <= if (receiverType?.IsNullableType() == true) { .... } receiver = new BoundConditionalReceiver(receiver.Syntax, 0, // <= receiverType ?? CreateErrorType(), hasErrors: receiver.HasErrors) // <= { WasCompilerGenerated = true }; return receiver; } 

रिसीवर चर शून्य हो सकता है। कोड के लेखक को इसके बारे में पता है, क्योंकि वह रिसीवर को एक्सेस करने के लिए ब्लॉक की स्थिति में सशर्त नल ऑपरेटर का उपयोग करता है । सिंटैक्स । इसके अलावा रिसीवर वेरिएंट का उपयोग बिना किसी चेक के किया जाता है। इन त्रुटियों को ठीक किया जाना चाहिए:

 private BoundExpression GetReceiverForConditionalBinding( ExpressionSyntax binding, DiagnosticBag diagnostics) { .... BoundExpression receiver = this.ConditionalReceiverExpression; if (receiver?.Syntax != GetConditionalReceiverSyntax(conditionalAccessNode)) { receiver = BindConditionalAccessReceiver(conditionalAccessNode, diagnostics); } var receiverType = receiver?.Type; if (receiverType?.IsNullableType() == true) { .... } receiver = new BoundConditionalReceiver(receiver?.Syntax, 0, receiverType ?? CreateErrorType(), hasErrors: receiver?.HasErrors) { WasCompilerGenerated = true }; return receiver; } 

हमें यह भी सुनिश्चित करना होगा कि कंस्ट्रक्टर अपने मापदंडों के लिए शून्य मान प्राप्त करने का समर्थन करता है या हमें अतिरिक्त रीफैक्टरिंग करने की आवश्यकता है।

अन्य समान त्रुटियां:

• V3042 संभावित NullReferenceException। '?' और '' ऑपरेटरों का उपयोग ''TType' ऑब्जेक्ट के सदस्यों तक पहुँचने के लिए किया जाता है। SyntaxGeneratorExtensions_Negate.cs 240
• V3042 संभावित NullReferenceException। '?' और '' ऑपरेटरों का उपयोग 'अभिव्यक्ति' ऑब्जेक्ट एक्सप्रेशनसिनटैक्सएक्सएक्सएक्सएक्स.एससी 349 के सदस्यों तक पहुंचने के लिए किया जाता है
• V3042 संभावित NullReferenceException। '?' और '' ऑपरेटरों का उपयोग 'अभिव्यक्ति' ऑब्जेक्ट एक्सप्रेशनसिनटैक्सएक्सएक्सएक्सएक्स.एससी 349 के सदस्यों तक पहुंचने के लिए किया जाता है

हालत में त्रुटि

V3057 ' सब्स्ट्रिंग ' फ़ंक्शन '-1' मान प्राप्त कर सकता है जबकि गैर-नकारात्मक मान अपेक्षित है। दूसरे तर्क का निरीक्षण करें। CommonCommandLineParser.cs 109

 internal static bool TryParseOption(....) { .... if (colon >= 0) { name = arg.Substring(1, colon - 1); value = arg.Substring(colon + 1); } .... } 

यदि कोलन वैरिएबल 0 है, जो कोड में स्थिति के अनुसार ठीक है, तो मामले में, सबटाइटल विधि अपवाद को फेंक देगी। इसे ठीक करना होगा:

 if (colon > 0) 

संभव टाइपो

V3065 पैरामीटर 't2' का उपयोग विधि के शरीर के अंदर नहीं किया जाता है। CSharpCodeGenerationHelpers.cs 84

 private static TypeDeclarationSyntax ReplaceUnterminatedConstructs(....) { .... var updatedToken = lastToken.ReplaceTrivia(lastToken.TrailingTrivia, (t1, t2) => { if (t1.Kind() == SyntaxKind.MultiLineCommentTrivia) { var text = t1.ToString(); .... } else if (t1.Kind() == SyntaxKind.SkippedTokensTrivia) { return ReplaceUnterminatedConstructs(t1); } return t1; }); .... } 

लैम्ब्डा अभिव्यक्ति दो मापदंडों को स्वीकार करती है: t1 और t2। हालाँकि, केवल t1 का उपयोग किया जाता है। यह संदिग्ध लगता है, इस तथ्य को ध्यान में रखते हुए कि ऐसे नामों के साथ चर का उपयोग करते समय गलती करना कितना आसान है।

असावधानी

V3083 इवेंट 'TagsChanged', NullReferenceException का असुरक्षित आह्वान संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। पूर्वावलोकनUpdater.Tagger.cs 37

 public void OnTextBufferChanged() { if (PreviewUpdater.SpanToShow != default) { if (TagsChanged != null) { var span = _textBuffer.CurrentSnapshot.GetFullSpan(); TagsChanged(this, new SnapshotSpanEventArgs(span)); // <= } } } 

TagsChanged घटना असुरक्षित तरीके से लागू होती है। अशक्त की जाँच करने और घटना को लागू करने के बीच, कोई व्यक्ति इससे अनसब्सक्राइब कर सकता है, फिर एक अपवाद फेंक दिया जाएगा। इसके अलावा, अन्य ऑपरेशन अगर घटना को लागू करने से ठीक पहले ब्लॉक के शरीर में किए जाते हैं। मैंने इस त्रुटि को "असावधानी" कहा, क्योंकि इस घटना को अन्य जगहों पर अधिक सावधानी से संभाला गया है, इस प्रकार है:

 private void OnTrackingSpansChanged(bool leafChanged) { var handler = TagsChanged; if (handler != null) { var snapshot = _buffer.CurrentSnapshot; handler(this, new SnapshotSpanEventArgs(snapshot.GetFullSpan())); } } 

एक अतिरिक्त हैंडलर चर का उपयोग समस्या को रोकता है। OnTextBufferChanged विधि में , किसी को घटना को सुरक्षित रूप से संभालने के लिए संपादन करना पड़ता है।

अंतर्विरोधी पर्वतमाला

सशर्त अभिव्यक्तियों के भीतर V3092 रेंज चौराहे संभव हैं। उदाहरण: अगर (A> 0 && A <5) {...} और यदि (A> 3 && A <9) {...}। ILBuilderEmit.cs 677

 internal void EmitLongConstant(long value) { if (value >= int.MinValue && value <= int.MaxValue) { .... } else if (value >= uint.MinValue && value <= uint.MaxValue) { .... } else { .... } } 

बेहतर समझ के लिए, मैं अपने वास्तविक मूल्यों के साथ स्थिरांक के नाम को बदलते हुए, इस कोड को फिर से लिखना चाहता हूं:

 internal void EmitLongConstant(long value) { if (value >= -2147483648 && value <= 2147483648) { .... } else if (value >= 0 && value <= 4294967295) { .... } else { .... } } 

शायद, कोई वास्तविक त्रुटि नहीं है, लेकिन स्थिति अजीब दिखती है। इसका दूसरा भाग ( और यदि ) केवल 2147483648 + 1 से 4294967295 रेंज के लिए निष्पादित किया जाएगा।

इसी तरह की चेतावनी के एक और जोड़े:

• सशर्त अभिव्यक्तियों के भीतर V3092 रेंज चौराहे संभव हैं। उदाहरण: अगर (A> 0 && A <5) {...} और यदि (A> 3 && A <9) {...}। LocalRewriter_Literal.cs 109
• सशर्त अभिव्यक्तियों के भीतर V3092 रेंज चौराहे संभव हैं। उदाहरण: अगर (A> 0 && A <5) {...} और यदि (A> 3 && A <9) {...}। LocalRewriter_Literal.cs 66

अशक्त (या उनमें से कमी) के लिए जाँच के बारे में अधिक

इसके उपयोग के बाद शून्य के लिए एक चर के चेक पर V3095 त्रुटियों की एक जोड़ी। पहला अस्पष्ट है, आइए कोड पर विचार करें।

V3095 नल के खिलाफ सत्यापित होने से पहले 'displayName' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइन: 498, 503. फ्यूजनएएसएसडिमेन्डिटी.एससी 498

 internal static IAssemblyName ToAssemblyNameObject(string displayName) { if (displayName.IndexOf('\0') >= 0) { return null; } Debug.Assert(displayName != null); .... } 

यह माना जाता है कि संदर्भ डिस्प्लेनाम शून्य हो सकता है। इसके लिए, चेक डीबग.एजर्स की जाँच की गई। यह स्पष्ट नहीं है कि स्ट्रिंग का उपयोग करने के बाद यह क्यों जाता है। यह भी ध्यान में रखा जाना चाहिए कि डिबग से अलग कॉन्फ़िगरेशन के लिए, कंपाइलर डिबग को हटा देगा । क्या इसका मतलब है कि केवल डिबग के लिए एक शून्य संदर्भ प्राप्त करना संभव है? यदि ऐसा नहीं है, तो लेखक ने स्ट्रिंग की जांच क्यों की। उदाहरण के लिए NullOrEmpty (स्ट्रिंग) । यह कोड के लेखकों के लिए सवाल है।

निम्नलिखित त्रुटि अधिक स्पष्ट है।

V3095 नल के खिलाफ सत्यापित होने से पहले 'scriptArgsOpt' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 321, 325. कॉमनकॉमनलाइनपैर। 321

 internal void FlattenArgs(...., List<string> scriptArgsOpt, ....) { .... while (args.Count > 0) { .... if (parsingScriptArgs) { scriptArgsOpt.Add(arg); // <= continue; } if (scriptArgsOpt != null) { .... } .... } } 

मुझे लगता है कि इस कोड को किसी स्पष्टीकरण की आवश्यकता नहीं है। मुझे आपको निश्चित संस्करण देने दें:

 internal void FlattenArgs(...., List<string> scriptArgsOpt, ....) { .... while (args.Count > 0) { .... if (parsingScriptArgs) { scriptArgsOpt?.Add(arg); continue; } if (scriptArgsOpt != null) { .... } .... } } 

रोसलिन कोड में, 15 और समान त्रुटियां थीं:

• V3095 नल के खिलाफ सत्यापित होने से पहले 'LocalFunctions' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 289, 317. ControlFlowGraphBuilder.RegionBuilder.cs 289
• V3095 'रिज़ॉल्यूशन .verloadResolutionResult' ऑब्जेक्ट का उपयोग इससे पहले कि वह अशक्त के खिलाफ सत्यापित किया गया था। चेक लाइनें: 579, 588. बाइंडर_इनवोकेशन.के 579
• V3095 'रिज़ॉल्यूशन। मीथोडग्रुप' ऑब्जेक्ट का उपयोग शून्य से पहले सत्यापित होने से पहले किया गया था। चेक लाइन: 592, 621. बाइंडर_ इनवोकेशन.के 592
• V3095 अशक्त के खिलाफ सत्यापित होने से पहले 'छुआ-छींटा Logger' ऑब्जेक्ट का उपयोग किया गया था। जाँच लाइनें: 111, 126. CSharpCompiler.cs 111
• V3095 नल के खिलाफ सत्यापित होने से पहले 'newExceptionRegionsOpt' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 736, 743. AbstractEditAndContinueAnalyzer.cs 736
• V3095 नल के खिलाफ सत्यापित होने से पहले 'प्रतीक' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 422, 427. AbstractGenerateConstructorService.Editor.cs 422
• V3095 नल के खिलाफ सत्यापित होने से पहले '_state.BaseTypeOrInterfaceOpt' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 132, 140। AbstractGenerateTypeService.GenerateNamedType.cs 132
• V3095 नल के खिलाफ सत्यापित होने से पहले 'एलिमेंट' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइन: 232, 233. प्रोजेक्टयूलेट .cs 232
• V3095 नल के खिलाफ सत्यापित होने से पहले 'भाषा' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइन: 22, 28. ExportCodeCleanupProvider.cs 22
• V3095 नल के खिलाफ सत्यापित होने से पहले 'सदस्य टाइप' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइन: 183, 184. सिंटैक्सजेनरेटरएक्स्टेंशन_क्रिएटगेट हैशकोडमैथोड्स। 183
• V3095 नल के खिलाफ सत्यापित होने से पहले 'मान्यटाइपडक्लेरेशन' ऑब्जेक्ट का उपयोग किया गया था। जाँच रेखाएँ: 223, 228. सिंटेक्सट्रीक्स्टेन्शन्स.cs 223
• V3095 नल के खिलाफ सत्यापित होने से पहले 'टेक्स्ट' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 376, 385. MSBuildWorkspace.cs 376
• V3095 नल के खिलाफ सत्यापित होने से पहले 'nameOrMemberAccessExpression' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 206, 223. CSharpGenerateTypeService.cs 206
• V3095 नल के खिलाफ सत्यापित होने से पहले 'simpleName' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 83, 85. CSharpGenerateMethodService.cs 83
• V3095 नल के खिलाफ सत्यापित होने से पहले 'विकल्प' ऑब्जेक्ट का उपयोग किया गया था। चेक लाइनें: 23, 28. OptionKey.cs 23

आइए V3105 त्रुटियों पर विचार करें। यहां सशर्त नल ऑपरेटर का उपयोग वैरिएबल को इनिशियलाइज़ करते समय किया जाता है, लेकिन आगे वैरिएबल का उपयोग बिना जाँच के किया जाता है।

दो चेतावनियाँ निम्न त्रुटि दर्शाती हैं:

V3105 शून्य-सशर्त ऑपरेटर के माध्यम से असाइन किए जाने के बाद 'documentId' चर का उपयोग किया गया था। NullReferenceException संभव है। CodeLensReferencesService.cs 138

V3105 शून्य-सशर्त ऑपरेटर के माध्यम से असाइन किए जाने के बाद 'documentId' चर का उपयोग किया गया था। NullReferenceException संभव है। CodeLensReferencesService.cs 139

 private static async Task<ReferenceLocationDescriptor> GetDescriptorOfEnclosingSymbolAsync(....) { .... var documentId = solution.GetDocument(location.SourceTree)?.Id; return new ReferenceLocationDescriptor( .... documentId.ProjectId.Id, documentId.Id, ....); } 

डॉक्यूमेंटआईड वैरिएबल को null द्वारा प्रारंभ किया जा सकता है। नतीजतन, एक ऑब्जेक्ट ReferenceLocationDescriptor बनाने के परिणामस्वरूप एक अपवाद फेंक दिया जाएगा। कोड निश्चित होना चाहिए:

 return new ReferenceLocationDescriptor( .... documentId?.ProjectId.Id, documentId?.Id, ....); 

डेवलपर्स को एक कंस्ट्रक्टर को पारित होने वाले चर की संभावना को भी शून्य होना चाहिए ।

कोड में अन्य समान त्रुटियां:

• V3105 'प्रतीक' चर का उपयोग अशक्त-सशर्त ऑपरेटर के माध्यम से सौंपा जाने के बाद किया गया था। NullReferenceException संभव है। SymbolFinder_Hierarchy.cs 44
• V3105 'प्रतीक' चर का उपयोग अशक्त-सशर्त ऑपरेटर के माध्यम से सौंपा जाने के बाद किया गया था। NullReferenceException संभव है। SymbolFinder_Hierarchy.cs 51

प्राथमिकताएं और कोष्ठक

V3123 शायद '?:' ऑपरेटर अपेक्षा से अलग तरीके से काम करता है। इसकी प्राथमिकता इसकी स्थिति में अन्य ऑपरेटरों की प्राथमिकता से कम है। Edit.cs 70

 public bool Equals(Edit<TNode> other) { return _kind == other._kind && (_oldNode == null) ? other._oldNode == null : _oldNode.Equals(other._oldNode) && (_newNode == null) ? other._newNode == null : _newNode.Equals(other._newNode); } 

रिटर्न ब्लॉक में स्थिति का मूल्यांकन डेवलपर के अनुसार नहीं किया जाता है। यह मान लिया गया था कि पहली स्थिति _kind == other._kin d होगी, (इस कारण इस स्थिति के बाद एक लाइन ब्रेक है), और उसके बाद ऑपरेटर के साथ शर्तों के ब्लॉक " ? " का मूल्यांकन अनुक्रम में किया जाएगा। वास्तव में, पहली स्थिति _kind == other._kind && (_oldNode == null) है । यह इस तथ्य के कारण है कि ऑपरेटर और& में ऑपरेटर की तुलना में अधिक प्राथमिकता है " ? "। इसे ठीक करने के लिए, एक डेवलपर को ऑपरेटर के सभी अभिव्यक्तियों को लेना चाहिए "" ? कोष्ठक में:

 return _kind == other._kind && ((_oldNode == null) ? other._oldNode == null : _oldNode.Equals(other._oldNode)) && ((_newNode == null) ? other._newNode == null : _newNode.Equals(other._newNode)); 

यह मेरे द्वारा पाई गई त्रुटियों के विवरण को समाप्त करता है।

निष्कर्ष

बड़ी संख्या में त्रुटियों के बावजूद, जो मैंने रोजलिन परियोजना कोड (2,770,000 लाइनों) के आकार के संदर्भ में पाया, यह बहुत ज्यादा नहीं है। जैसा कि एंड्री ने पिछले लेख में लिखा था, मैं इस परियोजना की उच्च गुणवत्ता को स्वीकार करने के लिए भी तैयार हूं।

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

आप अपने आप को इस परियोजना में और दूसरे में दोनों त्रुटियों की जांच कर सकते हैं। ऐसा करने के लिए, आपको बस हमारे विश्लेषक को डाउनलोड करने और प्रयास करने की आवश्यकता है।