Rust में defensive programming patterns

• Rust के type system और compiler का सक्रिय उपयोग करके bugs को पहले से रोकने वाली coding आदतों का परिचय
• vector indexing, Default का अति-उपयोग, अपूर्ण match, और अनावश्यक boolean parameters जैसे कमज़ोर code smell के उदाहरण और उनके विकल्पों की व्याख्या
• मुख्य सिद्धांत है ऐसी संरचना डिज़ाइन करना जिसमें compiler invariants को enforce करे, और इसके लिए pattern matching, private fields, #[must_use] attribute आदि का उपयोग
• TryFrom का उपयोग, struct का complete destructuring, temporary mutability, constructor validation जैसे वास्तविक code-level defensive techniques को ठोस रूप में प्रस्तुत किया गया है
• ऐसे patterns refactoring के दौरान stability सुनिश्चित करने और long-term maintainability बढ़ाने के लिए आवश्यक हैं

---

defensive programming का अवलोकन

• // this should never happen comment वाले स्थान उन बिंदुओं को दिखाते हैं जहाँ implicit invariant टूटता है
  • अधिकांश मामलों में developer सभी boundary conditions या भविष्य के code changes को ध्यान में नहीं रखता
• Rust compiler memory safety की गारंटी देता है, लेकिन business logic errors फिर भी हो सकते हैं
• कई वर्षों के व्यावहारिक अनुभव से मिले छोटे habitual patterns (idiom) code quality को बहुत बेहतर बनाते हैं

Code Smell: vector indexing

• if !vec.is_empty() { let x = &vec[0]; } जैसी संरचना में length check और indexing अलग होने से runtime panic का जोखिम रहता है
• slice pattern matching (match vec.as_slice()) का उपयोग करने पर compiler हर state की जाँच अनिवार्य कर देता है
  • empty vector, single element, duplicate element जैसे सभी मामलों को स्पष्ट रूप से handle किया जा सकता है
• यह ऐसा डिज़ाइन करने का प्रतिनिधि उदाहरण है जहाँ compiler invariants की गारंटी दे

Code Smell: Default का अंधाधुंध उपयोग

• ..Default::default() नया field जुड़ने पर उसके छूट जाने के जोखिम और implicit value setting की समस्या पैदा कर सकता है
• सभी fields को स्पष्ट रूप से initialize करने पर compiler नए fields को सेट करने के लिए मजबूर करता है
• let Foo { field1, field2, .. } = Foo::default(); जैसे रूप में default struct को destructure करके चुनिंदा override किया जा सकता है
  • इससे default values और explicit override के बीच संतुलन बना रहता है

Code Smell: नाज़ुक Trait implementation

• struct fields को पूरी तरह destructure करके compare करने पर नया field जुड़ने पर compiler error के ज़रिए चेतावनी मिलती है
  • उदाहरण: PartialEq implementation में let Self { size, toppings, .. } = self;
• extra_cheese जैसे नए field जुड़ने पर comparison logic की फिर से समीक्षा करना अनिवार्य हो जाता है
• यही सिद्धांत Hash, Debug, Clone जैसे अन्य traits पर भी लागू किया जा सकता है

Code Smell: From की जगह TryFrom की आवश्यकता

• जब conversion हमेशा सफल नहीं होता, तब From की जगह TryFrom से failure की संभावना को स्पष्ट करना चाहिए
• unwrap_or_else का उपयोग संभावित failure को छिपाने का संकेत हो सकता है, और fail fast तरीका अधिक सुरक्षित है

Code Smell: अपूर्ण match

• _ => {} जैसा catch-all pattern नया variant जुड़ने पर case छूट जाने का जोखिम बढ़ाता है
• सभी variants को स्पष्ट रूप से सूचीबद्ध करने पर compiler नए case को handle न करने की चेतावनी देता है
• वही logic Variant3 | Variant4 जैसे रूप में group भी किया जा सकता है

Code Smell: _ placeholder का अति-उपयोग

• केवल _ इस्तेमाल करने पर कौन-सा variable छोड़ा गया है यह स्पष्ट नहीं रहता
• has_fuel: _, has_crew: _ जैसे स्पष्ट नाम readability बेहतर बनाते हैं

Pattern: temporary mutability

• जब data सिर्फ initialization के दौरान mutable होना चाहिए, तब let mut data = ...; data.sort(); let data = data; जैसी संरचना उपयोगी है
• block scope का उपयोग करने पर temporary variables बाहर expose होने से बचते हैं
  • उदाहरण: let data = { let mut d = get_vec(); d.sort(); d };
• कई temporary variables वाले initialization process में scope को स्पष्ट रूप से अलग किया जा सकता है

Pattern: constructor validation को अनिवार्य बनाना

• struct बनाते समय validation logic से अनिवार्य रूप से गुज़रना सुनिश्चित किया जाता है
  • _private: () field जोड़ने पर बाहर से direct construction संभव नहीं रहता
  • #[non_exhaustive] attribute crate के बाहर construction रोकने और future extension का संकेत देने के लिए उपयोगी है
• अगर internal modules में भी इसे enforce करना हो, तो private type (Seal) वाली nested module structure का उपयोग किया जा सकता है
  • Seal केवल अंदर मौजूद होता है, इसलिए new() के अलावा direct construction संभव नहीं
• fields को private रखकर getter देने से immutable state बनाए रखी जा सकती है
• लागू करने के मानदंड
  • बाहरी code को रोकना: _private या #[non_exhaustive]
  • आंतरिक code को रोकना: private module + Seal
  • validation logic को compiler-level guarantee में बदलना

Pattern: #[must_use] attribute का उपयोग

• #[must_use] महत्वपूर्ण return values को नज़रअंदाज़ होने से रोकता है
  • उदाहरण: #[must_use = "Configuration must be applied to take effect"]
• यदि user return value को ignore करता है, तो compiler warning देता है
• यह Result जैसी standard library types में भी व्यापक रूप से इस्तेमाल होने वाला सरल लेकिन शक्तिशाली defensive उपाय है

Code Smell: boolean parameters

• fn process_data(..., compress: bool, encrypt: bool, validate: bool) जैसी संरचना अर्थ को अस्पष्ट बनाती है और order mistakes का जोखिम बढ़ाती है
• enum Compression, enum Encryption आदि से intent को स्पष्ट रूप से व्यक्त किया जा सकता है
• कई options होने पर parameter struct (Params struct) का उपयोग उपयुक्त है
  • ProcessDataParams::production() जैसी preset methods reusability बढ़ाती हैं
• नया option जुड़ने पर मौजूदा call sites पर असर कम होता है

Clippy lints के साथ automation

• प्रमुख defensive patterns की Clippy lints से automatic जाँच की जा सकती है
  • indexing_slicing: direct indexing निषिद्ध
  • fallible_impl_from: From की जगह TryFrom की सिफारिश
  • wildcard_enum_match_arm: _ pattern निषिद्ध
  • fn_params_excessive_bools: बहुत अधिक boolean parameters पर warning
  • must_use_candidate: #[must_use] candidates का सुझाव
• #![deny(clippy::...)] या Cargo.toml settings से इन्हें project-wide लागू किया जा सकता है

निष्कर्ष

• Rust में defensive programming का सार है type system और compiler का सक्रिय उपयोग करके invariants को explicit और verifiable बनाना
• ये patterns refactoring के समय stability, bug की संभावना में कमी, और long-term maintainability में योगदान देते हैं
• यह “जो bug compile ही न हो, वही सबसे अच्छा bug है” वाले सिद्धांत को व्यवहार में उतारने का तरीका है