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

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

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

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

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

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

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

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

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

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

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

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; } 

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

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

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 (स्ट्रिंग, बूल) विधि का परिणाम लौटाएगा , जिसका मूल्य शून्य हो सकता है। चूंकि आगे ExpandFileNamePattern पद्धति के शरीर में अशक्त समानता के लिए पहली जाँच के बिना निर्देशिका चर का उपयोग किया जाता है, हम विश्लेषक द्वारा चेतावनी की वैधता के बारे में बात कर सकते हैं। यह एक संभावित असुरक्षित डिजाइन है।

कोड का एक और टुकड़ा 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; } 

विधि छोटा है, इसलिए मैं इसका पूरा कोड देता हूं। रिटर्न ब्लॉक में स्थिति गलत है। कुछ मामलों में, टाइप करते समय NullReferenceException को फेंकना संभव है। FullName । मैं स्थिति स्पष्ट करने के लिए कोष्ठक (वे यहाँ व्यवहार नहीं बदलेंगे) का उपयोग करते हैं:

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

इस तरह, संचालन की प्राथमिकता के अनुसार, यह कोड काम करेगा। यदि प्रकार चर शून्य है , तो हम एक और जांच में शामिल होते हैं, जहां, सुनिश्चित करें कि 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 प्रकार का है। समस्या इस जाँच का अनुसरण कर रही है। भले ही मान चर शून्य नहीं है, लेकिन यह गारंटी नहीं देता है कि प्रकार रूपांतरण सफल रहा था और मान को समरूपता में शून्य नहीं होना चाहिए। 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, // <= ....)); } .... } .... } 

वेरिएबल कॉलमस्टेट ColumnState2 प्रकार का है। हालांकि, ऑपरेशन का परिणाम, चर columnState2 , null के लिए आगे की जाँच नहीं है। इसके बजाय, सशर्त स्तंभ कथन का उपयोग करके चर स्तम्भन की जाँच की जाती है। इस कोड का खतरा क्या है? पिछले उदाहरण के रूप में, ऑपरेटर के रूप में उपयोग करने वाले कास्टिंग विफल हो सकते हैं, और कॉलमस्टेट 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 को असाइन करने के लिए मूल्य LibraryService.NavInfoFactory.CreateForProject विधि से प्राप्त किया जाएगा, जो NavInfo वर्ग की एक नई वस्तु का निर्माण और वापसी करेगा। लेकिन किसी भी तरह से अशक्त नहीं। सवाल यह है कि, विश्लेषक ने पहले चेक navInfo == null के लिए चेतावनी क्यों नहीं दी? इसके लिए एक स्पष्टीकरण है। सबसे पहले, यदि प्रतीक चर शून्य हो जाता है, तो navInfo का मान एक शून्य संदर्भ बना रहेगा। दूसरे, भले ही navInfo को LibraryService.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 है, जो कोड में एक स्थिति की अनुमति देता है, तो सब्स्टीट्यूटिंग विधि एक ArgumentOutOfRadException को फेंक देगी । सुधार आवश्यक:

 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; }); .... } 

दो मापदंडों को लैम्ब्डा अभिव्यक्ति में पास किया जाता है: टी 1 और टी 2। हालाँकि, केवल 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)); // <= } } } 

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

 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 नल के खिलाफ सत्यापित होने से पहले 'मान्यटाइपडक्लेरेशन' ऑब्जेक्ट का उपयोग किया गया था। Check lines: 223, 228. SyntaxTreeExtensions.cs 223
• V3095 The 'text' object was used before it was verified against null. Check lines: 376, 385. MSBuildWorkspace.cs 376
• V3095 The 'nameOrMemberAccessExpression' object was used before it was verified against null. Check lines: 206, 223. CSharpGenerateTypeService.cs 206
• V3095 The 'simpleName' object was used before it was verified against null. Check lines: 83, 85. CSharpGenerateMethodService.cs 83
• V3095 The 'option' object was used before it was verified against null. Check lines: 23, 28. OptionKey.cs 23

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

अगली त्रुटि को दो चेतावनियों द्वारा तुरंत संकेत दिया जाता है।

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

V3105 'डॉक्यूमेंटआईड' वैरिएबल का उपयोग तब किया गया था जब इसे नल-सशर्त ऑपरेटर के माध्यम से सौंपा गया था। 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, ....); } 

चर डॉक्युमेंटआईड को शून्य से आरंभ किया जा सकता है । नतीजतन, 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 पंक्तियों) के आकार के संदर्भ में, मैं जिन त्रुटियों का पता लगाने में सक्षम था, उनकी महत्वपूर्ण संख्या के बावजूद, यह काफी कम राशि होगी। पिछले लेख में आंद्रेई की तरह, मैं भी इस परियोजना की उच्च गुणवत्ता को पहचानने के लिए तैयार हूं।

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

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

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: सर्गेई ख्रेनोव। रोजलिन सोर्स कोड की जाँच करना ।