स्थैतिक विश्लेषण जटिल सी ++ परियोजनाओं के कोड आधार में सुधार करेगा

धीरे-धीरे और असंगत रूप से, एक स्थिति विकसित होती है जब गंभीर सी ++ परियोजनाओं की जटिलता निषेधात्मक हो जाती है। दुर्भाग्य से, अब एक C ++ प्रोग्रामर पूरी तरह से अपनी ताकत पर भरोसा नहीं कर सकता है।

सबसे पहले, इतना कोड है कि यह संभव नहीं है जब परियोजना में कम से कम कुछ प्रोग्रामर हैं जो पूरी परियोजना को जानते हैं। उदाहरण के लिए, लिनक्स कर्नेल 1.0.0 में कोड की लगभग 176 हजार लाइनें थीं। यह बहुत कुछ है, लेकिन एक कॉफी मशीन को पास में रखना संभव था और कुछ हफ्तों में कम या ज्यादा पूरे कोड को देखें और इसके संचालन के सामान्य सिद्धांतों को समझें। यदि हम लिनक्स 5.0.0 कर्नेल लेते हैं, तो कोड बेस का आकार पहले से ही कोड की 26 मिलियन लाइनों के बारे में है। कर्नेल कोड लगभग 150 गुना बढ़ गया है। आप केवल परियोजना के कई हिस्सों का चयन कर सकते हैं और उनके विकास में भाग ले सकते हैं। यह पता लगाना असंभव है कि यह सब कैसे काम करता है, कोड के विभिन्न वर्गों के बीच क्या संबंध हैं।

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

क्या स्थिति निराशाजनक है? नहीं। उपकरणों का एक नया वर्ग बचाव के लिए आता है: स्थैतिक कोड विश्लेषक। इस समय के कई अनुभवी प्रोग्रामर ने अपने होंठों को कर्ल किया, जैसे कि वे एक नींबू गिराए हों :)। जैसे, हम आपके लिंटर को जानते हैं ... बहुत सारे संदेश हैं, थोड़ी समझदारी ... हां, और यह नया टूल कौन सा है! हमने लिंटर 20 साल पहले लॉन्च किया था।

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

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

हालांकि, यह अधिक महत्वपूर्ण है कि आधुनिक स्थिर विश्लेषणकर्ताओं को त्रुटि पैटर्न का व्यापक ज्ञान है। इसके अलावा, analyzers भी पेशेवर डेवलपर्स से अधिक जानते हैं। कोड लिखते समय सभी बारीकियों को याद रखना मुश्किल हो गया। उदाहरण के लिए, जब तक आप विशेष रूप से इसके बारे में कहीं नहीं पढ़ते हैं, तब तक आप कभी भी अनुमान नहीं लगाएंगे कि निजी डेटा को मिटाने के लिए मेमसेट फ़ंक्शन को कॉल करना कभी-कभी गायब हो जाता है, क्योंकि कंपाइलर के दृष्टिकोण से, कॉल करने के लिए मेमसेट फ़ंक्शन बेमानी है। इस बीच, यह एक गंभीर सुरक्षा दोष है CWE-14 , जो हर जगह सचमुच पाया जाता है । या जो, उदाहरण के लिए, जानता है कि ऐसे कंटेनर भरने में क्या खतरनाक है?

std::vector<std::unique_ptr<MyType>> v; v.emplace_back(new MyType(123)); 

मुझे लगता है कि हर कोई तुरंत महसूस नहीं करेगा कि ऐसा कोड संभावित खतरनाक है और इससे मेमोरी लीक हो सकती है।

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

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

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

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

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

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