टीम में C#: कोड स्टाइल और कन्वेंशन जो आपके प्रोजेक्ट को बचाएंगे

कोड स्टाइल सिर्फ "मेरी सोच" नहीं है

क्या आपने कभी C# में किसी और का कोड खोला है और खुद को एक पुरातत्वविद् की तरह महसूस किया है जो किसी प्राचीन मंदिर के खंडहरों की खुदाई कर रहा है? public int a;, बिना संदर्भ के var x = GetSmth() और 400 लाइनों लंबे मेथड। अगर हाँ — तो आप जानते हैं कि एक समान कोड स्टाइल के बिना टीम का सिर कैसे दुखता है।

टीम में काम करना सिर्फ Git और code review के बारे में नहीं है। यह इस बारे में है कि आपका कोड दूसरे लोग पढ़ते हैं। और अगर आप अपने लिए लिखते हैं, तो C# के लिए कोड स्टाइल एक उबाऊ नौकरशाही है। लेकिन अगर आप टीम के लिए लिखते हैं — यह नसों, समय और प्रोडक्शन को बचाने वाला है।

इस लेख में, हम देखेंगे कि 2024 में कौन से C# कन्वेंशन वास्तव में काम करते हैं, उन्हें बिना दर्द के कैसे लागू करें, और EditorConfig आपका सबसे अच्छा दोस्त क्यों है। चलिए शुरू करते हैं।

बुनियादी नियम: पहले किस बात पर सहमत हों

1. नामकरण (naming conventions)

C# में सख्त मानक हैं, लेकिन टीमें अक्सर उनका उल्लंघन करती हैं। यहाँ सुनहरा न्यूनतम है जिसे 90% .NET टीमें स्वीकार करती हैं:

\n
• PascalCase — क्लास, मेथड, प्रॉपर्टी, पब्लिक फील्ड के लिए: public class UserService, public string GetUserName()।
\n
• camelCase — लोकल वेरिएबल, मेथड पैरामीटर, प्राइवेट फील्ड के लिए (अक्सर _ उपसर्ग के साथ): private int _userId;, var userName = "Alex";।
\n
• हंगेरियन नोटेशन से बचें — strName, intCount — यह पुराना जमाना है। वेरिएबल का प्रकार संदर्भ से स्पष्ट होना चाहिए।
\n
• बिना आवश्यकता के संक्षिप्त न करें — GetUsrInf(), GetUserInformation() से बुरा है। अपवाद: सामान्य संक्षिप्ताक्षर (IO, UI, DTO)।
\n

// खराब\npublic class user_service\n{\n    public int id;\n    public string nm;\n    private string _data;\n    public string GetData() => _data;\n}\n\n// अच्छा\npublic class UserService\n{\n    public int Id { get; }\n    public string Name { get; }\n    private readonly string _userData;\n\n    public string GetUserData() => _userData;\n}

2. फ़ॉर्मेटिंग: स्पेस, ब्रैकेट, खाली लाइनें

catch (Exception e) में कोलन से पहले स्पेस रखने या न रखने के बारे में बहस अनंत है। इसलिए स्वचालित टूल का उपयोग करें। लेकिन बुनियादी समझौते अभी भी आवश्यक हैं:

\n
• इंडेंटेशन — 4 स्पेस (C# में टैब का उपयोग शायद ही कभी किया जाता है, लेकिन अगर टीम ने टैब चुना है — यह ठीक है)।
\n
• कर्ली ब्रैकेट — हमेशा नई लाइन पर (Allman style)। यह C# के लिए मानक है।
\n
• मेथड के बीच एक खाली लाइन। क्लास के बीच दो।
\n

// खराब (ब्रैकेट उसी लाइन पर — यह Java है, C# नहीं)\npublic void Process() {\n    var result = Calculate();\n    return result;\n}\n\n// अच्छा (Allman style)\npublic void Process()\n{\n    var result = Calculate();\n    return result;\n}

उन्नत कन्वेंशन: जहाँ अक्सर ठोकर लगती है

3. var का उपयोग

एक शाश्वत बहस। नियम सरल है: var का उपयोग करें जब प्रकार दाईं ओर से स्पष्ट हो। यदि नहीं — स्पष्ट रूप से लिखें।

// var ठीक है\nvar users = GetUsers(); // प्रकार स्पष्ट है\nvar dictionary = new Dictionary<string, int>(); // लंबी घोषणा\n\n// स्पष्ट रूप से बेहतर\nUser user = GetUserById(id); // स्पष्ट नहीं कि User लौटा रहा है\nDictionary<string, int> result = ParseData(); // भी स्पष्ट नहीं

अगर आपकी टीम को var पसंद नहीं है — बस सहमत हो जाएँ। मुख्य बात एकरूपता है।

4. LINQ के साथ काम करना

LINQ एक शक्तिशाली लेकिन कपटी उपकरण है। सामान्य गलती — 10 मेथड की चेन जो मंत्र की तरह पढ़ी जाती है। सहमत हों:

\n
• लंबे LINQ एक्सप्रेशन को कई लाइनों में तोड़ें।
\n
• जहाँ प्रॉजेक्शन की आवश्यकता हो, वहाँ .Select() का दुरुपयोग न करें