Infer.NET कोड में क्या त्रुटियां छिपी हैं?

Microsoft का अपनी परियोजनाओं के लिए स्रोत कोड का प्रकाशन उन्हें सत्यापित करने का एक अच्छा कारण है। यह समय कोई अपवाद नहीं था, और आज हम Infer.NET कोड में पाए गए संदिग्ध स्थानों को देखते हैं। एनोटेशन के साथ नीचे - बिंदु पर पहुंचें!

परियोजना और विश्लेषक के बारे में थोड़ा सा

Infer.NET Microsoft से विशेषज्ञों द्वारा विकसित एक मशीन सीखने की प्रणाली है। परियोजना का स्रोत कोड हाल ही में GitHub पर उपलब्ध हो गया है , जो इसके सत्यापन का कारण था। उदाहरण के लिए, परियोजना के बारे में अधिक विवरण यहां पाया जा सकता है ।

पीवीएस-स्टूडियो संस्करण 6.26 स्थिर विश्लेषक का उपयोग करके परियोजना की जांच की गई थी। आपको याद दिला दूं कि पीवीएस-स्टूडियो विंडोज, लिनक्स, मैकओएस के तहत C \ C ++ \ C # (और जल्द ही जावा में) कोड में त्रुटियों की तलाश कर रहा है। C # कोड अब तक हम केवल विंडोज के तहत विश्लेषण कर रहे हैं। विश्लेषक को आपके प्रोजेक्ट पर डाउनलोड और आज़माया जा सकता है।

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

वैसे, पीवीएस-स्टूडियो का उपयोग करके Microsoft द्वारा परीक्षण किया गया यह पहला प्रोजेक्ट नहीं है - अन्य थे: रोसलिन , MSBuild , PowerShell , CoreFX और अन्य ।

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

लेकिन पर्याप्त सार बात - चलो कोड में समस्याओं को देखें।

यह एक बग या एक सुविधा है?

मेरा सुझाव है कि त्रुटि को स्वयं खोजने की कोशिश करें - एक पूरी तरह से हल करने योग्य कार्य। " 2017 के लिए सी ++ प्रोजेक्ट्स में शीर्ष 10 त्रुटियों " लेख में ईमानदारी से कोई मजाक नहीं किया गया था। तो कोड स्निपेट के बाद प्रदान की गई विश्लेषक चेतावनी को पढ़ने में जल्दबाजी न करें।

private void MergeParallelTransitions() { .... if ( transition1.DestinationStateIndex == transition2.DestinationStateIndex && transition1.Group == transition2.Group) { if (transition1.IsEpsilon && transition2.IsEpsilon) { .... } else if (!transition1.IsEpsilon && !transition2.IsEpsilon) { .... if (double.IsInfinity(transition1.Weight.Value) && double.IsInfinity(transition1.Weight.Value)) { newElementDistribution.SetToSum( 1.0, transition1.ElementDistribution, 1.0, transition2.ElementDistribution); } else { newElementDistribution.SetToSum( transition1.Weight.Value, transition1.ElementDistribution, transition2.Weight.Value, transition2.ElementDistribution); } .... } 

PVS-Studio चेतावनी : V3001 समान उप-अभिव्यक्तियाँ हैं 'डबल.इन्स.इनफ़िनिटी (ट्रांज़िशन 1. वाइट.वैल्यू)' बाईं ओर और '&&' ऑपरेटर के दाईं ओर। रनटाइम ऑटोमैटन.सिम्प्लीफिकेशन .cs 479

जैसा कि आप कोड स्निपेट से देख सकते हैं, विधि चर की एक जोड़ी के साथ काम कर रही है - ट्रांज़िशन 1 और ट्रांज़िशन 2 । समान नामों का उपयोग कभी-कभी काफी न्यायसंगत होता है, लेकिन यह याद रखने योग्य है कि इस मामले में नाम के साथ गलती से कहीं गलती होने की संभावना बढ़ जाती है।

यह तब होता है जब अनन्तता के लिए संख्याओं की जांच ( डबल.ई.इनफिनिटी )। एक त्रुटि के कारण, हमने एक ही चर के मूल्य को 2 बार जांचा - Trans1.1ight.Value । दूसरे सबडिप्रेशन में जाँच किया गया मान परिवर्तनशील होना चाहिए था।

एक और समान संदिग्ध कोड।

 internal MethodBase ToMethodInternal(IMethodReference imr) { .... bf |= BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance; .... } 

PVS-Studio चेतावनी : V3001 समान उप-अभिव्यक्तियाँ हैं 'BindingFlags.Public' बाईं ओर और 'दाईं ओर' है। ऑपरेटर। संकलक CodeBuilder.cs 194

Bf वैरिएबल का मान बनाते समय, BindingFlags.Public गणन तत्व का उपयोग दो बार किया जाता है। या तो इस कोड में एक अतिरिक्त फ़्लैगिंग ऑपरेशन होता है, या BindingFlags.Public के दूसरे उपयोग के बजाय , एक अलग गणना मूल्य होना चाहिए।

वैसे, सोर्स कोड में यह कोड एक लाइन पर लिखा होता है। यह मुझे लगता है कि अगर यह एक तालिका शैली (जैसे यहां) में स्वरूपित है, तो समस्या का पता लगाना आसान है।

चलो आगे बढ़ते हैं। मैं विधि के पूरे शरीर को ले आता हूं और फिर से सुझाव देता हूं कि आप स्वयं त्रुटि (या शायद त्रुटि) का पता लगाएं।

 private void ForEachPrefix(IExpression expr, Action<IExpression> action) { // This method must be kept consistent with GetTargets. if (expr is IArrayIndexerExpression) ForEachPrefix(((IArrayIndexerExpression)expr).Target, action); else if (expr is IAddressOutExpression) ForEachPrefix(((IAddressOutExpression)expr).Expression, action); else if (expr is IPropertyReferenceExpression) ForEachPrefix(((IPropertyReferenceExpression)expr).Target, action); else if (expr is IFieldReferenceExpression) { IExpression target = ((IFieldReferenceExpression)expr).Target; if (!(target is IThisReferenceExpression)) ForEachPrefix(target, action); } else if (expr is ICastExpression) ForEachPrefix(((ICastExpression)expr).Expression, action); else if (expr is IPropertyIndexerExpression) ForEachPrefix(((IPropertyIndexerExpression)expr).Target, action); else if (expr is IEventReferenceExpression) ForEachPrefix(((IEventReferenceExpression)expr).Target, action); else if (expr is IUnaryExpression) ForEachPrefix(((IUnaryExpression)expr).Expression, action); else if (expr is IAddressReferenceExpression) ForEachPrefix(((IAddressReferenceExpression)expr).Expression, action); else if (expr is IMethodInvokeExpression) ForEachPrefix(((IMethodInvokeExpression)expr).Method, action); else if (expr is IMethodReferenceExpression) ForEachPrefix(((IMethodReferenceExpression)expr).Target, action); else if (expr is IUnaryExpression) ForEachPrefix(((IUnaryExpression)expr).Expression, action); else if (expr is IAddressReferenceExpression) ForEachPrefix(((IAddressReferenceExpression)expr).Expression, action); else if (expr is IDelegateInvokeExpression) ForEachPrefix(((IDelegateInvokeExpression)expr).Target, action); action(expr); } 

क्या आपने पाया है? हम जाँच कर रहे हैं!

पीवीएस-स्टूडियो चेतावनी :

• V3003 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। लाइनों की जाँच करें: 1719, 1727। कंपाइलर कोडक्रीग्नाइजर। 1719
• V3003 'if (A) {...} का उपयोग if (A) {...}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। जाँच लाइनें: १ec२१, १.२ ९। कंपाइलर कोडक्रीग्नाइज़र। १ .२१

समस्याओं को अधिक स्पष्ट करने के लिए कोड को थोड़ा सरल करें।

 private void ForEachPrefix(IExpression expr, Action<IExpression> action) { if (....) .... else if (expr is IUnaryExpression) ForEachPrefix(((IUnaryExpression)expr).Expression, action); else if (expr is IAddressReferenceExpression) ForEachPrefix(((IAddressReferenceExpression)expr).Expression, action); .... else if (expr is IUnaryExpression) ForEachPrefix(((IUnaryExpression)expr).Expression, action); else if (expr is IAddressReferenceExpression) ForEachPrefix(((IAddressReferenceExpression)expr).Expression, action) .... } 

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

• यदि सशर्त अभिव्यक्ति सही है, तो पहले का शरीर यदि संबंधित जोड़ी से कथन निष्पादित किया जाता है;
• यदि पहले मामले में सशर्त अभिव्यक्ति झूठी है, तो यह दूसरे में गलत होगी।

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

हम जारी रखते हैं।

 public int Compare(Pair<int, int> x, Pair<int, int> y) { if (x.First < y.First) { if (x.Second >= y.Second) { // y strictly contains x return 1; } else { // No containment - order by left bound return 1; } } else if (x.First > y.First) { if (x.Second <= y.Second) { // x strictly contains y return -1; } else { // No containment - order by left bound return -1; } } .... } 

पीवीएस-स्टूडियो चेतावनी :

• V3004 'तत्कालीन' कथन 'और' कथन के बराबर है। रनटाइम रेगेक्सप्रीब्रीस्ट.ल 1080
• V3004 'तत्कालीन' कथन 'और' कथन के बराबर है। रंटाइम रेगेक्सप्रीब्रीबुल। 1093

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

दिलचस्प चक्र थे। नीचे उदाहरण:

 private static Set<StochasticityPattern> IntersectPatterns(IEnumerable<StochasticityPattern> patterns) { Set<StochasticityPattern> result = new Set<StochasticityPattern>(); result.AddRange(patterns); bool changed; do { int count = result.Count; AddIntersections(result); changed = (result.Count != count); break; } while (changed); return result; } 

पीवीएस-स्टूडियो चेतावनी : V3020 एक लूप के भीतर बिना शर्त 'ब्रेक'। कंपाइलर DefaultFactorManager.cs 474

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

एक ही विधि (सटीक प्रतिलिपि) दूसरी कक्षा में पाई गई थी। संवाददाता की चेतावनी के अनुरूप: V3020 लूप के भीतर बिना शर्त 'ब्रेक'। विज़ुअलाइज़र। विंडोज़ फैक्टरमॉन्गरएव्यू.क्स 350

वैसे, एक विधि लूप में बिना शर्त जारी स्टेटमेंट के साथ मिली (यह उसी डायग्नोस्टिक्स के साथ विश्लेषक द्वारा पाया गया था), लेकिन ऊपर एक टिप्पणी थी जो यह पुष्टि करती है कि यह एक विशेष अस्थायी समाधान है:

 // TEMPORARY continue; 

मुझे याद है कि बिना शर्त ब्रेक स्टेटमेंट के पास ऐसी कोई टिप्पणी नहीं थी।

चलो आगे बढ़ते हैं।

 internal static DependencyInformation GetDependencyInfo(....) { .... IExpression resultIndex = null; .... if (resultIndex != null) { if (parameter.IsDefined( typeof(SkipIfMatchingIndexIsUniformAttribute), false)) { if (resultIndex == null) throw new InferCompilerException( parameter.Name + " has SkipIfMatchingIndexIsUniformAttribute but " + StringUtil.MethodNameToString(method) + " has no resultIndex parameter"); .... } .... } .... } 

पीवीएस-स्टूडियो चेतावनी : V3022 एक्सप्रेशन 'resultIndex == null' हमेशा गलत होता है। संकलक FactorManager.cs 382

तुरंत, मैं ध्यान देता हूं कि घोषणा और उपरोक्त सत्यापन के बीच, resultIndex चर का मूल्य बदल सकता है। हालाँकि, चेक resultIndex! = Null और resultIndex == null के बीच, मान पहले से नहीं बदला जा सकता है। इसलिए, अभिव्यक्ति का परिणाम Index == अशक्त हमेशा गलत होगा , जिसका अर्थ है कि एक अपवाद कभी नहीं फेंका जाएगा।

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

 public static Tuple<int, string> ComputeMovieGenre(int offset, string feature) { string[] genres = feature.Split('|'); if (genres.Length < 1 && genres.Length > 3) { throw new ArgumentException(string.Format( "Movies should have between 1 and 3 genres; given {0}.", genres.Length)); } double value = 1.0 / genres.Length; var result = new StringBuilder( string.Format( "{0}:{1}", offset + MovieGenreBuckets[genres[0]], value)); for (int i = 1; i < genres.Length; ++i) { result.Append( string.Format( "|{0}:{1}", offset + MovieGenreBuckets[genres[i].Trim()], value)); } return new Tuple<int, string>(MovieGenreBucketCount, result.ToString()); } 

देखते हैं कि यहां क्या होता है। इनपुट स्ट्रिंग वर्ण द्वारा पार्स की गई है '|' यदि सरणी की लंबाई अपेक्षा के अनुरूप नहीं है, तो अपवाद को फेंक दिया जाना चाहिए। एक दूसरी प्रतीक्षा करें ... genres.Length <1 && genres.Length> 3 ? चूंकि कोई संख्या नहीं है जो तुरंत अभिव्यक्ति ( [int.MinValue..1) और (3..int.MaxValue] ) द्वारा आवश्यक मूल्यों की सीमा में आती है, अभिव्यक्ति का परिणाम हमेशा गलत होगा । इसलिए, यह चेक किसी भी चीज़ से रक्षा नहीं करता है, और अपेक्षित अपवाद नहीं फेंका जाएगा।

यह वही है जो विश्लेषक इस बारे में चेतावनी देता है: V3022 एक्सप्रेशन 'genres.Length <1 && genres.Length> 3' हमेशा गलत होता है। शायद '||' ऑपरेटर को यहां इस्तेमाल किया जाना चाहिए। मूल्यांकनकर्ता विशेषताएँ। 242

संदिग्ध विखंडन ऑपरेशन मिले।

 public static void CreateTrueThetaAndPhi(....) { .... double expectedRepeatOfTopicInDoc = averageDocLength / numUniqueTopicsPerDoc; .... int cnt = Poisson.Sample(expectedRepeatOfTopicInDoc); .... } 

PVS-Studio चेतावनी : V3041 अभिव्यक्ति को 'int' प्रकार से 'डबल' प्रकार में डाला गया था। एक आंशिक भाग के नुकसान से बचने के लिए एक स्पष्ट प्रकार के कलाकारों का उपयोग करने पर विचार करें। एक उदाहरण: डबल ए = (डबल) (एक्स) / वाई ;; LDA यूटिलिटीज .cs 74

यह यहां संदेहास्पद है: पूर्णांक विभाजन किया जाता है (चर औसतविकास और न्यूमनीकॉटिक्सपेरडोक प्रकार के होते हैं), और परिणाम टाइप डबल के एक चर को लिखा जाता है। प्रश्न यह है: क्या यह विशेष रूप से किया गया है, या वास्तविक संख्याओं का विभाजन अभी भी निहित है? यदि अपेक्षित रिपेटऑउटऑप्टिकइंनडॉक वैरिएबल इंट के प्रकार के होते हैं, तो इससे संभावित प्रश्न साफ ​​हो जाएंगे।

अन्य स्थानों में, Poisson.Sample विधि, का तर्क जो संदेहास्पद चर अपेक्षित है । RepeatOfTopicInDoc , उदाहरण के लिए, नीचे वर्णित है।

 int numUniqueWordsPerTopic = Poisson.Sample((double)averageWordsPerTopic); 

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

और यहाँ उपयोग की एक और जगह है:

 double expectedRepeatOfWordInTopic = ((double)numDocs) * averageDocLength / numUniqueWordsPerTopic; .... int cnt = Poisson.Sample(expectedRepeatOfWordInTopic); 

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

सामान्य तौर पर, यह शुरुआती जगह पर देखने लायक है जहां विश्लेषक ने चेतावनी जारी की है।

लेकिन क्या यह संपादन के लायक है और कैसे, इस पर विचार करते हैं, कोड के लेखकों को (वे बेहतर जानते हैं), लेकिन हमें आगे जाने दें। अगले संदिग्ध विभाग में।

 public static NonconjugateGaussian BAverageLogarithm(....) { .... double v_opt = 2 / 3 * (Math.Log(mx * mz / Ex2 / 2) - m); if (v_opt != v) { .... } .... } 

PVS-Studio चेतावनी : V3041 अभिव्यक्ति को 'int' प्रकार से 'डबल' प्रकार में डाला गया था। एक आंशिक भाग के नुकसान से बचने के लिए एक स्पष्ट प्रकार के कलाकारों का उपयोग करने पर विचार करें। एक उदाहरण: डबल ए = (डबल) (एक्स) / वाई ;; रनटाइम ProductExp.cs 137

विश्लेषक ने पूर्णांक विभाजन के संदिग्ध संचालन का फिर से पता लगाया, जैसा कि 2 और 3 पूर्णांक संख्यात्मक शाब्दिक हैं, और अभिव्यक्ति 2/3 का परिणाम 0 होगा। परिणामस्वरूप, संपूर्ण अभिव्यक्ति का रूप लेता है:

 double v_opt = 0 * expr; 

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

लेकिन फिर यह मुझ पर हावी हो गया - मुझे 0/3 के रूप में लिखे गए 0 के कारक की आवश्यकता क्यों है? तो यह जगह वैसे भी देखने लायक है।

 public static void WriteAttribute(TextWriter writer, string name, object defaultValue, object value, Func<object, string> converter = null) { if ( defaultValue == null && value == null || value.Equals(defaultValue)) { return; } string stringValue = converter == null ? value.ToString() : converter(value); writer.Write($"{name}=\"{stringValue}\" "); } 

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

हालत के आधार पर विश्लेषक का काफी उचित दावा। अशक्त संदर्भ की डीफ्रेंसिंग अभिव्यक्ति मान में हो सकती है। मान (डिफ़ॉल्ट) यदि मान == शून्य है । चूँकि यह एक्सप्रेशन सही ऑपरेटर का है। ऑपरेटर, इसे कैलकुलेट करने के लिए, बाएं ऑपरेंड झूठा होना चाहिए, और इसके लिए यह पर्याप्त है कि कम से कम एक डिफ़ॉल्टवैल्यू \ वैल्यू वैरिएबल अशक्त न हो। परिणामस्वरूप, अगर defaultValue! = Null , और value == null :

• defaultValue == null -> गलत ;
• defaultValue == null && value == null -> गलत ; ( मूल्य की जांच नहीं हुई)
• value.Equals (defaultValue) -> NullReferenceException , चूंकि मान शून्य है ।

आइए एक ऐसे ही मामले को देखें:

 public FeatureParameterDistribution( GaussianMatrix traitFeatureWeightDistribution, GaussianArray biasFeatureWeightDistribution) { Debug.Assert( (traitFeatureWeightDistribution == null && biasFeatureWeightDistribution == null) || traitFeatureWeightDistribution.All( w => w != null && w.Count == biasFeatureWeightDistribution.Count), "The provided distributions should be valid and consistent in the number of features."); .... } 

पीवीएस-स्टूडियो चेतावनी : V3080 संभावित अशांति । निरीक्षण करने पर विचार करें 'traitFeatureWeightDistribution'। सिफारिश करने वाला फ़ीचरपैरमीटरडिस्ट्रिब्यूशन.केएस 65

हम बूलियन मूल्यों की गणना के लिए केवल तर्क छोड़ कर, अतिरिक्त फेंक देते हैं, ताकि यह पता लगाना आसान हो:

 (traitFeatureWeightDistribution == null && biasFeatureWeightDistribution == null) || traitFeatureWeightDistribution.All( w => w != null && w.Count == biasFeatureWeightDistribution.Count) 

फिर से, सही संचालन || इसकी गणना केवल तभी की जाती है जब बाईं गणना का परिणाम गलत होता है । बाएं ऑपरेंड गलत हो सकता है , जब traitFeatureWeightDistribution == null और biasFeatureWeightDistribution! = Null शामिल है । तब के सही ऑपरेंड || ऑपरेटर की गणना की जाएगी, और traitFeatureWeightDistribution के लिए एक कॉल किया जाएगा। सभी एक ArgumentNullException उठाएंगे ।

कोड का एक और दिलचस्प टुकड़ा:

 public static double GetQuantile(double probability, double[] quantiles) { .... int n = quantiles.Length; if (quantiles == null) throw new ArgumentNullException(nameof(quantiles)); if (n == 0) throw new ArgumentException("quantiles array is empty", nameof(quantiles)); .... } 

पीवीएस-स्टूडियो चेतावनी : V3095 ' क्वांटाइल्स ' ऑब्जेक्ट का उपयोग इससे पहले किया गया था जब इसे शून्य के खिलाफ सत्यापित किया गया था। चेक लाइनें: 91, 92. रनटाइम ओवरएटरक्वांटाइल्स.केएस 91

ध्यान दें कि quantiles.Length प्रॉपर्टी पहले एक्सेस की जाती है , और फिर null के लिए क्वांटाइल्स की जाँच की जाती है। नतीजतन, अगर क्वांटाइल्स == अशक्त है , तो विधि एक अपवाद फेंक देगी, बस थोड़ा सा गलत है, और थोड़ा नहीं जहां इसकी आवश्यकता थी। जाहिर है, उन्होंने स्थानों में लाइनों को गड़बड़ कर दिया।

यदि आपने पहले की त्रुटियों का स्वयं पता लगा लिया है, तो मैं आपको एक कप कॉफी बनाने की सलाह देता हूं और नीचे दी गई विधि में त्रुटि का पता लगाते हुए करतब दोहराने की कोशिश करता हूं। इसे थोड़ा और दिलचस्प बनाने के लिए, मैं विधि के पूरे कोड को उद्धृत करता हूं।

( फुलसाइज़ से लिंक करें )

ठीक है, ठीक है, यह एक मजाक था (या क्या आप सफल हुए?!)। आइए कार्य को थोड़ा सरल करें:

 if (sample.Precision < 0) { precisionIsBetween = true; lowerBound = -1.0 / v; upperBound = -mean.Precision; } else if (sample.Precision < -mean.Precision) { precisionIsBetween = true; lowerBound = 0; upperBound = -mean.Precision; } else { // in this case, the precision should NOT be in this interval. precisionIsBetween = false; lowerBound = -mean.Precision; lowerBound = -1.0 / v; } 

क्या यह बेहतर हो गया है? विश्लेषक ने इस कोड के लिए निम्नलिखित चेतावनी जारी की: V3008 'लोअर बाउंड' चर को क्रमिक रूप से दो बार मान दिया गया है। शायद यह एक गलती है। चेक लाइनें: 324, 323. रनटाइम गौसियनओप.सीएस 324

दरअसल, अंतिम दूसरी शाखा में, निचली चर का मान एक पंक्ति में दो बार सौंपा जाता है। स्पष्ट रूप से (और ऊपर दिए गए कोड को देखते हुए), चर अपरबाउंड को एक असाइनमेंट में शामिल होना चाहिए।

हम आगे का अनुसरण करते हैं।

 private void WriteAucMatrix(....) { .... for (int c = 0; c < classLabelCount; c++) { int labelWidth = labels[c].Length; columnWidths[c + 1] = labelWidth > MaxLabelWidth ? MaxLabelWidth : labelWidth; for (int r = 0; r < classLabelCount; r++) { int countWidth = MaxValueWidth; if (countWidth > columnWidths[c + 1]) { columnWidths[c + 1] = countWidth; } } .... } 

PVS-Studio चेतावनी : V3081 नेस्टेड लूप के अंदर 'r' काउंटर का उपयोग नहीं किया गया है। 'C' काउंटर के निरीक्षण उपयोग पर विचार करें। CommandLine ClassifierEvaluationModule.cs 459

कृपया ध्यान दें कि इस लूप के शरीर में आंतरिक लूप - आर - के काउंटर का उपयोग नहीं किया गया है। इस वजह से, यह पता चलता है कि आंतरिक लूप के सभी पुनरावृत्तियों के दौरान समान तत्वों पर एक ही संचालन किया जाता है - आखिरकार, सूचकांक भी बाहरी लूप ( सी ) के काउंटर का उपयोग करते हैं, और आंतरिक ( आर ) नहीं।

आइए देखें कि और क्या दिलचस्प पाया गया।

 public RegexpFormattingSettings( bool putOptionalInSquareBrackets, bool showAnyElementAsQuestionMark, bool ignoreElementDistributionDetails, int truncationLength, bool escapeCharacters, bool useLazyQuantifier) { this.PutOptionalInSquareBrackets = putOptionalInSquareBrackets; this.ShowAnyElementAsQuestionMark = showAnyElementAsQuestionMark; this.IgnoreElementDistributionDetails = ignoreElementDistributionDetails; this.TruncationLength = truncationLength; this.EscapeCharacters = escapeCharacters; } 

पीवीएस-स्टूडियो चेतावनी : V3117 कंस्ट्रक्टर पैरामीटर 'यूज़लैज़लक्वायंटिफायर' का उपयोग नहीं किया जाता है। रनटाइम रेगेक्सपॉर्माटेटिंग सेटिंग्स। 38

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

कई संभावित खतरनाक घटना संचालकों से मुलाकात की। उनमें से एक का उदाहरण नीचे दिया गया है:

 public class RecommenderRun { .... public event EventHandler Started; .... public void Execute() { // Report that the run has been started if (this.Started != null) { this.Started(this, EventArgs.Empty); } .... } .... } 

PVS-Studio चेतावनी : V3083 इवेंट 'आरंभ' का असुरक्षित आह्वान, NullReferenceException संभव है। इसे लागू करने से पहले एक स्थानीय चर को घटना असाइन करने पर विचार करें। इवैल्यूएटर रिकमेंडररून.केएस 115

तथ्य यह है कि अशक्त असमानता और हैंडलर की कॉल के बीच की घटना के बीच, एक घटना को अनसब्सक्राइब किया जा सकता है, और यदि इस समय अशक्त और हैंडलर की कॉल के बीच की घटना के सदस्य नहीं हैं, तो एक NullReferenceException को फेंक दिया जाएगा। इस तरह की समस्याओं से बचने के लिए, उदाहरण के लिए, आप एक स्थानीय चर में प्रतिनिधि श्रृंखला के लिंक को बचा सकते हैं या '?' संचालक का उपयोग कर सकते हैं। संचालकों को बुलाने के लिए।

उपरोक्त कोड स्निपेट के अलावा, ऐसे 35 स्थान थे।

वैसे, V3024 की 785 चेतावनियां भी मिलीं। वार्नर V3024 को ऑपरेटर्स का उपयोग करके वास्तविक संख्याओं की तुलना करते समय जारी किया जाता है '! =' या '=='। मैं यहां इस बात पर ध्यान नहीं दूंगा कि इस तरह की तुलनाएं हमेशा सही क्यों नहीं होती हैं - इस बारे में अधिक दस्तावेज में लिखा गया है, स्टैकऑवरफ्लो का एक लिंक भी है (यह यह है)।

यह देखते हुए कि सूत्र और गणना अक्सर मिलते थे, ये चेतावनी महत्वपूर्ण भी हो सकती हैं, हालांकि उन्हें लेवल 3 पर ले जाया जाता है (क्योंकि वे सभी परियोजनाओं में प्रासंगिक से बहुत दूर हैं)।

यदि आप सुनिश्चित हैं कि ये चेतावनियाँ अप्रासंगिक हैं, तो आप उन्हें लगभग एक क्लिक के साथ हटा सकते हैं , कुल संख्या में विश्लेषक ऑपरेशन को कम कर सकते हैं ।

निष्कर्ष

किसी तरह यह पता चला कि लंबे समय तक मैंने परियोजनाओं की जांच पर लेख नहीं लिखा था, और इस प्रक्रिया को फिर से छूने के लिए काफी सुखद था। मुझे उम्मीद है कि आपने इस लेख से कुछ नया / उपयोगी भी सीखा है, या कम से कम इसे रुचि के साथ पढ़ें।

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

और याद रखें कि एक स्थिर विश्लेषक का अधिकतम लाभ इसके नियमित उपयोग के साथ प्राप्त किया जाता है।

ऑल द बेस्ट!

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