लाइनिंग रूबी कोड

लाइनिंग संभावित समस्याओं की खोज में कोड का सांख्यिकीय विश्लेषण करने की प्रक्रिया है।

इस मामले में समस्या क्या है, यह प्रोग्रामिंग भाषाओं में, या समान भाषा में सभी परियोजनाओं में भिन्न हो सकती है। मैं इन समस्याओं को कुछ अलग श्रेणियों में रखूंगा:

• प्रोग्रामेटिक
• सुरक्षा
• शैलीगत
• प्रदर्शन

आइए प्रत्येक के कुछ उदाहरण देखें।

शैलीगत समस्याएं

कोड को स्टाइल करने का कोई वस्तुनिष्ठ सही तरीका नहीं है, क्योंकि यह पाठक की पसंद के बारे में है। कुंजी हालांकि निरंतरता है। वाद-विवाद के सामान्य बिंदुओं में शामिल हैं:

1. डबल-कोट्स बनाम सिंगल-कोट्स
2. टैब बनाम स्पेस
3. अधिकतम लाइन लंबाई
4. मल्टीलाइन कॉल का इंडेंटेशन, जैसा कि नीचे दिखाया गया है:

# always single-line
foo(:a, :b, :c)
 
# aligned with first argument
foo(:a,
    :b,
    :c
)
 
# aligned with function name
foo(
  :a,
  :b
)

ये पूरी तरह से व्यक्तिपरक हैं, लेकिन आमतौर पर प्रत्येक विशेष प्रोजेक्ट के लिए एक मानक पर सहमत होना फायदेमंद होता है, ताकि पूरे कोडबेस को एक समान रखा जा सके।

प्रोग्राम संबंधी समस्याएं

मैं यहां इस तरह की समस्याओं को शामिल करता हूं:

• अत्यंत लंबी विधि निकाय, जो पठनीयता और रखरखाव के मुद्दों की ओर ले जाती है
• चक्रीय जटिलता, एक मीट्रिक जो आमतौर पर कोड जटिलता को मापने के लिए उपयोग की जाती है
• शर्तों के भीतर असाइनमेंट। सबसे अधिक संभावना है, यदि आप if x = true टाइप करते हैं , आपका वास्तव में मतलब था if x == true . और यहां तक ​​कि अगर आपका मतलब एक असाइनमेंट था, तब भी यह एक कम सहज दृष्टिकोण है

सुरक्षा समस्या

कुछ कार्यों या प्रथाओं में संभावित सुरक्षा समस्याएं होती हैं जिनके बारे में डेवलपर्स को पता नहीं हो सकता है।

उदाहरण के लिए, रूबी में, Kernel#open एक लचीला फ़ंक्शन है जो फ़ाइलों या बाहरी URL को खोलने की अनुमति देता है। लेकिन यह open("| ls") . जैसी अजीब कॉलों के साथ, मनमाने ढंग से फाइल सिस्टम एक्सेस की भी अनुमति देता है .इसलिए, डेवलपर्स को इसके बारे में चेतावनी देना समझदारी है ताकि वे या तो एक सुरक्षित दृष्टिकोण का उपयोग कर सकें (File#open , IO.popen , URI.parse#open ), या व्यवहार को अपने जोखिम पर रखने का स्पष्ट निर्णय लें।

प्रदर्शन समस्या

रूबी के आंतरिक कामकाज के बारे में कई विवरण हैं जो संदर्भ के आधार पर कुछ विकल्पों को दूसरों की तुलना में अधिक प्रदर्शनकारी बनाते हैं।

उनके बारे में हमें चेतावनी देने वाला एक लिंटर हमें अपने कार्यक्रम के कुछ विवरणों को अनुकूलित करते हुए रास्ते में सीखने में मदद करता है।

उदाहरण के लिए, रूबी 2.5 ने String#delete_suffix introduced पेश किया जो एक स्ट्रिंग के अंत से सबस्ट्रिंग को हटा देता है। ये दो पंक्तियाँ समतुल्य हैं, लेकिन बाद वाली एक अधिक प्रदर्शनकारी है क्योंकि यह एक सामान्य स्ट्रिंग रेगेक्समैच पर निर्भर नहीं है:

str = 'string_with_suffix'
 
# bad
str.gsub(/suffix\z/, '')
 
# good
str.delete_suffix('suffix')

ऑटो फिक्सिंग

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

कन्वेंशन या कॉन्फ़िगरेशन

एक समुदाय या परियोजना के भीतर अक्सर भारी बहस होती है जिस पर नियम समझ में आता है।

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

रूबी में, यह कमोबेश दो मौजूदा लिंटरों में अनुवाद करता है:रूबोकॉप, जो पूर्ण-कॉन्फ़िगरेशन और मानकआरबी की अनुमति देता है, जो विपरीत दृष्टिकोण लेता है और एक सामान्य मानक को परिभाषित करता है।

रूबोकॉप

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

# configure max allowed line length
Layout/LineLength:
  Max: 80
 
# disable cyclomatic complexity
Metrics/CyclomaticComplexity:
  Enabled: false

इसमें पहले से ही समझदार डिफ़ॉल्ट शामिल हैं, इसलिए कॉन्फ़िगरेशन केवल उन विशिष्ट नियमों के लिए आवश्यक है जिन्हें आप बदलना चाहते हैं।

चल रहा है bundle exec rubocop रुबोकॉप पूरे कोडबेस का विश्लेषण करेगा और इसमें पाए गए सभी मुद्दों को सूचीबद्ध करेगा:

# test.rb
def badName
  if something
    return "inner result"
  end
 
  "outer result"
end

$ bundle exec rubocop
Inspecting 1 file
C
 
Offenses:
 
test.rb:1:1: C: [Correctable] Style/FrozenStringLiteralComment: Missing frozen string literal comment.
def badName
^
test.rb:1:5: C: Naming/MethodName: Use snake_case for method names.
def badName
    ^^^^^^^
test.rb:2:3: C: [Correctable] Style/IfUnlessModifier: Favor modifier if usage when having a single-line body. Another good alternative is the usage of control flow &&/||.
  if something
  ^^
test.rb:3:12: C: [Correctable] Style/StringLiterals: Prefer single-quoted strings when you don't need string interpolation or special symbols.
    return "inner result"
           ^^^^^^^^^^^^^^
test.rb:6:3: C: [Correctable] Style/StringLiterals: Prefer single-quoted strings when you don't need string interpolation or special symbols.
  "outer result"
  ^^^^^^^^^^^^^^
 
1 file inspected, 5 offenses detected, 4 offenses auto-correctable

फिर आप bundle exec rubocop --auto-correct चला सकते हैं , और आपकी अधिकांश समस्याओं का समाधान आपके कॉन्फ़िगरेशन के अनुसार किया जाएगा।

bundle exec rubocop सेट करना आपकी सीआई पाइपलाइन के हिस्से के रूप में यह सुनिश्चित करेगा कि पहले लाइनिंग नियमों को पूरा किए बिना कोई कोडगेट न हो।

StandardRB

एक और हालिया प्रोजेक्ट, जो वास्तव में हुड के तहत रूबोकॉप का उपयोग करता है। StandardRB का मुख्य लक्ष्य पूरी तरह से अलग लिंटर बनाना नहीं है, बल्कि एक ऐसे मानक तक पहुंचना है, जिसके बारे में बहस करने के बजाय हर कोई उपयोग कर सकता है।

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

चूंकि रूबोकॉप का उपयोग नीचे किया जाता है, इसलिए आपको जो आउटपुट मिलता है वह वास्तव में उसी प्रारूप में होता है। केवल अंतर यह है कि आपको किसी भी नियम को अनुकूलित करने की अनुमति नहीं है।

StandardRB हाल ही में 1.0.0 पर पहुँच गया है, जिसका अर्थ है कि किन नियमों का उपयोग करना है, इसके बारे में अधिकांश चर्चा उनके मुद्दों पृष्ठ पर पहले ही हो चुकी है। यदि आप किसी विशेष नियम की परवाह करते हैं या असहमत हैं, तो संभावना है कि आप इसके बारे में संबंधित चर्चा देखेंगे।

अंतत:हालांकि, आप आश्वस्त हो सकते हैं कि इस पर कुछ गहराई से चर्चा की गई थी। पूरे समुदाय के लिए सभी बिंदुओं पर 100% सहमत होना असंभव है। इस दृष्टिकोण का दर्शन यह है कि लोग लचीले होते हैं और असहमत हो सकते हैं और निर्णय के लिए प्रतिबद्ध हो सकते हैं।

अंतिम विचार

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

अधिकांश नियमों के लिए स्वचालित सुधारों के साथ-साथ चर्चाओं के ऊपरी हिस्से को हटाते हुए निरंतरता के सभी लाभों को ध्यान में रखते हुए, हमें बेहतर सॉफ़्टवेयर को अधिक कुशलता से वितरित करने में मदद मिलती है, और जो वास्तव में मायने रखता है उस पर ध्यान केंद्रित करता है।

अन्य भाषाएं समान निम्न-कॉन्फ़िगरेबिलिटी कोड स्वरूपकों को अपना रही हैं। mix formatter अमृत ​​में, और rustfmt जंग में दोनों कुछ विन्यास के लिए अनुमति देते हैं, लेकिन समुदाय आश्चर्यजनक रूप से मानक को ध्यान में रखते हुए जहाज पर है।

इसके साथ ही, रुबोकॉप अभी भी एक पूरी तरह से वैध विकल्प है यदि आप विडंबना यह है कि इस भावना से असहमत हैं।

पी.एस. यदि आप रूबी मैजिक की पोस्ट प्रेस से छूटते ही पढ़ना चाहते हैं, तो हमारे रूबी मैजिक न्यूजलेटर की सदस्यता लें और एक भी पोस्ट मिस न करें!