C# في الفريق: أسلوب الكود والاتفاقيات التي ستنقذ مشروعك

لماذا أسلوب الكود ليس مجرد "رأي شخصي"

هل سبق لك أن فتحت كودًا لشخص آخر بلغة C# وشعرت وكأنك عالم آثار ينقب في أنقاض معبد قديم؟ public int a;، var x = GetSmth() بدون سياق، وطرق بطول 400 سطر. إذا كان الأمر كذلك - فأنت تعلم كيف يؤلم رأس الفريق بدون أسلوب كود موحد.

العمل في فريق لا يقتصر فقط على Git ومراجعة الكود. بل يتعلق بأن كودك يقرأه أشخاص آخرون. وإذا كنت تكتب لنفسك، فإن أسلوب الكود لـ C# هو بيروقراطية مملة. ولكن إذا كنت تكتب لفريق - فهو إنقاذ للأعصاب والوقت والإنتاج.

في هذه المقالة، سنناقش أي اتفاقيات C# تعمل حقًا في عام 2024، وكيفية تطبيقها دون ألم، ولماذا 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). هذا هو المعيار لـ C#.
\n
• سطر فارغ واحد بين الطرق. سطران بين الفئات.
\n

// سيء (الأقواس في نفس السطر - هذه Java، ليست C#)\npublic void Process() {\n    var result = Calculate();\n    return result;\n}\n\n// جيد (نمط Allman)\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() حيث تحتاج إلى pro
\n