C# कोड समीक्षा: 7 चीज़ें जो वरिष्ठ डेवलपर्स को परेशान करती हैं

परिचय: आपका कोड सीनियर को क्यों परेशान करता है?

आपने पुल-रिक्वेस्ट भेज दी। पाँच मिनट बीत गए। चैट में आता है: "चलो इस ब्लॉक को फिर से लिखते हैं?" और हर दूसरी लाइन के नीचे दर्जनों टिप्पणियाँ। परिचित लगता है? यदि आप C# में लिखते हैं और एक टीम में काम करते हैं, तो code review Jira में सिर्फ एक टिक नहीं है। यह सच्चाई का क्षण है।

मैंने विशिष्ट टिप्पणियाँ एकत्र की हैं जो वरिष्ठ डेवलपर्स C# कोड की समीक्षा पर छोड़ते हैं। यह सिंटैक्स के बारे में नहीं है - यह सोचने के तरीके के बारे में है। "बस काम करने वाले कोड" को ऐसे कोड में बदलने के बारे में है जिसे पहले शुक्रवार को फिर से न लिखना पड़े।

चलिए उन C# एंटीपैटर्न को समझना शुरू करते हैं जो सबसे शांत टीम लीड को भी परेशान करते हैं।

1. मैजिक नंबर और स्ट्रिंग्स: "इसका मतलब क्या है?"

C# कोड समीक्षा पर सबसे आम टिप्पणी संख्याओं के बारे में एक प्रश्न है। आप if (status == 3) लिखते हैं, और सीनियर तुरंत पूछता है: "यह 3 क्या है? क्या यह स्थिति "प्रोसेसिंग में" है या "हटा दिया गया"?"

खराब:

if (order.Status == 3 && days > 7)\n{\n    CancelOrder(order);\n}\n

अच्छा:

private const int OrderStatusCancelled = 3;\nprivate const int MaxDaysBeforeAutoCancel = 7;\n\nif (order.Status == OrderStatusCancelled && days > MaxDaysBeforeAutoCancel)\n{\n    CancelOrder(order);\n}\n

इससे भी बेहतर - इसे enum में डालें। वरिष्ठ डेवलपर्स पठनीय कोड पसंद करते हैं जहाँ व्यावसायिक तर्क को समझने के लिए डेटाबेस में जाने की आवश्यकता नहीं होती। यह C# code review का मूल नियम है: कोड को अपने आप में बोलना चाहिए।

2. Async void — एप्लिकेशन का साइलेंट किलर

यदि आप इवेंट हैंडलर (जैसे WPF या WinForms में) के अलावा कहीं और async void लिखते हैं, तो भारी कटौती के लिए तैयार रहें। Async void को ट्रैक नहीं किया जा सकता - अपवाद कहीं गिर जाएगा और प्रक्रिया को खत्म कर देगा।

खराब:

public async void LoadData()\n{\n    var data = await _repository.GetDataAsync();\n    // अगर यहाँ गिरता है — एप्लिकेशन बिना त्रुटि संदेश के गिर जाएगा\n}\n

अच्छा:

public async Task LoadDataAsync()\n{\n    var data = await _repository.GetDataAsync();\n}\n

C# कोड समीक्षा पर सीनियर निश्चित रूप से इस बिंदु पर इंगित करेगा। याद रखें: async Task आपका मित्र है, async void दुश्मन है (इवेंट को छोड़कर)।

3. गॉडज़िला क्लासेस: Single Responsibility Principle

आप एक फ़ाइल खोलते हैं, और उसमें 2000 लाइनें हैं। एक क्लास सब कुछ करता है: डेटाबेस में जाता है, ईमेल भेजता है, रिपोर्ट जनरेट करता है और कॉफी भी बनाता है। यह एक क्लासिक C# एंटीपैटर्न है — God Object।

C# code review पर सीनियर कहेगा: "चलो इसे कई क्लासेस में विभाजित करते हैं।" और वह सही होगा।

उल्लंघन का उदाहरण:

public class OrderService\n{\n    public void ProcessOrder(Order order)\n    {\n        // 1. सत्यापन\n        // 2. DB में सहेजना\n        // 3. ईमेल भेजना\n        // 4. लॉगिंग\n    }\n}\n

सही तरीका:

public class OrderProcessor\n{\n    private readonly IOrderValidator _validator;\n    private readonly IOrderRepository _repository;\n    private readonly INotificationService _notificationService;\n\n    public OrderProcessor(\n        IOrderValidator validator,\n        IOrderRepository repository,\n        INotificationService notificationService)\n    {\n        _validator = validator;\n        _repository = repository;\n        _notificationService = notificationService;\n    }\n\n    public async Task ProcessOrderAsync(Order order)\n    {\n        _validator.Validate(order);\n        await _repository.SaveAsync(order);\n        await _notificationService.SendConfirmationAsync(order);\n    }\n}\n

यह सिर्फ "सुंदर" नहीं है। यह परीक्षण योग्य है। आप रिपॉजिटरी को मॉक कर सकते हैं और केवल प्रोसेसिंग लॉजिक की जाँच कर सकते हैं। इस शैली में C# रिफैक्टरिंग किसी भी प्रोजेक्ट के लिए must have है।

4. अपवादों को नियंत्रण संरचना के रूप में उपयोग करना