स्वचालित वर्ग संरचना नियंत्रण

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



सामान्य समस्याएं:

• कंस्ट्रक्टर अप्रत्याशित रूप से कक्षा के बीच में दिखाई देता है;
• भीतरी वर्ग बाहरी वर्ग के बीच में कहीं घोषित होता है;
• एक अमूर्त विधि एक बड़े अमूर्त वर्ग के बीच में कहीं घोषित की जाती है;
• @Autowired विधि कहीं भी स्थित है, लेकिन एक प्रमुख स्थान पर नहीं;
• स्थिर बिल्डर विधियां कक्षा कोड के आसपास बिखरी हुई हैं;
• वर्ग क्षेत्र आंतरिक वर्ग और विधियों के बीच कहीं खो गया था।

इस कोड में स्थायी रूप से थक गए?

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



उपयोगकर्ता फ़ील्ड (फ़ील्ड), विधियों (विधि), निर्माणकर्ताओं (Ctor), आंतरिक वर्गों (इनरक्लास), वर्ग तत्वों के बीच विभाजक "###" के लिए नियमित अभिव्यक्तियों के टुकड़ों का उपयोग करके वर्ग की सामग्री (संरचना) के वांछित प्रारूप का वर्णन करने के लिए आमंत्रित किया जाता है।

एक नियमित अभिव्यक्ति में एक वर्ग संरचना को परिभाषित करते समय, आप एक्सेस संशोधक, एनोटेशन, प्रकार, नाम निर्दिष्ट कर सकते हैं।

उपयोग के उदाहरण

एक साधारण नियम का एक उदाहरण: पहले फ़ील्ड को एक वर्ग, फिर विधियों और फिर आंतरिक कक्षाओं में घोषित किया जाता है:

Field(.*) ### Method(.*) ### InnerClass(.*)





खेतों के लिए एक उदाहरण: सार्वजनिक सांख्यिकी, फिर संरक्षित, फिर एनोटेशन @ स्वचालित, फिर निजी क्षेत्र:

Field(public static final.*) ###

Field((private|protected) static final.*) ###

Field(@Autowired.* public) ###

Field(private.*)





नियम के अंत में "*।" टेम्पलेट छोड़ा जा सकता है - यह स्वचालित रूप से प्रतिस्थापित किया गया है।



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



वास्तविक जीवन से एक नियम का उदाहरण (हमारे कोड का प्रारूप):

Field(private static final long serialVersionUID) ### Field((private|protected) final Log ([\w]*L|l)og|private static final Log [\w]*LOG) ### Field(public static final) ### Field((private|protected) static final) ### Field(@Autowired.* public) ### Field(public.*) ### Field(public) ### Field(private final) ### Field(private.*) ### Field(private) ### Field(.*) ### Method(public static void main.*) ### Method((public|protected)?\w*abstract) ### Method(public static .*(new|edit|create|open|clone).*) ### Ctor(public) ### Ctor(private) ### Method(@Autowired.* public) ### Method(.*) ### InnerClass(.*)



समर्थन चाहिए

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



मैं SourceForge वेबसाइट पर टिप्पणियों में CustomDeclarationOrderCheck का समर्थन करने के लिए समुदाय से पूछना चाहूंगा, या Habrahabr की टिप्पणियों में इनकार के संभावित कारण लिख सकता हूं और इसे अंतिम रूप देने के लायक है, अपने विकास को खुली परियोजनाओं में बढ़ावा देने का अनुभव साझा करें।



जो मॉड्यूल की कार्यक्षमता की जांच करना चाहते हैं वे हमारी विधानसभाओं का उपयोग कर सकते हैं:

1. ग्रहण-सीएस 5.3 ;
2. ग्रहण-सीएस 5.2 ;
3. ग्रहण-सीएस ५.१ ।

ऐसा करने के लिए, आपको अपने संस्करण के एक्लिप्स-सी ( अपडेट साइट ) के लिए संग्रह डाउनलोड करना होगा और <ग्रहण ग्रहण पथ> / प्लगइन्स में प्रस्तावित फ़ाइलों के प्रतिस्थापन के साथ संग्रह से net.sf.eclipsecs.checkstyle_x.xxxxx ... x फ़ोल्डर की सामग्री को कॉपी करना होगा।



प्रस्तावित बिल्ड्स में, हमारी टीम के कई पैच शामिल हैं, जिन्हें चेकस्ली रिलीज में कभी शामिल नहीं किया गया था:

1. अधिकतम लाइन लंबाई की जाँच के लिए अद्यतन ;
2. नई जाँच: CustomDeclarationOrderCheck ;
3. अनेकानेक कार्यविधियाँ ठीक करता है ।

आपके द्वारा चेकस्टाइल प्लगइन स्थापित करने और हमारे अतिरिक्त मॉड्यूल के साथ उस पर एक पैच स्थापित करने के बाद

विंडो -> प्राथमिकताएं -> आपके द्वारा बनाई गई चेकस्टाइल , चेक कॉन्फ़िगरेशन को संपादित करें ( नया , कॉन्फ़िगर करें )।

दिखाई देने वाली कॉन्फ़िगरेशन विंडो में, आपको कोडिंग समस्या मॉड्यूल के समूह में जाने और सूची से एक नया कस्टम घोषणा आदेश चेक मॉड्यूल बनाने की आवश्यकता है।



हमारी टीम CheckStyle के विकास पर काम करना बंद नहीं करती है। ठोस पैच, rusya7 , daniilyar , romanivanov के उपयोगकर्ताओं द्वारा तैयार पैच प्रदान किए गए थे। उपरोक्त सभी विशेष रूप से हब्रायुज़र के समुदाय में शामिल होने के लिए अच्छा होगा।

यहाँ विषय की निरंतरता ।