TypeScript पर कोड रिव्यू: 7 चीज़ें जिन्हें मैं जाँचता हूँ

परिचय: क्यों "बस कंपाइल हो जाता है" एक खराब मापदंड है

एक स्थिति की कल्पना करें: आप GitHub पर एक Pull Request खोलते हैं, CI की हरी टिक देखते हैं और एक आंतरिक आवाज सुनते हैं: "टाइप्स मैच कर रहे हैं — मतलब कोड सही है।" परिचित लगता है? यदि हाँ, तो आप एक जाल में फंस गए हैं जिसे हम "TypeScript की झूठी सुरक्षा भावना" कहते हैं।

TypeScript कोई रामबाण इलाज नहीं है। यह तार्किक त्रुटियों को नहीं पकड़ता, व्यावसायिक आवश्यकताओं की जाँच नहीं करता, और निश्चित रूप से यह गारंटी नहीं देता कि आपका कोड रनटाइम में नहीं टूटेगा। यही कारण है कि TypeScript पर कोड रिव्यू — यह "आँखें दौड़ाने" के बारे में नहीं है, बल्कि एक व्यवस्थित दृष्टिकोण के बारे में है। इस लेख में, मैं बताऊंगा कि जब आप TypeScript कोड की समीक्षा कर रहे हों तो वास्तव में क्या देखना चाहिए। मैं PythonLib पर ब्लॉग लिखता हूँ, और यहाँ हम गहराई में जाने के आदी हैं — तैयार रहें।

1. any टाइप: लाल झंडा

सबसे स्पष्ट, लेकिन किसी कारण से सबसे आम। any TypeScript का स्विच ऑफ बटन है। यदि आप कोड में any देखते हैं, तो आपका काम यह समझना है: क्या यह लेखक की आलस्य है या वास्तव में उचित मामला है?

खराब उदाहरण:

function processData(data: any) {\n    return data.name.toLowerCase();\n}

यहाँ हम टाइप के बारे में सारी जानकारी खो देते हैं। यदि data null या undefined आता है — तो रनटाइम में त्रुटि, नमस्ते।

अच्छा उदाहरण:

interface UserData {\n    name: string;\n    age?: number;\n}\n\nfunction processData(data: UserData) {\n    return data.name.toLowerCase();\n}

कोड रिव्यू पर क्या जाँचें: यदि any फिर भी उपयोग किया जाता है (उदाहरण के लिए, अज्ञात संरचना वाले JSON के साथ काम करने के लिए), तो क्या लेखक इनपुट पर वैलिडेशन की मांग करता है? अक्सर any बाहरी डेटा के लिए सामान्य टाइपिंग की कमी को छुपाता है।

2. Strict mode: इसे बंद न करें

पहली चीज़ जो मैं tsconfig.json में जाँचता हूँ — वह है फ्लैग strict: true। यदि यह नहीं है, तो आप अपने आप को जाँचों की एक पूरी परत से वंचित कर रहे हैं: strictNullChecks, noImplicitAny, strictFunctionTypes और अन्य।

strictNullChecks के बिना आप लिख सकते हैं:

const user = getUser(); // null लौटा सकता है\nconst name = user.name; // TS शिकायत नहीं करेगा, लेकिन रनटाइम में क्रैश हो जाएगा

कोड रिव्यू पर: यदि आप देखते हैं कि प्रोजेक्ट strict mode के बिना काम कर रहा है — तो अलार्म बजाएँ। यह तकनीकी ऋण है जो तेजी से बढ़ता है। strict mode को चालू करने और त्रुटियों को ठीक करने में एक दिन बिताना बेहतर है, बजाय प्रोडक्शन में बग पकड़ने में एक महीना बिताने के।

3. जेनेरिक्स: शक्ति और जिम्मेदारी

जेनेरिक्स TypeScript की सुपरपावर हैं। लेकिन बड़ी शक्ति के साथ बड़ी जिम्मेदारी आती है। कोड रिव्यू पर मैं हमेशा देखता हूँ: क्या लेखक ने टाइप्स को अत्यधिक जटिल नहीं बना दिया?

अत्यधिक जटिलता का उदाहरण:

function identity<T extends Record<string, unknown>>(arg: T): T {\n    return arg;\n}

T को Record<string, unknown> तक सीमित क्यों करें, जब हम बस वही लौटा रहे हैं? पर्याप्त है:

function identity<T>(arg: T): T {\n    return arg;\n}

क्या जाँचें:

\n
• क्या जेनेरिक्स का उपयोग वहाँ किया गया है जहाँ लचीलेपन की आवश्यकता है, या क्या एक विशिष्ट टाइप से काम चल सकता था?
\n
• क्या कोई अनावश्यक प्रतिबंध (extends) हैं जो पुन: उपयोग में बाधा डालते हैं?
\n
• क्या टाइप्स सही ढंग से अनुमानित किए गए हैं — क्या उपयोगकर्ता को मैन्युअल रूप से <SomeType> निर्दिष्ट करना पड़ रहा है जहाँ TS स्वयं अनुमान लगा सकता था?
\n

4. unknown बनाम any: सही हथियार चुनें

जब आप उस डेटा के साथ काम कर रहे हों जिसका टाइप आपको ज्ञात नहीं है (API, localStorage, उपयोगकर्ता इनपुट), तो unknown का उपयोग करें, any का नहीं। unknown आपको उपयोग से पहले स्पष्ट रूप से टाइप की जाँच करने के लिए मजबूर करता है।

खराब: