चेकस्टाइल और जावा। क्या स्वचालित कोड निरीक्षण में मदद मिलेगी?

हाल ही में, कोड रिव्यू के ऑटोमेशन और ऑप्टिमाइज़ेशन, कोड इंस्पेक्शन, और बड़े प्रोजेक्ट्स के कोड को सभ्य रूप में बनाए रखने के लिए अन्य तरीके (उदाहरण के लिए, आर्टिकल 1 , आर्टिकल 2 , आर्टिकल 3 ) हैबर पर लगातार नज़र आते हैं।

मुझे लगता है कि नियमित पाठक पिछली पोस्ट ( पहले , दूसरे ) से मिल चुके हैं, जहां मेरे सहयोगियों ने जावा लाइब्रेरी चेकस्टाइल का उपयोग करने के बारे में बात की थी और इसके विस्तार पर हमारे संयुक्त अनुभव को साझा किया था।

चेकस्टाइल के लिए अतिरिक्त चेक (चेक) लिखने के लिए हमारी टीम के नवीनतम प्रयासों को एक्सेल चेकस्टाइल प्लगइन एक्लिप्स-सी ( सेवेंतु-चेकस्टाइल 1.5.3 , 4 सितंबर, 2012) के लिए हमारे ऐड-ऑन की नई विधानसभा में शामिल किया गया था।

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

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

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

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

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

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

कोड में त्रुटियों / स्टाइल की समस्याओं का पता लगाने के बाद, सेटिंग्स के आधार पर चेकस्टाइल अलग तरह से व्यवहार कर सकता है। "सॉफ्ट" सेटिंग्स के साथ, पुस्तकालय केवल त्रुटियों की चेतावनी देगा जो मौजूद हैं, और सबसे गंभीर सेटिंग्स के साथ, यह तब तक निर्माण करने में विफल रहेगा जब तक कि परियोजना में सभी चेकस्टाइल चेतावनी तय नहीं हो जाती।

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

विशिष्ट आवश्यकताओं के लिए अपने स्वयं के चेक को चेकस्टाइल में जोड़ना भी संभव है। हमारी टीम लंबे समय तक चेक लिख रही है और चेकस्टाइल को जोड़ रही है, और हम लगातार विकास में कई तैयार चेक का उपयोग करते हैं। उदाहरण: हमारी कंपनी में, java.lang.NullpointerException ऑब्जेक्ट बनाना एक खराब रूप माना जाता है। यह सुनिश्चित करने के लिए कि किसी भी परियोजना में कोई एनपीई तात्कालिकता नहीं है, हमने प्लगइन्स के एक्लिप्स चेकस्टाइल सेट में अपना स्वयं का चेक जोड़ा, जो किसी दिए गए वर्ग की वस्तुओं को बनाने से मना करता है ( ForbidInstantiationCheck ) और कॉन्फ़िगर किया गया ताकि चेक केवल "शापित" हो एनपीई को तुरंत करने के लिए।

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

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

मेरा मानना ​​है कि लाइब्रेरी की मुख्य खामी यह है कि सभी चेकस्टाइल चेक एक एकल जावा फ़ाइल की सीमा से परे नहीं जा सकते हैं। चेक के दौरान भी, चेकस्टाइल सभी टिप्पणियों को छोड़ देता है, लेकिन यह, मेरी राय में, घातक नहीं है।

जावा कोड का सत्यापन हमेशा चेकलिस्ट द्वारा निम्नलिखित योजना के अनुसार किया जाता है:

1. LL व्याकरण के आधार पर, चेकस्टाइल में प्रयुक्त ANTLR इंजन एक जावा पार्सर उत्पन्न करता है जो उपयोग किए गए जावा के संस्करण के विनिर्देश से मेल खाता है।
2. परिणामस्वरूप पार्सर का उपयोग करते हुए, जावा कोड को सार पार्सिंग ट्री (सार सिंथेस ट्री या एएसटी) के रूप में दर्शाया गया है - एक जावा फ़ाइल के लिए एक पेड़। प्राप्त प्रत्येक सिंटैक्स ट्री में लगभग निम्नलिखित संरचना होती है:
   
3. प्रत्येक पेड़ के प्रत्येक शीर्ष को सभी सम्मिलित चेक द्वारा संसाधित किया जाता है, जिसके कोड में इसी प्रकार के शीर्ष को इनपुट के रूप में इंगित किया जाता है। वाक्य रचना के पेड़ के कोने को संसाधित करने का क्रम कोड पढ़ते समय उनके अनुक्रम के वास्तविक क्रम से मेल खाता है: बाएं से दाएं और ऊपर से नीचे तक।
4. मिली सभी त्रुटियों के लिए, उपयुक्त चेतावनी उत्पन्न की जाती है।

हमारे पूरक के बारे में थोड़ा

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

लगभग एक साल पहले (11/09/11), हमारी परियोजना ग्रहण चेकस्टाइल प्लगइन का हिस्सा बन गई थी, जो ग्रहण-सी के लिए एक "विस्तार" बन गया। इसे स्थापित करना, जैसे कि ग्रहण के लिए किसी भी अन्य ऐड-ऑन, अपडेट-साइट के माध्यम से आसान है। स्थापना प्रक्रिया में दो सरल बिंदु होते हैं:

1. ग्रहण खोलें।
2. हम हमारी अपडेट साइट के "- नया सॉफ़्टवेयर स्थापित करें" URL में ड्राइव करते हैं: eclipse-cs.sourceforge.net/update/ और दोनों daw, अर्थात् - चेकस्टाइल-प्लगइन की वास्तविक स्थापना का चयन स्वयं और इसके अतिरिक्त करें:

इसके अलावा, आप एक्लिप्स मार्केटप्लेस के माध्यम से हमारे ऐड-ऑन (और एक्लिप्स-सीस को) स्वयं स्थापित कर सकते हैं, बिना मैन्युअल रूप से लिंक के।

ग्रहण को रिबूट करने और एक नया चेकस्टाइल बनाने के बाद - कॉन्फ़िगरेशन (विंडो -> प्राथमिकताएं -> चेकस्टाइल -> नया ...) हमारे अतिरिक्त चेक के 25 के साथ एक समूह चेकस्टाइल सेटिंग्स में दिखाई देगा:


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

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

ChildBlockLengthCheck - एक जांच जो नेस्टेड ऑपरेटरों के आकार के प्रतिशत की जांच करता है (ऑपरेटरों के शरीर द्वारा कब्जा लाइनों की संख्या की तुलना करता है)। यह चेक एक चेतावनी प्रदर्शित करता है यदि नेस्टेड ऑपरेटर का शरीर का आकार ऑपरेटर के आकार के एन% से अधिक है जो एक स्तर अधिक है। एक चेक केवल चेतावनी प्रदर्शित करता है अगर नेस्टेड स्टेटमेंट m लाइनों से अधिक हो। यह तब सुविधाजनक होता है जब आपको ऐसे ब्लॉक खोजने की आवश्यकता होती है जो स्क्रीन पर पूरी तरह से फिट नहीं होते हैं और पेरेंट ब्लॉक की बहुत सी लाइनों पर कब्जा कर लेते हैं।

AvoidModifiersForTypesCheck - आपको 4 प्रकार के कीवर्ड में से एक या अधिक के उपयोग को प्रतिबंधित करने की अनुमति देता है: स्थिर, अंतिम, क्षणिक, निर्दिष्ट प्रकारों की वस्तुओं के लिए अस्थिर। पैरामीटर के रूप में, प्रत्येक 4 कीवर्ड के लिए यह चेक आपको 4 अलग-अलग नियमित अभिव्यक्ति निर्दिष्ट करने की अनुमति देता है जो वांछित प्रकार के नाम प्रारूप को निर्दिष्ट करते हैं।

AvoidModifiersForTypesCheck उपयोग उदाहरण: ULC ग्राफिक्स लाइब्रेरी ऑब्जेक्ट्स (ULCCompords) स्थिर नहीं होना चाहिए: लिंक । इसलिए, चेकस्टाइल के साथ यह बहुत ही उचित है कि सभी वस्तुओं को "स्थिर" कीवर्ड के असाइनमेंट को निषिद्ध करें, जिसका वर्ग नाम शुरू होता है, उदाहरण के लिए, "यूएलसी"।

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

अपने स्वयं के अपवादों का प्रतिनिधित्व करने वाले वर्ग वर्ग नाम (नियमित अभिव्यक्ति का उपयोग करके पाए जाते हैं, जो इनपुट पैरामीटर के रूप में निर्दिष्ट है)।

चेक पर भी उनके नाम से कुछ वर्गों की अनदेखी की संभावना है - फिर से एक नियमित अभिव्यक्ति का उपयोग कर।

ForbidsCertainImportsCheck - एक चेक जो नियमित अभिव्यक्ति द्वारा कुछ पैकेजों / प्रकारों के आयात पर प्रतिबंध लगाता है (यह चेक इसी सोनार चेक के समान है)।

ForbidInstantiationCheck - एक चेक जो किसी दिए गए प्रकार की वस्तुओं की तात्कालिकता को रोकता है। उदाहरण उदाहरण: मान लें कि हमें java.lang.NullPointerException ऑब्जेक्ट के निर्माण को पूरी परियोजना के स्तर पर प्रतिबंधित करने की आवश्यकता है (हमारी कंपनी में, एनपीई ऑब्जेक्ट बनाने को खराब रूप माना जाता है)। पैरामीटर के रूप में, चेक उन योग्य पथों की अल्पविराम से अलग की गई सूची को स्वीकार करता है, जिन्हें तत्काल किए जाने की अनुमति नहीं है:

«java.lang.NullPointerException, your.custom.Class, etc.»

ReturnCountExtendedCheck - एक जाँच जो विधियों और निर्माणकर्ताओं में वापसी खोजशब्दों की संख्या की जाँच करता है। चेक में लचीली अनदेखी सेटिंग्स है, इसकी मदद से, आप केवल एन रिटर्न स्टेटमेंट्स से अधिक के साथ लेखन विधियों पर प्रतिबंध नहीं लगा सकते हैं। यह जाँच केवल "वापसी" बयानों को "गिन" सकती है जो:

• विधि / निर्माणकर्ता की पहली मी लाइनों के भीतर झूठ मत बोलो (ऐसे वापसी बयान अक्सर "जल्दी से" परोसते हैं) जब निर्माण की प्रक्रिया से बाहर निकल जाते हैं, तो या तो अपेक्षित आउटपुट मान या, नल विधि के लिए पैरामीटर की जाँच कर रहे हैं या ...
• कश्मीर से अधिक परिचालकों के घोंसले के स्तर पर झूठ (जैसे "वापसी" जटिल निर्माणों से बाहर निकलने की सेवा कर सकता है और गिना नहीं जा सकता)
• छोटे तरीकों में नहीं हैं। यदि विधि स्क्रीन पर फिट बैठती है, तो यह अक्सर कोड पठनीयता को खोए बिना "रिटर्न" बयानों की एक बड़ी संख्या का उपयोग करने के लिए काफी स्वीकार्य है।

इसके अलावा, यह चेक आपको नियमित अभिव्यक्ति का उपयोग करके उनके नामों द्वारा कुछ तरीकों की अनदेखी करने की अनुमति देता है।

संक्षिप्त नामवापस नियमनामचेक - एक चेक जो लगातार बड़े अक्षरों की संख्या के लिए वर्ग नामों की जांच करता है। यानी - यह जाँच "MDCContextListener" जैसी जावा कक्षाओं के नामकरण पर रोक लगाने के लिए है, जिसका नाम बदलकर "MdcContextListener" करने का सुझाव दिया गया है। एक समान चेक की आवश्यकता न केवल वर्ग नामों को मानकीकृत करने के लिए है। यह उपयोगी है कि इनपुट मापदंडों की सहायता से आप उन संक्षिप्ताक्षरों के नामों की जाँच कर सकते हैं जो अपवाद होंगे।

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

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

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

यह सब, देखने के लिए धन्यवाद)