कीड़े के लिए ऑर्चर्ड सीएमएस के कोड को स्कैन करना

यह लेख PVS-Studio स्थैतिक विश्लेषक के साथ ऑर्चर्ड परियोजना के दूसरे चेक के परिणामों की समीक्षा करता है। ऑर्चर्ड एक ओपन-सोर्स कंटेंट मैनेजर सिस्टम है, जो नॉन-प्रॉफिट ऑउटरकव फाउंडेशन के तहत ASP.NET ओपन सोर्स गैलरी के हिस्से के रूप में दिया गया है। आज की जाँच विशेष रूप से दिलचस्प है क्योंकि पहली जाँच के बाद से परियोजना और विश्लेषक दोनों एक लंबा रास्ता तय कर चुके हैं, और इस बार हम नए नैदानिक ​​संदेशों और कुछ अच्छे बगों को देखेंगे।

ऑर्चर्ड सीएमएस के बारे में

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

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

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

विश्लेषण के परिणाम

यहां ऑर्चर्ड के पहले चेक से कुछ आंकड़े दिए गए हैं ताकि आपको तुलना के लिए दो लेखों के बीच स्विच न करना पड़े।

पिछले चेक के दौरान, "हमने .cs एक्सटेंशन के साथ सभी स्रोत कोड फ़ाइलों (3739 आइटम) का विश्लेषण किया था। कुल योग में कोड की 214,564 लाइनें थीं। जाँच का परिणाम 137 चेतावनियाँ थीं। अधिक सटीक होने के लिए, पहले 39 (उच्च) स्तर की चेतावनी थी। 60 सेकंड (मध्यम) स्तर की चेतावनी भी थी। ”

ऑर्चर्ड का वर्तमान संस्करण 2,767 .cs फाइलों से बना है, यानी यह लगभग एक हजार फाइलें छोटी है। रिपॉजिटरी के डाउनसाइज़िंग और नाम बदलने से पता चलता है कि डेवलपर्स ने परियोजना के कोर ( 966 कमिट ) को अलग कर दिया है, जो कि 108,287 एलओसी लंबा है। विश्लेषक ने 153 चेतावनी जारी की: 33 प्रथम-स्तर और 70 दूसरे-स्तर वाले। हम आम तौर पर तीसरे स्तर की चेतावनियों को शामिल नहीं करते हैं, और मैं परंपरा से चिपके रहने वाला हूं।

PVS- स्टूडियो डायग्नोस्टिक संदेश: V3110 'TryValidateModel' पद्धति के अंदर संभावित अनंत पुनरावृत्ति। उपसर्गकृतमोडुलेपदत्र ed४ule ule

public bool TryValidateModel(object model, string prefix) { return TryValidateModel(model, Prefix(prefix)); } 

एक अनंत पुनरावृत्ति बग के साथ शुरू करते हैं, जैसा कि हमने पहले लेख में किया था। इस बार डेवलपर के सटीक इरादे स्पष्ट नहीं हैं, लेकिन मैंने देखा कि TryValidateModel विधि में एक पैरामीटर के साथ एक अतिभारित संस्करण था:

 public bool TryValidateModel(object model) { return _updateModel.TryValidateModel(model); } 

मुझे लगता है कि, अतिभारित संस्करण के मामले की तरह, डेवलपर का इरादा _updateModel के माध्यम से कॉल करने का है । संकलक ने गलती को नोटिस नहीं किया; _updateModel IUpdateModel प्रकार का है, और वर्तमान वर्ग भी इस इंटरफ़ेस को लागू करता है। चूंकि StackOverflowException के विरुद्ध किसी भी जाँच में विधि शामिल नहीं है, इसलिए शायद इसे कभी नहीं बुलाया गया, हालाँकि मैं उस पर भरोसा नहीं करता। यदि मेरी धारणा सही है, तो निश्चित संस्करण को इस तरह दिखना चाहिए:

 public bool TryValidateModel(object model, string prefix) { return _updateModel.TryValidateModel(model, Prefix(prefix)); } 

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3008 'कंटेंट' वेरिएबल को क्रमिक रूप से दो बार मान दिया गया है शायद यह एक गलती है। चेक लाइन: 197, 190. डायनेमिकचैटेग हेल्पर। 197

 public override async Task ProcessAsync(....) { .... IHtmlContent content; .... try { content = await output.GetChildContentAsync(); } finally { _cacheScopeManager.ExitScope(); } content = await ProcessContentAsync(output, cacheContext); .... } 

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

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3080 संभावित अशक्तता । 'आइटमटैग' का निरीक्षण करने पर विचार करें। CoreShapes.cs 92

 public async Task<IHtmlContent> List(....string ItemTag....) { .... string itemTagName = null; if (ItemTag != "-") { itemTagName = string.IsNullOrEmpty(ItemTag) ? "li" : ItemTag; } var index = 0; foreach (var item in items) { var itemTag = String.IsNullOrEmpty(itemTagName) ? null : ....; .... itemTag.InnerHtml.AppendHtml(itemContent); listTag.InnerHtml.AppendHtml(itemTag); ++index; } return listTag; } 

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

 public async Task<IHtmlContent> List(....string ItemTag....) { .... string itemTagName = null; if (ItemTag != "-") { itemTagName = string.IsNullOrEmpty(ItemTag) ? "li" : ItemTag; } var index = 0; foreach (var item in items) { var itemTag = ....; if(String.IsNullOrEmpty(itemTag)) throw .... .... itemTag.InnerHtml.AppendHtml(itemContent); listTag.InnerHtml.AppendHtml(itemTag); ++index; } return listTag; } 

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

 public async Task<IActionResult> Import(ImportViewModel model) { .... var remoteClient = remoteClientList.RemoteClients.FirstOrDefault(....); var apiKey = Encoding.UTF8.GetString(....(remoteClient.ProtectedApiKey)); if (remoteClient == null || ....) { .... } .... } 

विश्लेषक ने रिमोट क्लिएंट के एक विचलन का पता लगाया, जिसके बाद बाद में एक-दो लाइनों की अशक्त जांच की। यह वास्तव में एक संभावित NullReferenceException है क्योंकि FirstOrDefault विधि एक डिफ़ॉल्ट मान (जो संदर्भ प्रकारों के लिए रिक्त है ) वापस कर सकती है। मुझे लगता है कि इस स्निपेट को केवल चेक अप को आगे बढ़ाकर तय किया जा सकता है, ताकि डायरैक्शन ऑपरेशन से पहले:

 public async Task<IActionResult> Import(ImportViewModel model) { .... var remoteClient = remoteClientList.RemoteClients.FirstOrDefault(....); if (remoteClient != null) var apiKey = UTF8.GetString(....remoteClient.ProtectedApiKey); else if (....) { .... } .... } 

या शायद यह FirstOrDefault को First के साथ बदलकर और पूरी तरह से चेक को हटाकर तय किया जाना चाहिए।

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

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

मैं इस निदान से प्राप्त परिणामों को ऑर्चर्ड परियोजना पर साझा नहीं कर सकता। 27 संभावित खतरनाक स्पॉट हैं। यहाँ उनमें से कुछ हैं:

ContentTypesAdminNodeNavigationBuilder.cs 71:

 var treeBuilder = treeNodeBuilders.Where(....).FirstOrDefault(); await treeBuilder.BuildNavigationAsync(childNode, builder, treeNodeBuilders); 

ListPartDisplayDriver.cs 217:

 var contentTypePartDefinition = ....Parts.FirstOrDefault(....); return contentTypePartDefinition.Settings....; 

ContentTypesAdminNodeNavigationBuilder.cs 113:

 var typeEntry = node.ContentTypes.Where(....).FirstOrDefault(); return AddPrefixToClasses(typeEntry.IconClass); 

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3080 संभव वापसी विधि की वापसी के बिना। निरीक्षण करने पर विचार करें: CreateScope ()। SetupService.cs 136

 public async Task<string> SetupInternalAsync(SetupContext context) { .... using (var shellContext = await ....) { await shellContext.CreateScope().UsingAsync(....); } .... } 

विश्लेषक ने CreateScope विधि द्वारा लौटाए गए मान का एक उल्लेख किया। CreateScope एक छोटी विधि है, इसलिए यहां इसका पूर्ण कार्यान्वयन है:

 public ShellScope CreateScope() { if (_placeHolder) { return null; } var scope = new ShellScope(this); // A new scope can be only used on a non released shell. if (!released) { return scope; } scope.Dispose(); return null; } 

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

शायद मेरी राय पक्षपाती है, लेकिन मेरा मानना ​​है कि हर अतुल्यकालिक विधि को NullReferenceException से जितना संभव हो सके संरक्षित किया जाना चाहिए क्योंकि सामान को डिबग करना ऐसे ही सुखद है।

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

V3080 विधि वापसी मूल्य की संभावित अशक्तता । निरीक्षण करने पर विचार करें: CreateScope ()। SetupService.cs 192

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3127 दो समान कोड टुकड़े पाए गए। शायद, यह एक टाइपो है और 'ConsumerSecret' TwitterClientMessageHandler.cs 52 के बजाय 'AccessTokenSecret' चर का उपयोग किया जाना चाहिए

 public async Task ConfigureOAuthAsync(HttpRequestMessage request) { .... if (!string.IsNullOrWhiteSpace(settings.ConsumerSecret)) settings.ConsumerSecret = protrector.Unprotect(settings.ConsumerSecret); if (!string.IsNullOrWhiteSpace(settings.ConsumerSecret)) settings.AccessTokenSecret = protrector.Unprotect(settings.AccessTokenSecret); .... } 

यह एक क्लासिक कॉपी-पेस्ट गलती है। ConsumerSecret को दो बार चेक किया गया था, जबकि AccessTokenSecret को बिल्कुल चेक नहीं किया गया था। जाहिर है, यह इस प्रकार तय किया गया है:

 public async Task ConfigureOAuthAsync(HttpRequestMessage request) { .... if (!string.IsNullOrWhiteSpace(settings.ConsumerSecret)) settings.ConsumerSecret = protrector.Unprotect(settings.ConsumerSecret); if (!string.IsNullOrWhiteSpace(settings.AccessTokenSecret)) settings.AccessTokenSecret = protrector.Unprotect(settings.AccessTokenSecret); .... } 

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3139 दो या दो से अधिक केस-शाखाएँ एक ही क्रिया करते हैं। SerialDocumentExecuter.cs 23

एक और कॉपी-पेस्ट बग। स्पष्टता के लिए, यहां पूर्ण वर्ग कार्यान्वयन (यह छोटा है)।

 public class SerialDocumentExecuter : DocumentExecuter { private static IExecutionStrategy ParallelExecutionStrategy = new ParallelExecutionStrategy(); private static IExecutionStrategy SerialExecutionStrategy = new SerialExecutionStrategy(); private static IExecutionStrategy SubscriptionExecutionStrategy = new SubscriptionExecutionStrategy(); protected override IExecutionStrategy SelectExecutionStrategy(....) { switch (context.Operation.OperationType) { case OperationType.Query: return SerialExecutionStrategy; case OperationType.Mutation: return SerialExecutionStrategy; case OperationType.Subscription: return SubscriptionExecutionStrategy; default: throw ....; } } } 

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

 switch (context.Operation.OperationType) { case OperationType.Query: case OperationType.Mutation: return SerialExecutionStrategy; case OperationType.Subscription: return SubscriptionExecutionStrategy; default: throw ....; } 

यदि यह एक कॉपी-पेस्ट बग है, तो डुप्लिकेट रिटर्न फ़ील्ड्स में से पहला इस प्रकार तय किया जाना चाहिए:

 switch (context.Operation.OperationType) { case OperationType.Query: return ParallelExecutionStrategy; case OperationType.Mutation: return SerialExecutionStrategy; case OperationType.Subscription: return SubscriptionExecutionStrategy; default: throw ....; } 

या यह दूसरी केस ब्रांच होनी चाहिए। मुझे परियोजना का विवरण नहीं पता है और इसलिए ऑपरेशन के प्रकार और रणनीतियों के नामों के बीच संबंध का निर्धारण नहीं किया जा सकता है।

 switch (context.Operation.OperationType) { case OperationType.Query: return SerialExecutionStrategy; case OperationType.Mutation: return ParallelExecutionStrategy; case OperationType.Subscription: return SubscriptionExecutionStrategy; default: throw ....; } 

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3080 संभावित अशक्तता । 'अनुरोध' का निरीक्षण करने पर विचार करें। ग्राफक्लाइनमेडवेयर.केएस 148

 private async Task ExecuteAsync(HttpContext context....) { .... GraphQLRequest request = null; .... if (HttpMethods.IsPost(context.Request.Method)) { .... } else if (HttpMethods.IsGet(context.Request.Method)) { .... request = new GraphQLRequest(); .... } var queryToExecute = request.Query; .... } 

अनुरोध चर पहले ब्लॉक में कई बार शून्य से भिन्न मान दिया जाता है, लेकिन प्रत्येक बार नेस्टेड शर्तों के साथ। उन सभी स्थितियों को शामिल करने से उदाहरण बहुत लंबा हो जाएगा, इसलिए हम बस पहले कुछ लोगों के साथ जाएंगे, जो http विधि IsGet या IsPost के प्रकार की जांच करते हैं। Microsoft.AspNetCore.Http.HttpMethods वर्ग में क्वेरी प्रकार की जाँच के लिए नौ स्थिर विधियाँ हैं। इसलिए, उदाहरण के लिए, ExecuteAsync विधि के लिए एक हटाएँ या सेट क्वेरी NullReferenceException को बढ़ाने के लिए ले जाएगा। यहां तक ​​कि अगर इस तरह के तरीके वर्तमान में समर्थित नहीं हैं, तब भी अपवाद-फेंकने वाले चेक को जोड़ना बुद्धिमानी होगी। आखिरकार, सिस्टम आवश्यकताएँ बदल सकती हैं। इस तरह की जाँच का एक उदाहरण है:

 private async Task ExecuteAsync(HttpContext context....) { .... if (request == null) throw ....; var queryToExecute = request.Query; .... } 

पीवीएस-स्टूडियो डायग्नोस्टिक संदेश: V3080 संभव वापसी विधि की वापसी के बिना। निरीक्षण करने पर विचार करें: Get <ContentPart> (...)। ContentPartHandlerCoordinator.cs 190

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

 public override async Task LoadingAsync(LoadContentContext context) { .... context.ContentItem.Get<ContentPart>(typePartDefinition.Name) .Weld(fieldName, fieldActivator.CreateInstance()); .... } 

विश्लेषक इस लाइन की रिपोर्ट करते हैं। आइए एक नजर डालते हैं Get विधि पर:

 public static TElement Get<TElement>(this ContentElement contentElement....) where TElement : ContentElement { return (TElement)contentElement.Get(typeof(TElement), name); } 

यह इसके अतिभारित संस्करण को कॉल करता है। आइए इसे भी जांचें:

 public static ContentElement Get(this ContentElement contentElement....) { .... var elementData = contentElement.Data[name] as JObject; if (elementData == null) { return null; } .... } 

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

समाधान 1:

 public static ContentElement Get(this ContentElement contentElement....) { .... var elementData = contentElement.Data[name] as JObject; if (elementData == null) { throw.... } .... } 

समाधान 2:

 public override async Task LoadingAsync(LoadContentContext context) { .... context.ContentItem.Get<ContentPart>(typePartDefinition.Name) ?.Weld(fieldName, fieldActivator.CreateInstance()); .... } 

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

 public static async Task<IEnumerable<ContentItem>> ContentQueryAsync(....) { var results = await orchardHelper.QueryAsync(queryName, parameters); .... foreach (var result in results) { .... } .... } 

पिछले एक की तुलना में यह काफी सरल उदाहरण है। विश्लेषक को संदेह है कि QueryAsync विधि एक अशक्त संदर्भ वापस कर सकती है। यहाँ विधि का कार्यान्वयन है:

 public static async Task<IEnumerable> QueryAsync(....) { .... var query = await queryManager.GetQueryAsync(queryName); if (query == null) { return null; } .... } 

चूंकि GetQueryAsync एक इंटरफ़ेस विधि है, इसलिए आप प्रत्येक कार्यान्वयन के बारे में सुनिश्चित नहीं हो सकते हैं, खासकर अगर हम मानते हैं कि परियोजना में निम्नलिखित संस्करण भी शामिल हैं:

 public async Task<Query> GetQueryAsync(string name) { var document = await GetDocumentAsync(); if(document.Queries.TryGetValue(name, out var query)) { return query; } return null; } 

बाहरी कार्यों और कैश एक्सेस के लिए कई कॉल GetDocumentAsync के विश्लेषण को मुश्किल बनाते हैं , तो चलिए हम कहते हैं कि चेक की आवश्यकता है - सभी और अधिक क्योंकि विधि एक अतुल्यकालिक है।

 public static async Task<IEnumerable<ContentItem>> ContentQueryAsync(....) { var results = await orchardHelper.QueryAsync(queryName, parameters); if(results == null) throw ....; .... foreach (var result in results) { .... } .... } 

निष्कर्ष

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

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