RuboCop के साथ Ruby कोड गुणवत्ता सुधारें: लिंटिंग और ऑटो-फॉर्मेटिंग

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

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

RuboCop इंस्टॉल करना

RubyGems के माध्यम से RuboCop इंस्टॉल करना सीधा है:

$ gem install rubocop

इंस्टॉल किए गए वर्जन की जांच करें:

$ rubocop --version
1.18.3

यदि आप Bundler का उपयोग करना पसंद करते हैं, तो नीचे दिए गए स्निपेट को अपने Gemfile में रखें और फिर bundle install चलाएँ। require: false भाग Bundler.require को उस विशिष्ट जेम को आपके कोड में आवश्यक न करने के लिए कहता है क्योंकि इसका उपयोग केवल कमांड लाइन से किया जाएगा।

gem 'rubocop', require: false

इंस्टॉल किए गए वर्जन की जांच करें:

$ bundle exec rubocop --version
1.18.3

RuboCop चलाना

आप RuboCop को इसकी डिफ़ॉल्ट सेटिंग्स का उपयोग करके अपने प्रोजेक्ट पर rubocop टाइप करके चला सकते हैं (या bundle exec rubocop यदि Bundler के साथ इंस्टॉल किया गया है)। यदि आप कमांड को कोई आर्गुमेंट पास नहीं करते हैं, तो यह करंट डायरेक्टरी में सभी Ruby सोर्स फाइल्स के साथ-साथ सभी सब-डायरेक्टरीज की जांच करेगा। वैकल्पिक रूप से, आप उन फाइलों और डायरेक्टरीज की सूची पास कर सकते हैं जिनका विश्लेषण किया जाना चाहिए।

$ bundle exec rubocop
$ bundle exec rubocop src/lib

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

रिपोर्ट के नीचे, आपको एक लाइन दिखाई देगी जो निरीक्षित फाइलों की संख्या, कुल ऑफेंस की संख्या, और कितने ऑफेंस स्वचालित रूप से ठीक किए जा सकते हैं, का वर्णन करती है। यदि आप -a या --auto-correct आर्गुमेंट जोड़ते हैं, तो RuboCop आपकी सोर्स फाइलों में पाई गई समस्याओं को स्वचालित रूप से ठीक करने का प्रयास करेगा (जिन्हें [Correctable] से प्रीफिक्स किया गया है)।

$ bundle exec rubocop -a

ध्यान दें कि प्रत्येक ठीक किया गया ऑफेंस अब [Corrected] से प्रीफिक्स्ड है। रिपोर्ट के नीचे ठीक किए गए ऑफेंस की संख्या का सारांश भी प्रस्तुत किया गया है। उपरोक्त उदाहरण में, एक और ठीक करने योग्य ऑफेंस था जिसे -a फ्लैग जोड़ने के बाद भी ऑटो-फिक्स नहीं किया गया था। ऐसा इसलिए है क्योंकि कुछ स्वचालित सुधार कोड के अर्थ को थोड़ा बदल सकते हैं, इसलिए RuboCop इसे असुरक्षित मानता है। यदि आप इन ऑफेंस को भी ऑटोकरेक्ट करना चाहते हैं, तो -A या --auto-correct-all फ्लैग का उपयोग करें।

$ bundle exec rubocop -A

पालन करने के लिए एक अच्छा नियम यह है कि ऑटोकरेक्ट कार्यक्षमता का उपयोग करने के बाद अपने टेस्ट सूट को चलाएँ ताकि यह सुनिश्चित हो सके कि आपके कोड का व्यवहार अप्रत्याशित रूप से नहीं बदला है।

RuboCop कॉन्फ़िगर करना

RuboCop को आपके प्रोजेक्ट के रूट में रखी गई .rubocop.yml फाइल के माध्यम से कॉन्फ़िगर किया जा सकता है। यदि आप सभी प्रोजेक्ट्स के लिए समान जांच चाहते हैं, तो आप अपने होम डायरेक्टरी (~/.rubocop.yml) या XDG कॉन्फिग डायरेक्टरी (~/.config/rubocop/config.yml) में एक ग्लोबल कॉन्फिग फाइल रख सकते हैं। यदि करंट डायरेक्टरी या क्रमिक पैरेंट डायरेक्टरी में स्थानीय रूप से स्कोप्ड प्रोजेक्ट कॉन्फिगरेशन फाइल नहीं मिलती है, तो इस ग्लोबल कॉन्फिग फाइल का उपयोग किया जाएगा।

RuboCop के लिए डिफ़ॉल्ट कॉन्फ़िगरेशन इसके कॉन्फ़िगरेशन होम डायरेक्टरी (~/.config/rubocop/default.yml) में रखा जाता है, और अन्य सभी कॉन्फिग फाइलें इससे विरासत में लेती हैं। इसका अर्थ है कि जब आप अपना प्रोजेक्ट कॉन्फ़िगरेशन सेट कर रहे हों, तो आपको केवल उन परिवर्तनों को करने की आवश्यकता है जो डिफ़ॉल्ट से अलग हैं। इसका अर्थ कुछ जांचों को सक्षम या अक्षम करना या उनके व्यवहार को बदलना हो सकता है यदि वे कोई पैरामीटर स्वीकार करते हैं।

RuboCop प्रत्येक व्यक्तिगत जांच को "कॉप्स" के रूप में संदर्भित करता है, और प्रत्येक एक विशिष्ट ऑफेंस का पता लगाने के लिए जिम्मेदार होता है। उपलब्ध कॉप्स को निम्न विभागों में भी समूहीकृत किया जाता है:

• स्टाइल कॉप्स ज्यादातर उपरोक्त Ruby स्टाइल गाइड पर आधारित होते हैं, और वे आपके कोड की स्थिरता की जांच करते हैं।
• लेआउट कॉप्स फॉर्मेटिंग से संबंधित मुद्दों को पकड़ते हैं, जैसे व्हाइट स्पेस का उपयोग।
• लिंट कॉप्स आपके कोड में संभावित त्रुटियों का पता लगाते हैं, ruby -w के समान, लेकिन अतिरिक्त जांच के एक मेजबान के साथ।
• मेट्रिक कॉप्स सोर्स कोड माप से संबंधित मुद्दों से निपटते हैं जैसे क्लास लंबाई और मेथड लंबाई।
• नेमिंग कॉप्स नामकरण परंपराओं से संबंधित हैं।
• सिक्योरिटी कॉप्स संभावित सुरक्षा मुद्दों को पकड़ने में मदद करते हैं।
• बंडलर कॉप्स बंडलर फाइलों (जैसे Gemfile) में खराब प्रथाओं की जांच करते हैं।
• जेमस्पेक कॉप्स .gemspec फाइलों में खराब प्रथाओं की जांच करते हैं।

अतिरिक्त लिंटर्स और फॉर्मेटर्स के माध्यम से RuboCop को विस्तारित करना भी संभव है। आप अपने स्वयं के एक्सटेंशन बना सकते हैं या मौजूदा लोगों का लाभ उठा सकते हैं यदि वे आपके प्रोजेक्ट के लिए प्रासंगिक हैं। उदाहरण के लिए, Rails सर्वोत्तम प्रथाओं और कोडिंग कन्वेंशन को लागू करने के उद्देश्य से एक Rails एक्सटेंशन उपलब्ध है।

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

# .rubocop.yml
AllCops:
  NewCops: enable

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

आप इसे अपने Gemfile में निम्न लाइन जोड़कर और फिर bundle install चलाकर इंस्टॉल कर सकते हैं।

# Gemfile
gem "standard", group: [:development, :test]

इसके बाद, आप कमांड लाइन से Standard को निम्नानुसार निष्पादित कर सकते हैं:

$ bundle exec standardrb

मौजूदा प्रोजेक्ट में RuboCop जोड़ना

अधिकांश Rubyists के पास ग्रीनफील्ड प्रोजेक्ट्स पर काम करने का सौभाग्य नहीं होता। हमारा अधिकांश विकास समय विरासत कोडबेस में व्यतीत होता है जो लिंटिंग ऑफेंस की एक भारी मात्रा उत्पन्न कर सकते हैं जिन्हें तुरंत निपटाया नहीं जा सकता। सौभाग्य से, RuboCop में एक उपयोगी विशेषता है जो मौजूदा ऑफेंस की एक अनुमति सूची जनरेट करती है, जिसे समय के साथ धीरे-धीरे संबोधित किया जा सकता है। लाभ यह है कि यह आपको अपने मौजूदा प्रोजेक्ट में लिंटिंग पेश करने की अनुमति देता है बिना प्रबंधन न करने योग्य लिंटिंग त्रुटियों के पहाड़ से घिरे हुए जबकि आगे बढ़ने वाले किसी भी नए उल्लंघन को चिह्नित करता है।

$ bundle exec rubocop
523 files inspected, 1018 offenses detected

अनुमति सूची कॉन्फिग फाइल बनाने के लिए नीचे दी गई कमांड के माध्यम से किया जा सकता है:

$ bundle exec rubocop --auto-gen-config
Added inheritance from `.rubocop_todo.yml` in `.rubocop.yml`.
Created .rubocop_todo.yml.

--auto-gen-config विकल्प सभी ऑफेंस और उनकी संख्या एकत्र करता है और करंट डायरेक्टरी में एक .rubocop_todo.yml फाइल जनरेट करता है जहाँ सभी वर्तमान ऑफेंस को नजरअंदाज किया जाता है। अंत में, यह .rubocop.yml को .rubocop_todo.yml फाइल से विरासत में लेने का कारण बनता है ताकि कोडबेस पर एक बार फिर RuboCop चलाने से कोई ऑफेंस न मिले।

$ bundle exec rubocop
523 files inspected, no offenses detected

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

$ bundle exec rubocop --auto-gen-config --auto-gen-only-exclude --exclude-limit 10000

--auto-gen-only-exclude विकल्प यह सुनिश्चित करता है कि अनुमति सूची में प्रत्येक कॉप के पास एक Exclude ब्लॉक हो जो उन सभी फाइलों को सूचीबद्ध करता है जहाँ उल्लंघन हुआ, Max के बजाय, जो एक कॉप के लिए बाहर की गई फाइलों की अधिकतम संख्या निर्धारित करता है। --exclude-limit सेट करने से प्रत्येक कॉप के लिए Exclude ब्लॉक में जोड़ी जा सकने वाली फाइलों की अधिकतम संख्या भी बदल जाती है। जांच की जा रही कुल फाइलों की संख्या से बड़ी एक मनमानी संख्या निर्दिष्ट करने से यह सुनिश्चित होता है कि कोई भी कॉप पूरी तरह से अक्षम नहीं होगा, और मौजूदा या नई फाइलों में जोड़ा गया कोई भी नया कोड तदनुसार जांचा जाएगा।

मौजूदा उल्लंघनों को ठीक करना

.rubocop_todo.yml फाइल जनरेट करने के बाद, मौजूदा उल्लंघनों को न भूलना महत्वपूर्ण है, बल्कि उन्हें एक-एक करके धीरे-धीरे संबोधित करना है। आप इसे एक फाइल को कॉप के Exclude ब्लॉक से हटाकर, फिर रिपोर्ट किए गए उल्लंघनों को ठीक करके, बग्स पेश करने से बचने के लिए अपने टेस्ट सूट को चलाकर, और कमिट करके कर सकते हैं। एक बार जब आप एक कॉप से सभी फाइलों को हटा देते हैं, तो आप कॉप को फाइल से मैन्युअली हटा सकते हैं, या एक बार फिर अनुमति सूची फाइल को पुनर्जनरेट कर सकते हैं। जहाँ संभव हो --auto-correct विकल्प का उपयोग करना न भूलें ताकि प्रक्रिया बहुत तेज हो जाए।

स्टाइल गाइड अपनाना

RuboCop बहुत कॉन्फ़िगर करने योग्य है, जो इसे किसी भी प्रकार के प्रोजेक्ट के लिए व्यवहार्य बनाता है। हालांकि, नियमों को आपकी आवश्यकताओं के अनुसार कॉन्फ़िगर करने में लंबा समय लग सकता है, खासकर यदि आप कई डिफ़ॉल्ट नियमों से असहमत हैं। ऐसी परिस्थितियों में, मौजूदा स्टाइल गाइड को अपनाना फायदेमंद हो सकता है। कई कंपनियों ने पहले ही अपने Ruby स्टाइल गाइड सार्वजनिक उपभोग के लिए जारी कर दिए हैं, जैसे Shopify और Airbnb। RuboCop में अपने पसंदीदा स्टाइल गाइड का उपयोग करना आपके Gemfile में संबंधित जेम जोड़कर प्राप्त किया जा सकता है:

# Gemfile
gem "rubocop-shopify", require: false

फिर, इसे अपने प्रोजेक्ट कॉन्फ़िगरेशन में आवश्यक करें:

# .rubocop.yml
inherit_gem:
  rubocop-shopify: rubocop.yml

लिंटिंग त्रुटियों को दबाना

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

# rubocop:disable Layout/LineLength, Style
[..]
# rubocop:enable Layout/LineLength, Style

या आप एक ही बार में कोड के एक सेक्शन के लिए सभी कॉप्स को अक्षम कर सकते हैं:

# rubocop:disable all
[..]
# rubocop:enable all

यदि आप एंड-ऑफ-लाइन कमेंट का उपयोग करते हैं, तो निर्दिष्ट कॉप्स केवल उस लाइन के लिए अक्षम हो जाएंगे।

for x in (0..10) # rubocop:disable Style/For

एडिटर इंटीग्रेशन

कमांड लाइन के माध्यम से हर बार जांच चलाने के बजाय, कोड टाइप करते समय एडिटर में RuboCop द्वारा उत्पादित चेतावनियों और त्रुटियों को देखना आसान है। शुक्र है, RuboCop इंटीग्रेशन ज्यादातर लोकप्रिय कोड एडिटर्स और IDEs में उपलब्ध है, ज्यादातर थर्ड-पार्टी प्लगइन्स के माध्यम से। Visual Studio Code में, आपको केवल इस Ruby एक्सटेंशन को इंस्टॉल करना होगा और अपने यूजर settings.json फाइल में निम्न रखना होगा:

{
  "ruby.lint": {
    "rubocop": true
  }
}

यदि आप Vim या Neovim का उपयोग करते हैं, तो आप coc.nvim के माध्यम से RuboCop के डायग्नोस्टिक्स प्रदर्शित कर सकते हैं। आपको Solargraph लैंग्वेज सर्वर (gem install solargraph) इंस्टॉल करना होगा, इसके बाद coc-solargraph एक्सटेंशन (:CocInstall coc-solargraph)। इसके बाद, अपने coc-settings.json फाइल को नीचे दिखाए अनुसार कॉन्फ़िगर करें:

{
  "coc.preferences.formatOnSaveFiletypes": ["ruby"],
  "solargraph.autoformat": true,
  "solargraph.diagnostics": true,
  "solargraph.formatting": true
}

प्री-कमिट हुक सेट अप करना

यह सुनिश्चित करने का एक शानदार तरीका है कि प्रोजेक्ट में सभी Ruby कोड सोर्स कंट्रोल में चेक इन होने से पहले ठीक से लिंटेड और फॉर्मेटेड हैं, एक Git प्री-कमिट हुक सेट अप करना है जो प्रत्येक स्टेज्ड फाइल पर RuboCop चलाता है। यह लेख आपको दिखाएगा कि Overcommit के साथ इसे कैसे सेट अप करें, Git प्री-कमिट हुक्स को प्रबंधित और कॉन्फ़िगर करने के लिए एक टूल, लेकिन यदि आपके पास पहले से मौजूद प्री-कमिट वर्कफ़्लो है तो आप RuboCop को अन्य टूल्स के साथ भी एकीकृत कर सकते हैं।

सबसे पहले, RubyGems के माध्यम से Overcommit इंस्टॉल करें और फिर इसे अपने प्रोजेक्ट में इंस्टॉल करें:

$ gem install overcommit
$ overcommit --install # आपके प्रोजेक्ट के रूट पर

ऊपर दूसरी कमांड करंट डायरेक्टरी में एक रेपो-विशिष्ट सेटिंग्स फाइल (.overcommit.yml) बनाएगी और किसी भी मौजूदा हुक का बैकअप लेगी। यह फाइल डिफ़ॉल्ट कॉन्फ़िगरेशन को विस्तारित करती है, इसलिए आपको केवल डिफ़ॉल्ट के संबंध में अपना कॉन्फ़िगरेशन निर्दिष्ट करने की आवश्यकता है। उदाहरण के लिए, आप निम्न स्निपेट के माध्यम से RuboCop प्री-कमिट हुक को सक्षम कर सकते हैं:

# .overcommit.yml
PreCommit:
  RuboCop:
    enabled: true
    on_warn: fail
    problem_on_unmodified_line: ignore
    command: ['bundle', 'exec', 'rubocop']

on_warn: fail सेटिंग Overcommit को चेतावनियों को विफलताओं के रूप में मानने का कारण बनती है, जबकि problem_on_unmodified_line: ignore उन चेतावनियों और त्रुटियों को नजरअंदाज करती है जो उन लाइनों पर थीं जिन्हें स्टेज नहीं किया गया था। आप प्रोजेक्ट के GitHub पेज पर उपलब्ध सभी हुक विकल्पों और उनके स्वीकार्य मूल्यों की सीमा ब्राउज़ कर सकते हैं। अपने कॉन्फ़िगरेशन फाइल को बदलने के बाद आपको overcommit --sign चलाने की आवश्यकता हो सकती है ताकि परिवर्तन प्रभावी हों।

कभी-कभी, यदि आप एक ऐसी फाइल कमिट करना चाहते हैं जो सभी जांच पास नहीं करती (जैसे वर्क-इन-प्रोग्रेस), तो आप केस-दर-केस आधार पर व्यक्तिगत जांच को छोड़ सकते हैं:

$ SKIP=RuboCop git commit -m "WIP: Unfinished work"

अपने CI वर्कफ़्लो में RuboCop जोड़ना

प्रत्येक पुल रिक्वेस्ट पर RuboCop जांच चलाना खराब फॉर्मेटेड कोड को आपके प्रोजेक्ट में मर्ज होने से रोकने का एक और तरीका है। हालांकि आप इसे किसी भी CI टूल के साथ सेट अप कर सकते हैं, यह लेख केवल चर्चा करेगा कि GitHub Actions के माध्यम से RuboCop कैसे चलाया जाए।

पहला कदम अपने प्रोजेक्ट के रूट पर .github/workflows डायरेक्टरी बनाना और नई डायरेक्टरी के भीतर rubocop.yml फाइल बनाना है। फाइल को अपने एडिटर में खोलें और इसे निम्नानुसार अपडेट करें:

# .github/workflows/rubocop.yml
name: Lint code with RuboCop
on: [push, pull_request]
jobs:
  build:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [macos-latest, ubuntu-latest, windows-latest]
    steps:
      - uses: actions/checkout@v2
      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.0'
          bundler-cache: true
      - name: Run RuboCop
        run: bundle exec rubocop

उपरोक्त वर्कफ़्लो फाइल एक सिंगल जॉब का वर्णन करती है जो तब निष्पादित होगी जब कोड GitHub पर पुश किया जाता है या जब किसी भी ब्रांच के विरुद्ध पुल रिक्वेस्ट की जाती है। एक job क्रमिक रूप से चलने वाले चरणों का एक क्रम है। यह विशेष जॉब GitHub Actions द्वारा प्रदान किए गए नवीनतम Ubuntu, MacOS, और Windows वर्जन्स पर एक बार चलेगा (जैसा कि runs-on और strategy.matrix द्वारा परिभाषित)। पहला चरण रिपॉजिटरी में कोड को चेक आउट करता है, जबकि अगला Ruby टूल चेन और निर्भरताओं को सेट अप करता है, और अंतिम RuboCop को निष्पादित करता है।

एक बार जब आप फाइल एडिट कर लें, तो इसे सेव करें, कमिट करें, और GitHub पर पुश करें। बाद में, आपको बाद के चेक-इन्स और पुल रिक्वेस्ट पर रिपोर्ट किए गए किसी भी मुद्दे का इनलाइन डिस्प्ले मिलेगा।

वैकल्पिक ऑटो-फॉर्मेटर्स

हालांकि RuboCop व्यापक ऑटो-फॉर्मेटिंग क्षमताएं प्रदान करता है, वैकल्पिक टूल्स के बारे में जागरूक होना भी महत्वपूर्ण है यदि यह आपकी आवश्यकताओं को पर्याप्त रूप से पूरा नहीं करता है।

Prettier

Prettier JavaScript के लिए एक ओपिनियनटेड कोड फॉर्मेटर के रूप में शुरू हुआ, लेकिन अब यह Ruby सहित कई अन्य भाषाओं का समर्थन करता है। इसका Ruby प्लगइन इंस्टॉल करना सीधा है: prettier जेम को अपने Gemfile में जोड़ें और फिर bundle चलाएँ।

# Gemfile
gem 'prettier'

इस बिंदु पर, आप निम्न कमांड के माध्यम से Prettier के साथ अपने Ruby कोड को फॉर्मेट कर सकते हैं:

$ bundle exec rbprettier --write '**/*.rb'

Prettier के कुछ नियम RuboCop के साथ टकराते हैं, इसलिए बाद के फॉर्मेटिंग जांच को अक्षम करना आवश्यक है ताकि यह Prettier के साथ हस्तक्षेप न करे। सौभाग्य से, Prettier के साथ टकराने वाले या अनावश्यक RuboCop जांच को बंद करना आसान है। आपको बस अपने प्रोजेक्ट के .rubocop.yml फाइल के शीर्ष पर Prettier की RuboCop कॉन्फ़िगरेशन को विरासत में लेने की आवश्यकता है:

# .rubocop.yml
inherit_gem:
  prettier: rubocop.yml

अब से जब आप RuboCop चलाएँगे ( bundle exec rubocop के साथ), यह किसी भी लेआउट-संबंधित ऑफेंस की रिपोर्ट नहीं करेगा, जिससे Prettier के लिए उन्हें अपने नियमों के अनुसार सही करने का मार्ग प्रशस्त होगा। आप Prettier के आउटपुट को इसकी कॉन्फ़िगरेशन फाइल के माध्यम से भी कॉन्फ़िगर कर सकते हैं, जिसे उसी प्रोजेक्ट में JavaScript और Ruby कोड के बीच साझा किया जा सकता है।

RubyFmt

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

निष्कर्ष

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

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

पढ़ने के लिए धन्यवाद, और हैप्पी कोडिंग!