पीवीएस-स्टूडियो में एक नया नैदानिक ​​नियम कैसे जोड़ें? साप्ताहिक डेवलपर्स ...

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



चलो तुरंत साफ हो जाओ। पीवीएस-स्टूडियो में उपयोगकर्ता को अपने नियम लिखने के लिए कोई तंत्र नहीं है। यह, सबसे पहले, एक वास्तुशिल्प सीमा है। और कुछ उपयोगकर्ता परेशान हो सकते हैं। हालांकि, वास्तव में, ऐसे उपयोगकर्ता समझ नहीं पाते हैं कि वे क्या चाहते हैं। क्योंकि जीवन में, एक नया नियम जोड़ने की प्रक्रिया काफी जटिल है।

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

 स्थिर कास्ट संरचना _tag_cpltbl {अहस्ताक्षरित सीपी;  const char * मिमेकप;  } cptbl [] = {{037, "IBM037"}, // IBM EBCDIC US-Canada {437, "IBM437"}, // OEM संयुक्त राज्य अमेरिका {500, "IBM500"}, // IBM EBCDIC International {708, "ASMO-708"}, // अरबी (ASMO 708) ...} 

यह केवल संरेखण के लिए 37 के बजाय 037 कहता है, हालांकि यह दशमलव 31 हो गया, क्योंकि 037 C ++ नियमों के अनुसार एक अष्टक सूचना है। त्रुटि का निदान करना काफी सरल है, है ना? वास्तव में, हम एक स्थिरांक की तलाश कर रहे हैं, देखें कि क्या यह 0 से शुरू होता है और नैदानिक ​​संदेश जारी करता है। इस तरह के नैदानिक ​​नियम को एक घंटे में लागू किया जा सकता है। और एक स्थिर विश्लेषक का उपयोगकर्ता (प्रोग्रामिंग में एक पेशेवर, लेकिन इस तरह के उपकरणों के विकास के लिए नया) इस तरह के नियम को लागू करने के लिए सिद्धांत रूप में तैयार है।

हालांकि, वह ऐसा नहीं कर पाएगा। बल्कि, यह पता चलेगा, लेकिन बड़ी संख्या में झूठी सकारात्मकता के कारण वह परिणाम से संतुष्ट नहीं होगा।

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

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

गलत ऑक्टल नंबरों की खोज पर लौटते हैं - V536 नियम। इसमें कई अपवाद हैं। जब निदान जारी नहीं किया जाता है तो यहां ऐसी स्थितियां हैं:

1. निरंतर मान 8 से कम है।
2. नंबर #define के माध्यम से घोषित किया गया है।
3. एक ब्लॉक में दो से अधिक अष्टक संख्या (नियम ने दो से अधिक बार काम किया), प्रकार के चार को छोड़कर।
4. इस नंबर का उपयोग फ़ंक्शंस में एक तर्क के रूप में किया जाता है: _open, mknod, open, wxMkdir, wxFileName :: Mkdir, wxFileName :: AppendDir, chmod।
5. यह संख्याओं का नेस्टेड ब्लॉक है। हम केवल सबसे ऊपर की जाँच करते हैं। उदाहरण: {{090}, {091}, {092}, {093}}।
6. यह संख्या <= 0777 है और उस कथन का हिस्सा है जहां एक शब्द है: फ़ाइल, फ़ाइल।
7. एक संख्या एक फ़ंक्शन का एक तर्क है, जिसमें से एक पैरामीटर में स्ट्रिंग "% o" शामिल है।

वास्तविक परियोजनाओं पर लॉन्च करने से पहले अपवादों की भविष्यवाणी करना हमेशा संभव नहीं होता है। इसलिए, पुनरावृत्ति "अपवाद - परीक्षण रन - परिणामों का विश्लेषण" कई बार दोहराया जा सकता है।

फिर, जब सभी अपवादों को लागू किया जाता है, और झूठी सकारात्मक की संख्या पर्याप्त होती है, तो परीक्षण परिणाम (पता त्रुटियों की संग्रहीत लॉग फ़ाइलों) को संदर्भ के रूप में घोषित किया जाता है। उसके बाद, विज़ुअल स्टूडियो के अन्य संस्करणों के लिए समान परीक्षण चलाए जाते हैं। अब (2011) हम विजुअल स्टूडियो 2005/2008/2010 के तीन संस्करणों का समर्थन करते हैं, उनमें परीक्षण 4 / 4.5 / 5 घंटे के अनुसार किए जाते हैं, जो कुल 14-15 घंटे का समय देता है। विजुअल स्टूडियो के एक अन्य संस्करण में एक रन के परिणामों के अनुसार, यह पता चल सकता है कि विज़ुअल स्टूडियो के संस्करण के आधार पर एक ही कोड के लिए अलग-अलग नैदानिक ​​संदेश जारी किए जाते हैं। यह आमतौर पर विभिन्न एसडीके की हेडर फाइलों में अंतर के कारण होता है। हम मतभेदों को खत्म करने की कोशिश कर रहे हैं ताकि विजुअल स्टूडियो के सभी संस्करणों में चलाए जा रहे परीक्षण समान परिणाम दें।

इन सभी थकाऊ परीक्षणों को चलाना इतना महत्वपूर्ण क्यों है? वास्तव में केवल झूठी सकारात्मक के कारण? नहीं, यह केवल झूठी सकारात्मक के बारे में नहीं है। मुद्दा यह है कि नियमों को लागू करते समय सभी संभव प्रकार की संरचनाओं को ध्यान में रखना और नियम लिखना बहुत मुश्किल है ताकि यह सही ढंग से काम करे और इसके अलावा विश्लेषक दुर्घटनाग्रस्त न हो। यही वह सब है जिसके लिए भारी मात्रा में परीक्षणों की आवश्यकता है!

हम किस अजीब डिजाइन के बारे में बात कर रहे हैं? मैं आपको कुछ उदाहरण देता हूं।

क्या आप जानते हैं कि आप एक चर घोषित कर सकते हैं, उदाहरण के लिए, किसी तरह यह:

  int const अहस्ताक्षरित स्थिर a22 = 0; 

क्या आप जानते हैं __int64 एक चर नाम हो सकता है?

  int __identifier (__ int64); 

तुम्हें पता है कि स्विच ब्रेसिज़ वैकल्पिक हैं के बाद?

  स्विच (0)
   अगर (एक्स) फू (); 

यहां तक ​​कि अगर आप स्वयं अपने कोड में एक समान निर्माण का उपयोग नहीं करते हैं, तो वे उपयोग किए गए पुस्तकालयों में हैं।

अंत में, सभी परीक्षणों को पास करने के बाद, आप प्रलेखन पर ले जा सकते हैं। प्रत्येक नैदानिक ​​नियम के लिए, हम रूसी और अंग्रेजी में एक प्रमाण पत्र लिखते हैं। अंग्रेजी में अनुवाद में भी समय लगता है। अब (जब कोड को डीबग किया जाता है, परीक्षण पारित किए जाते हैं, दस्तावेज लिखा जाता है), नियम पीवीएस-स्टूडियो की अगली रिलीज पर जाएगा।

इसलिए, एक नए नैदानिक ​​नियम के विकास चक्र को संक्षेप में निम्न प्रकार से प्रस्तुत किया जा सकता है:

1. एक नए नियम का विचार। या तो हम आविष्कार करते हैं, या उपयोगकर्ता संकेत देते हैं, या हम कहीं और झांकने का प्रबंधन करते हैं।
2. नियम का निरूपण।
3. नियम का क्रियान्वयन।
4. सभी प्रकार का परीक्षण।
5. परिणामों का विश्लेषण। विकल्प हैं:
   1. नियम के शब्दों को अंतिम रूप देना, अपवादों का परिचय, अनुच्छेद 2 में परिवर्तन
   2. नियम के कार्यान्वयन को स्थापित माना जाता है, आप प्रलेखन लिख और अनुवाद कर सकते हैं।

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

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

फिर सवाल उठता है: "क्यों, कुछ जाने-माने और सम्मानित स्टेटिक एनालिसिस में, क्या अपने स्वयं के कस्टम नियम निर्धारित करने के तरीके हैं?" शायद हम ऐसा नहीं कर सकते? आंशिक रूप से हाँ। लेकिन अपने स्वयं के नियमों को स्थापित करने के लिए केवल एक तंत्र एक सरल उद्देश्य प्रदान करता है - "प्रतियोगियों के साथ तुलना के लिए मैट्रिक्स" संकलन करने के लिए:

और इसलिए, पाठक पूछेगा कि पीवीएस-स्टूडियो में कस्टम नियम बनाना कभी संभव नहीं होगा? किसी दिन हमारे पास इसे लागू करने के लिए पर्याप्त ताकत होगी और तुलना मैट्रीस में खोना नहीं होगा :-)। इस बीच, हम हर कोई होगा जो इस पाठ का लिंक देने के लिए एक नया नियम बनाना चाहता है और कहता है: "हमारे पास कस्टम नियमों को जोड़ने के लिए सबसे अच्छा इंटरफ़ेस है - बस हमें एक ईमेल लिखें!"