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

परिचय: आपकी TypeScript कोड समीक्षा कंट्रोल पैनल पर लाल बत्ती की तरह क्यों दिखती है?

क्या आपने कभी pull request भेजा है और एक घंटे बाद एक सीनियर डेवलपर से 20 टिप्पणियाँ प्राप्त की हैं, जिनमें से आधी "इसे बेहतर किया जा सकता है" शब्दों से शुरू होती हैं? परिचित लगता है। यदि आप TypeScript में लिखते हैं, लेकिन आपका कोड अभी भी सहकर्मियों में इसे शुरू से फिर से लिखने की इच्छा जगाता है - यह लेख आपके लिए है।

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

1. "Any" - आपका दुश्मन, दोस्त नहीं

किसी भी TypeScript कोड समीक्षा पर सबसे आम शिकायत any का उपयोग है। ऐसा लगता है कि टाइपों से निपटने की तुलना में const data: any = await fetch(...) लिखना आसान है। लेकिन सीनियर इसे लाल झंडे की तरह देखते हैं।

खराब:

function processUser(user: any) {\n  console.log(user.name.toUpperCase());\n}\n

अच्छा:

interface User {\n  id: number;\n  name: string;\n  email: string;\n}\n\nfunction processUser(user: User): void {\n  console.log(user.name.toUpperCase());\n}\n

यह क्यों महत्वपूर्ण है? यदि आप any का उपयोग करते हैं तो TypeScript अपना पूरा अर्थ खो देता है। आप सचमुच टाइप सिस्टम को बंद कर रहे हैं। यदि डेटा API से आता है - एक इंटरफ़ेस बनाएँ। यदि टाइप जटिल है - जाँच के साथ unknown का उपयोग करें। यह TypeScript best practices के मुख्य नियमों में से एक है।

2. strict mode को अनदेखा करना

कई प्रोजेक्ट tsconfig.json में सख्त मोड को बंद कर देते हैं क्योंकि "यह तेज़ है" या "टाइप परेशान करते हैं"। TypeScript पर एक सीनियर डेवलपर तुरंत देखेगा कि आपका कोड null और undefined की जाँच नहीं करता है।

खराब (strict: false):

function getLength(str: string) {\n  return str.length; // str null हो सकता है, और यह क्रैश हो जाएगा\n}\n

अच्छा (strict: true):

function getLength(str: string | null): number {\n  if (str === null) return 0;\n  return str.length;\n}\n

सुझाव: tsconfig.json में strict: true चालू करें। यह आपको अधिक सुरक्षित कोड लिखने के लिए मजबूर करेगा। TypeScript कोड समीक्षा पर यह एक प्लस होगा, माइनस नहीं।

3. टाइप्स के साथ जादू: अत्यधिक जटिलता

कभी-कभी डेवलपर्स यह दिखाने की कोशिश करते हैं कि वे कितने अच्छे हैं, और ऐसे टाइप लिखते हैं कि सीनियर भी अपना सिर खुजलाते हैं। उदाहरण के लिए, नेस्टेड जेनेरिक के साथ सशर्त टाइप जहाँ एक साधारण इंटरफ़ेस से काम चल सकता था।

खराब (over-engineering):

type DeepReadonly<T> = {\n  readonly [P in keyof T]: T[P] extends object ? DeepReadonly<T[P]> : T[P];\n};\n

अच्छा (सरलता):

interface Config {\n  readonly apiUrl: string;\n  readonly timeout: number;\n}\n

सीनियर कोड की पठनीयता को महत्व देते हैं। यदि आपके टाइप को तीन फ़ील्ड वाले इंटरफ़ेस से बदला जा सकता है - ऐसा करें। बिना आवश्यकता के जटिल न बनाएँ।

4. त्रुटियों का गलत प्रबंधन

code review TypeScript पर एक सामान्य गलती any या खाली catch ब्लॉक के साथ try-catch है। सीनियर तुरंत इस ओर इशारा करेंगे।

खराब:

try {\n  const data = await fetchData();\n} catch (e) {\n  console.log('त्रुटि');\n}\n

अच्छा:

try {\n  const data = await fetchData();\n} catch (error: unknown) {\n  if (error instanceof Error) {\n    console.error(error.message);\n  } else {\n    console.error('अज्ञात त्रुटि', error);\n  }\n}\n

त्रुटियों के लिए unknown का उपयोग करें। यह