Swift कोड की समीक्षा: 7 गलतियाँ जो वरिष्ठ डेवलपर्स को परेशान करती हैं

Swift कोड की समीक्षा: सहकर्मियों को परेशान करना कैसे बंद करें और वरिष्ठ स्तर का कोड कैसे लिखें

क्या आपने कभी Pull Request भेजा है और एक घंटे बाद टीम लीड से 15 टिप्पणियाँ मिली हैं? "Force unwrap? सच में?", "एरर हैंडलिंग कहाँ है?", "यह फ्लो कंट्रोलर तीन दिनों से मेमोरी में लटका हुआ है।" परिचित लगता है? Swift कोड समीक्षा की दुनिया में आपका स्वागत है - वह जगह जहाँ अनुभवी डेवलपर्स भी कभी-कभी इंटर्न जैसा महसूस करते हैं।

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

1. Force Unwrap - पहला प्यार और सबसे बड़ा दर्द

सबसे सामान्य लेकिन शाश्वत से शुरू करते हैं। Force unwrap (!) बिना सीट बेल्ट के गाड़ी चलाने जैसा है। यह सुविधाजनक लगता है, लेकिन एक अचानक ब्रेक और आप अस्पताल में हैं।

खराब कोड (सामान्य जूनियर):

func getUserName() -> String {\n    let name: String? = UserDefaults.standard.string(forKey: "user_name")\n    return name!\n}

वरिष्ठ क्या कहेंगे: "अगर UserDefaults में कुछ नहीं है तो? क्रैश। हमेशा। guard let या defaultValue जोड़ें।"

अच्छा कोड:

func getUserName() -> String {\n    guard let name = UserDefaults.standard.string(forKey: "user_name") else {\n        return "अतिथि"\n    }\n    return name\n}

अपवाद: Force unwrap केवल एक मामले में स्वीकार्य है - जब आपको 146% यकीन हो कि मान मौजूद है। उदाहरण के लिए, IBOutlets के साथ काम करते समय, जो गारंटी के साथ इनिशियलाइज़ होंगे। लेकिन यहाँ भी वरिष्ठ private var label: UILabel! का उपयोग करने की सलाह देंगे - यह एक परंपरा है, कोई कच्चा समाधान नहीं।

2. जादुई संख्याएँ और स्ट्रिंग्स: कोड को पहेली नहीं होना चाहिए

दूसरी चीज़ जो Swift कोड समीक्षा पर ध्यान खींचती है - जादुई स्थिरांक। "ठीक 0.75 क्यों? आह, यह एनिमेशन गुणांक है... कौन सा वास्तव में?"। यदि आप सीधे कोड में संख्याएँ और स्ट्रिंग्स लिखते हैं, तो आप सहकर्मियों को जासूसी खेलने पर मजबूर करते हैं।

खराब कोड:

if user.age > 18 {\n    showAdultContent()\n}\nbutton.layer.cornerRadius = 12\nlet url = "https://api.example.com/v1/users"

वरिष्ठ क्या कहेंगे: "18 एक जादुई संख्या है। इसे स्थिरांक में डालें। URL - enum में। cornerRadius - स्टाइलिस्टिक स्थिरांक में। कोड को किताब की तरह पढ़ा जाना चाहिए, कोड की तरह नहीं।"

अच्छा कोड:

private enum Constants {\n    static let adultAgeLimit = 18\n    static let defaultCornerRadius: CGFloat = 12\n    static let baseURL = "https://api.example.com/v1"\n}\n\nenum APIEndpoint {\n    case users\n    var url: String {\n        switch self {\n        case .users: return Constants.baseURL + "/users"\n        }\n    }\n}\n\nif user.age > Constants.adultAgeLimit {\n    showAdultContent()\n}

3. Memory Leaks: गलती से एप्लिकेशन को कैसे लटकाएँ

Swift कोड समीक्षा शायद ही कभी retain cycles की चर्चा के बिना होती है। वरिष्ठों को यह विषय पसंद है क्योंकि यह दिखाता है कि क्या आप समझते हैं कि ARC कैसे काम करता है। सबसे लोकप्रिय एंटीपैटर्न - क्लोजर में weak संदर्भ के बिना self को कैप्चर करना।

खराब कोड:

class NetworkManager {\n    func fetchData(completion: @escaping (Data) -> Void) {\n        URLSession.shared.dataTask(with: url) { data, _, _ in\n            self.process(data) // self को मजबूती से कैप्चर किया गया\n            completion(data)\n        }\n    }\n}

वरिष्ठ क्या कहेंगे: "तुम क्लोजर के अंदर self पर एक मजबूत संदर्भ रख रहे हो। जब तक क्लोजर जीवित है - ऑब्जेक्ट डिलीट नहीं होगा। [weak self] जोड़ें और nil की जाँच करें। या [unowned self] का उपयोग करें, यदि तुम्हें पक्का पता है कि self क्लोजर से अधिक जीवित रहेगा।"

अच्छा कोड:

func fetchDa