कस्टम स्विफ्टलिंट नियम

हाय हमर! मेरा नाम एलेक्स है, मैं iOSCH को FINCH पर हूं। जल्द ही नया साल अलग ढंग से जीना शुरू करने का समय है, और स्विफ्टलिंट जैसी शांत चीज इसमें मदद करेगी। लेख में मैं आपको बताऊंगा कि क्यों इसे सभी परियोजनाओं में लागू किया जाना चाहिए, जिसमें विरासत और पालतू परियोजनाएं भी शामिल हैं, और यह भी बताती हैं कि नियमित लाइनों का उपयोग करके इस उपकरण का अधिकतम लाभ कैसे प्राप्त किया जाए।

मैं आपको नहीं बताऊंगा कि स्विफ्टलिंट क्या है और इसे कैसे स्थापित किया जा सकता है - यदि आप उपकरण से परिचित नहीं हैं, तो आधिकारिक दस्तावेज पढ़ना बेहतर है।

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

तो, याद रखें:

1. स्विफ्टलाइन आपको करने की अनुमति देता है:

• स्टाइल गाइड के साथ एक शैली

वास्तव में सब कुछ।

लेख यहां समाप्त हो सकता है, लेकिन अगर ऐसा था, तो मैं इस लेख को लिखना शुरू नहीं करूंगा। दिलचस्प बात यह है कि स्विफ्टलाइन आपको करने की अनुमति नहीं देती है - वें ... हॉट फ़िक्स कोड।

2. SwiftLint आपको रोकने की अनुमति देता है:

• फोर्स अनप्रैप
• मजबूत प्रतिनिधि
• CyclomaticComplexity
• कुछ और ...

मुझे लगता है कि ऐसी गलतियों से सुरक्षित रहना अच्छा है, है ना? यह एक नौसिखिया डेवलपर के लिए विशेष रूप से अच्छा है, क्योंकि वह केवल सीखता है और कई बार ऐसी त्रुटियों पर संदेह नहीं करता है।

3. स्विफ्टलिंट का अपने नियमों के अनुसार विस्तार किया जा सकता है।

मैं उन वर्गों के लिए अंतिम निर्दिष्ट करके शुरू करूँगा जो दूसरों के लिए माता-पिता नहीं होंगे। अंतिम के लिए धन्यवाद, हम प्रोजेक्ट असेंबली समय बचाते हैं। यहां बताया गया है कि Apple प्रलेखन हमें अंतिम कक्षाओं के बारे में क्या बताता है:

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

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

final_class: included: ".*.swift" name: "Final class requrement" regex: '^class' message: "All classes must be final or nonfinal" saverity: error 

एक छोटा और काफी सरल उदाहरण। मैं प्रत्येक नियम के लिए कुछ समान नहीं लिखूंगा, लेकिन स्रोत कोड लेख के अंत में होगा।

 class SomeClass { } //  internal class SomeClass { } //  /* @non-final */ class SomeClass { } //   

अगले बिंदु के लिए आवश्यक है। हम कंपनी में स्टोरीबोर्ड का उपयोग नहीं करते हैं, इसलिए प्रत्येक UIView वर्ग में एक घातक आरंभीकरण निर्दिष्ट करना पूरी तरह से सामान्य नहीं है। इस मामले के लिए, हमारे पास अपना खुद का NLView (NL - NibLess) है - एक ऐसा वर्ग जिसमें आवश्यक init केवल एक बार लागू किया जाता है। परियोजना के नए डेवलपर्स को यह नहीं पता होगा, लेकिन स्विफ्टलिंट का लाभ हमेशा जिम्मेदार नेतृत्व के बजाय डांटता है। या इसके साथ।

 required_init: regex: 'required init\?\(coder: NSCoder\)' message: "Use NL class instead" 

यदि आप अभी भी स्टोरीबोर्ड का उपयोग कर रहे हैं, तो आप यह जानने के लिए निम्न नियमों का उपयोग कर सकते हैं कि आपके सभी स्टोरीबोर्ड निजी हैं:

 open_iboutlets: included: ".*.swift" name: "IBOutlet opening" regex: '@IBOutlet ?(weak){0,1} var' message: "IBOutlet should be private" severity: error 

 open_ibaction: included: ".*.swift" name: "IBAction opening" regex: '@IBAction func' message: "IBAction should be private" severity: error 

अक्सर ऐसा होता है कि फाउंडेशन का उपयोग किया जाता है जहां यह पूरी तरह से अनावश्यक है। इसलिए, हर बार इसे उजागर करना बेहतर है ताकि इसे न भूलें:

  foundation_using: included: ".*.swift" regex: 'import Foundation' message: "Do you really need for Foundation ???" 

मुझे आशा है कि हर कोई जानता है कि प्रिंट एक कठिन प्रक्रिया है, जो अनुप्रयोग प्रदर्शन (विशेषकर लूप में) को बहुत नुकसान पहुंचा सकता है। एकमात्र निर्णय - प्रिंट बिल्कुल नहीं होना चाहिए।

 print_using: regex: 'print' message: "Print decrease performance of the app" severity: error 

इसके अलावा, आपको क्लास केवल प्रोटोकॉल नहीं बनाना चाहिए, क्योंकि ऐसी संभावना है कि इस तरह के सिंटैक्स जल्द ही पदावनत हो जाएंगे और स्विफ्ट डेवलपर्स द्वारा इसकी सिफारिश नहीं की जाती है ।

 class_protocol: regex: ': class' message: "Use Anyobject instead" 

नीचे उन परियोजनाओं के लिए नियम है जो R.swift का उपयोग करते हैं।

 image_name_initialization: included: ".*.swift" name: "Image initialization without R.swift" regex: 'UIImage\(named:[^)]+\)' message: "Use R.image.name() or typealias of this instead" severity: error 

यह केवल एक छोटा सा हिस्सा है जो मैं साथ आ सकता था, लेकिन इंटरनेट पर और भी कम उदाहरण हैं। आप मेरे पूरे "संग्रह" को github पर देख सकते हैं ।

आपका ध्यान के लिए धन्यवाद। यदि आप कस्टम नियमों के साथ स्विफ्टलाइन का भी उपयोग करते हैं, तो हमें उनके बारे में बताएं - मुझे संभव मामलों पर चर्चा करने में खुशी होगी।