Rust कोड रिव्यू: 5 ऐसी बातें जो हर Senior डेवलपर कहेगा

परिचय: Rust इतना सख्त क्यों है, और कोड रिव्यू कैसे मदद करता है?

आपने Rust में कोड लिखा। वह कंपाइल हो गया — वाह! लेकिन समस्या यह है: जब senior डेवलपर आपका Pull Request खोलता है, तो वह आह भरता है और कमेंट लिखना शुरू कर देता है। परिचित लग रहा है? Rust एक अनोखी फिलॉसफी वाली भाषा है: यह आप पर भरोसा करती है, लेकिन सब कुछ जाँचती है। हालाँकि, कंपाइलर वह नहीं देखता जो एक अनुभवी आँख देखती है। वह यह नहीं कहेगा: "अरे, इसे और अच्छे से किया जा सकता है" या "तुम्हारा कोड लीक कर रहा है — मेमोरी से नहीं, तो परफॉरमेंस से।"

इस लेख में हम Rust कोड रिव्यू करेंगे और senior डेवलपर्स की सामान्य टिप्पणियाँ समझेंगे। आप सीखेंगे कि कैसे "बस काम करने वाले कोड" को इडियोमैटिक और भरोसेमंद बनाया जाए। चलिए शुरू करते हैं!

1. टाइप सिस्टम को नज़रअंदाज़ करना: "चलो सब कुछ String में डाल देते हैं"

शुरुआती लोगों की सबसे आम गलती — जहाँ विशिष्ट टाइप चाहिए, वहाँ String या सामान्य टाइप का उपयोग करना। Senior कहेगा: "तुम्हारा टाइप बिज़नेस लॉजिक को दर्शाना चाहिए, न कि सिर्फ एक स्ट्रिंग होना चाहिए।"

समस्या: सिमैंटिक्स का नुकसान

मान लीजिए आप email पतों के साथ काम करने के लिए एक फंक्शन लिख रहे हैं:

fn send_email(to: String, subject: String, body: String) {
    // ...
}

इसमें क्या गलत है? आप to और subject को गलती से बदल सकते हैं — कंपाइलर को पता नहीं चलेगा। Senior newtype पैटर्न का उपयोग करने का सुझाव देगा:

struct Email(String);
struct Subject(String);
struct Body(String);

fn send_email(to: Email, subject: Subject, body: Body) {
    // ...
}

क्या यह ज़रूरत से ज़्यादा लगता है? Rust कोड रिव्यू में यह तरीका सुनहरा मानक है। यह कोड को स्वयं-दस्तावेज़ीकृत बनाता है और गलतियों की एक पूरी श्रेणी को खत्म करता है।

2. clone() का अत्यधिक उपयोग: कॉपी करने का मतलब मालिक होना नहीं है

Junior डेवलपर अक्सर जहाँ कंपाइलर बॉरोइंग पर आपत्ति करता है, वहाँ .clone() का उपयोग करते हैं। Senior कहेगा: "तुम बस borrow checker के सामने हार मान रहे हो। अलग सोचो।"

उदाहरण: अनावश्यक clone

fn process(data: Vec<i32>) {
    let first = data[0].clone();
    let second = data[1].clone();
    // ...
}

i32 Copy ट्रेट को लागू करता है — यहाँ clone() पूरी तरह से अनावश्यक है। लेकिन समस्या गहरी है: यदि आप बड़ी संरचनाओं (जैसे Vec या String) को क्लोन करते हैं, तो आपको परफॉरमेंस का झटका लगता है।

सही तरीका — रेफरेंस के साथ काम करना है:

fn process(data: &[i32]) {
    let first = &data[0];
    let second = &data[1];
    // ...
}

Rust कोड रिव्यू में आपको यह समझाना होगा कि आप क्यों क्लोन कर रहे हैं। यदि जवाब "ताकि कंपाइलर शिकायत न करे" है — तो कड़ी टिप्पणी के लिए तैयार रहें।

3. खराब एरर हैंडलिंग: .unwrap() कोई अंतिम समाधान नहीं है

Senior डेवलपर production कोड में unwrap() और expect() से नफरत करते हैं। क्यों? क्योंकि वे संभावित रूप से ठीक होने योग्य एरर को पैनिक में बदल देते हैं। और Rust में पैनिक का मतलब है आपातकालीन समाप्ति।

इस कोड में क्या गलत है?

let file_content = std::fs::read_to_string("config.txt").unwrap();

अगर फ़ाइल मौजूद नहीं है — प्रोग्राम क्रैश हो जाएगा। Senior सुझाव देगा:

let file_content = std::fs::read_to_string("config.txt")
    .map_err(|e| format!("Failed to read config: {}", e))?;

? ऑपरेटर और अपने खुद के एरर टाइप का उपयोग करें। यह इडियोमैटिक Rust की नींव है। Rust कोड रिव्यू में यह पहली टिप्पणियों में से एक होगी।

4. भूली हुई परफॉरमेंस: एलोकेशन और इटरेटर

Rust एक सिस्टम भाषा है। Senior सिर्फ सुरक्षा ही नहीं, बल्कि गति पर भी ध्यान देगा। एक सामान्य समस्या है अनावश्यक कलेक्शन बनाना।

उदाहरण: बिना ज़रूरत के कलेक्ट करना

let numbers: Vec<i32> = (0..100).collect();
let doubled: Vec<i32> = numbers.iter().map(|x| x * 2).collect();