कोड बेस पर स्टेटिक कोड विश्लेषण करने के लिए पीसी-लिंट या क्यूएसी जैसे टूल का उपयोग किया जा सकता है।
मेरे अनुभव में स्थैतिक विश्लेषण में अक्सर भारी मात्रा में शोर होता है, अर्थात उन चीजों पर चेतावनी जो वास्तविक बग नहीं हैं, लेकिन किसी दिए गए नियम के नियमों में से किसी एक का उल्लंघन करते हैं। कुछ नियमों को बंद करना (या तो नियम सेट में या कोड में विशेष टिप्पणियों के माध्यम से अच्छे के लिए) एक वास्तविक बोझिल प्रक्रिया हो सकती है।
स्थैतिक कोड विश्लेषण के वास्तविक लाभ क्या हैं?
जवाबों:
मैंने एक ऐसे स्थान पर काम किया, जिसने एक व्यावसायिक स्थैतिक कोड विश्लेषण प्रणाली का उपयोग किया, जिसे Coverity Prevent कहा जाता था, और यह आश्चर्यजनक था! यह वास्तव में परिष्कृत और बुद्धिमान है।
हमने ओपन-सोर्स और मालिकाना सी और सी ++ कोड दोनों के बारे में 18 जीबी फेंक दिया, और यह कोड रास्तों के माध्यम से पता लगाएगा और जल्दी से सूक्ष्म कीड़े ढूंढेगा जो एक मानव को हमेशा के लिए ट्रैक करने के लिए ले जाएगा। यह उन चीज़ों पर चुटकी लेने में भी बहुत अच्छा था जो आमतौर पर हाइजेनबग्स होंगे।
यह हमारे कोड बेस के खिलाफ हर कुछ दिनों में चला, और एक अच्छी विशेषता यह थी कि हम इसे बता सकते हैं, "यह वास्तव में बग नहीं है," और यह भविष्य में याद रखेगा।
गोटा है, आवरण वास्तव में महंगा है। वे लागतों को प्रकाशित नहीं करते हैं, लेकिन मुझे लगता है कि वाणिज्यिक परियोजनाओं के लिए, यह प्रति वर्ष सैकड़ों हजारों डॉलर में शुरू होता है। लेकिन इसने शायद हमें डेवलपर्स और क्यूए कर्मचारियों के पूरे समूह को रखने के लिए बचा लिया, इसलिए हमारे पूरे प्रबंधन को लगता है कि यह एक अच्छी खरीद थी।
उस अनुभव के बाद, मैं स्थैतिक कोड विश्लेषण पर काफी अनुकूल लग रहा हूं।
जब एक नई भाषा के साथ शुरुआत करना एक कोच के लिए अच्छा होता है। यही कारण है कि मैं स्थैतिक विश्लेषण उपकरण के बारे में सोचता हूं। मैं बहुत सारी जावास्क्रिप्ट लिखता हूं और शुरुआत में मैंने मुख्य रूप से कुछ बुरी आदतों को उठाया क्योंकि मैं पहले की भाषाओं से कुछ चीजों को स्थानांतरित कर रहा था। जावास्क्रिप्ट बहुत लचीला है, इसलिए आप बहुत कुछ के साथ दूर हो सकते हैं, लेकिन अगर मुझे jslint ने मुझे कुछ निश्चित पैटर्न के बारे में चेतावनी दी होती, तो मैंने शुरुआत में सामान वापस करने के बजाय शुरू से ही बेहतर कोडिंग पैटर्न उठाया होता।
स्थैतिक विश्लेषक मूल रूप से मशीन-असिस्टेड कोड समीक्षाएं हैं। वे उन संदिग्ध क्षेत्रों को इंगित करेंगे जो नियमित परीक्षण के दौरान छूट सकते हैं।
उदाहरण के लिए, क्या लेखक का वास्तव में इस सशर्त में असाइनमेंट करने का मतलब है?
if (x = 1) {
...
}
या शायद एक धोखेबाज़ ने शाब्दिक कास्टिंग को भ्रमित किया:
char* number = "123";
int converted = number;
निश्चित रूप से स्थैतिक विश्लेषणकर्ताओं को ट्विकिंग की आवश्यकता होती है। फिर से, पुनरीक्षण नियंत्रण, विकी, बग ट्रैकर्स, सुंदर प्रिंटर और अन्य उपकरणों के साथ-साथ कुछ सेट-अप की आवश्यकता होती है। परियोजना जितनी बड़ी होगी, प्रारंभिक श्रम के लिए उतना ही बेहतर होगा।
एक सलाहकार के दृष्टिकोण से, प्रत्येक स्थिर विश्लेषण उपकरण में कुछ शोर होगा लेकिन सभी स्थिर विश्लेषणकर्ताओं को समान नहीं बनाया गया है। कवरटी, क्लोकवर्क, ग्राममेट जैसे स्थैतिक विश्लेषण उपकरण में अच्छी विश्लेषण तकनीकें हैं जो अधिक सटीक परिणाम उत्पन्न करना चाहिए। यदि आप कुछ और ट्यून करते हैं और आप बेहतर परिणाम प्राप्त करते हैं तो आमतौर पर (आखिरकार, स्टैटिक एनालाइजर को छोटे मेडिकल डिवाइस से नेटवर्क ऑपरेटिंग सिस्टम पर सभी विभिन्न प्रकार के कोड को चलाने में सक्षम होना पड़ता है)। "शोर" को परिभाषित करना भी एक तय-योग्य रिपोर्ट का गठन करने के लिए आपके मानदंड पर निर्भर है। स्पेक्ट्रम के एक छोर पर, कुछ डेवलपर्स उन सभी रिपोर्टों को चिह्नित करते हैं जिन्हें वे "झूठे" के रूप में ठीक नहीं करते हैं (यहां तक कि खराब लिखे गए कोड भी, जिनके पास उन्हें ठीक करने का समय नहीं है) और दूसरे छोर पर,
इन उपकरणों में से कुछ अधिक केंद्रीय विश्लेषण केंद्रित हैं और अन्य अधिक डेस्कटॉप केंद्रित हैं - हालांकि तीनों में ऐसी विशेषताएं हैं जो दोनों का समर्थन करती हैं। जैसा @ @ ने उल्लेख किया है, वे पैसे खर्च करते हैं।
सॉफ्टवेयर कोड पर मैनुअल समीक्षा करके, उपकरण के बिना स्टेटिक विश्लेषण भी किया जा सकता है। कोड गुणवत्ता में सुधार के लिए यह अक्सर सबसे अधिक लागत प्रभावी तरीका है।
दूसरा सबसे अच्छा विकल्प एक या एक से अधिक हाई-एंड स्टैटिक एनालिसिस टूल्स (जैसे कि पहले बताई गई कवरेज, या KLOCwork) के लिए निवेश करना है। चूंकि ये उपकरण लिंट की तुलना में बहुत गहरा विश्लेषण करते हैं, उदाहरण के लिए, सिग्नल-टू-शोर अनुपात बहुत बेहतर है।
मैं तीसरे विकल्प के रूप में लिंट का उपयोग करने पर विचार करता हूं, क्योंकि उच्च शोर स्तर। मौजूदा परियोजना के लिए एक प्रकार का वृक्ष लगाना एक कठिन काम हो सकता है।
सामान्य स्थैतिक कार्यक्रम विश्लेषण में हाल के वर्षों में बहुत प्रगति हुई है। वर्तमान स्थैतिक विश्लेषण उपकरण गहरी इंटरप्रोडेक्टल विश्लेषण करने में सक्षम हैं, स्वचालित रूप से पूर्व और बाद की स्थितियों के उदाहरण के लिए पहचान कर सकते हैं। यह बाद में कोड समीक्षाओं के लिए भी एक बड़ी मदद हो सकती है।
उच्च झूठी सकारात्मक दर के कारण, आपको प्रत्येक संकलन के लिए स्थैतिक विश्लेषण उपकरण (जैसे लिंट या फाइंडबग्स) का उपयोग नहीं करना चाहिए।
बल्कि, बग होने के बाद परामर्श करने के लिए यह एक अच्छा विवेक है । उस स्थिति में, आप झूठी सकारात्मकता का मनोरंजन कर सकते हैं, और आप पहले से ही त्रुटि के संभावित स्रोतों को कम कर सकते हैं। उदाहरण के लिए, यदि आप कुछ मॉड्यूल को निष्पादित किए बिना भी अपने बग को पुन: पेश करते हैं, तो आप अनदेखा कर सकते हैं कि फाइंडबग्स उनके लिए क्या कहता है। यह विशेष रूप से तब सहायक होता है जब आप एक कोड को देख रहे होते हैं और सोचते हैं कि यह एक बात कहती है, जबकि कंपाइलर इसे अक्षरशः पढ़ता है (जैसे जावा में जब आपके पास एक equalsविधि होती है जो इसके बजाय कक्षा के प्रकार में होती है Object)।
आपके पास स्थैतिक विश्लेषण उपकरण भी आपकी विकास प्रक्रिया का एक हिस्सा हो सकते हैं: जब एक डेवलपर को कोड की समीक्षा मिलती है, तो उन्हें उस पर FindBugs भी चलाना चाहिए। संक्षेप में, यह उपयोगी है, लेकिन आप इसे संकलक या पाठ संपादक के रूप में अक्सर उपयोग नहीं करेंगे।