غلاف Pascal أو Camel Casing لرمز C#؟

Question

لقد كنت أتجادل مع زملائي في العمل حول غلاف باسكال (حالة الجمل العلوي) مقابل غلاف باسكال (حالة الجمل العلوي).أدنى CamelCasing.يتم استخدامها لخفض غلاف الجمل لكل شيء بدءًا من أسماء الجداول في قواعد بيانات SQL إلى تسمية الخصائص في كود C# ولكني أفضل غلاف Pascal بشكل أفضل، وغطاء الجمل السفلي للمتغيرات وغطاء Pascal للخصائص:

string firstName;
public string FirstName {
...
}

لكنهم معتادون على هذا:

string _firstname;
public string firstName {
...
}

أحاول مواكبة "المعيار" الخاص بهم بحيث يبدو الرمز كما هو ولكني لا أحبه.

لقد رأيت أن إطار عمل .NET على الأقل يستخدم هذه الاتفاقية وهذه هي الطريقة التي أحاول بها الاحتفاظ بالرمز الخاص بي، على سبيل المثال:

System.Console.WriteLine("string")

ماذا تستخدم/تفضل ولماذا؟أنا آسف إذا سأل شخص آخر هذا السؤال ولكني بحثت ولم أجد أي شيء.

تحديث:لقد قدمت مثالاً للطريقة وليس خاصية ولكنها نفس الشيء.كما ذكرت في الفقرة الأولى، يستخدم زملائي اصطلاح باسكال في كل شيء (المتغيرات، الأساليب، أسماء الجداول، وما إلى ذلك)

Answer 1

أستخدم ما يستخدمه إطار العمل، لأنه أفضل الممارسات الفعلية.ومع ذلك، طالما أن الرمز الموجود في شركتك هو باستمرار باستخدام أسلوبهم، فمن الأفضل أن تعتاد عليه.إذا كان لكل مطور معياره الخاص، فلا يوجد معيار على الإطلاق.

Answer 2

رابط للمسؤول موجهات التصميم قد تساعد.على وجه التحديد، اقرأ القسم الخاص بـ أنماط الكتابة بالأحرف الكبيرة.

في المخطط الكبير للأشياء، لا يهم Pascal vs Camel كثيرًا، ومن غير المرجح أن تقنع أي شخص بالعودة إلى قاعدة التعليمات البرمجية الموجودة فقط لتغيير حالة الأسماء.ما يهم حقًا هو أنك تريد أن تكون متسقًا ضمن قاعدة تعليمات برمجية معينة.

أنا سعيد طالما أنك لا تستخدم اللغة المجرية.

Answer 3

يجب عليك إلقاء نظرة على أداة مايكروسوفت الجديدة، StyleCop للتحقق من كود مصدر C#.راقب أيضًا FxCop لفحص تجميعات .Net المترجمة.تركز FxCop أكثر على تفاصيل ما يفعله الكود، وليس التخطيط، ولكنها تحتوي على بعض قواعد التسمية المتعلقة بالأسماء المرئية بشكل عام.

يحدد StyleCop معيارًا للترميز، والذي يتم الترويج له الآن بواسطة Microsoft كمعيار صناعي.يقوم بفحص كود مصدر C# مقابل المعيار.يلتزم StyleCop بأسلوب PascalCase الخاص بك.

يمكن أن يكون جذب الأشخاص إلى StyleCop (أو أي معيار آخر في هذا الشأن) أمرًا صعبًا، فهو يمثل عقبة كبيرة، وStyleCop شامل تمامًا.ولكن يجب أن يكون الكود وفقًا لمعايير موحدة - والمعيار الشخصي أفضل من لا شيء، ومعيار الشركة أفضل من المعيار الشخصي، ومعيار الصناعة هو الأفضل على الإطلاق.

من الأسهل كثيرًا إقناع الأشخاص عند بدء المشروع - حيث يتم تشكيل الفريق ولا يوجد كود موجود لتحويله.ويمكنك وضع الأدوات (FxCop، StyleCop) في مكانها الصحيح لكسر البناء إذا كان الكود لا يفي بالمعايير.

يجب عليك استخدام المعيار للغة وإطار العمل - يجب أن يستخدم كود SQL معايير SQL، ويجب أن يستخدم كود C# معايير C#.

Answer 4

بالنسبة للواجهات العامة ، يجب أن تلتزم بإرشادات تصميم MS .NET Framework:"اتفاقيات الكتابة بالأحرف الكبيرة".

بالنسبة للأعضاء غير المكشوفين، فكل ما يمكنك الاتفاق عليه أنت وزملائك.

Answer 5

أنا (وفريقي) أفضّل حجز الأحرف الأولى لأسماء الفئات.

لماذا؟أعتقد أن معايير جافا تنتشر.

Answer 6

من .NET Framework Developer Guideاتفاقيات الكتابة بالأحرف الكبيرة, ، حساسية القضية:

توجد إرشادات الرسملة فقط لتسهيل القراءة والتعرف على المعرفات.لا يمكن استخدام الغلاف كوسيلة لتجنب تصادم الأسماء بين عناصر المكتبة.

لا تفترض أن جميع لغات البرمجة حساسة للحالة.هم ليسوا.لا يمكن أن تختلف الأسماء حسب الحالة وحدها.

Answer 7

لقد وجدت معايير الترميز لـ .Net.

Answer 8

يجب استخدام غلاف باسكال للخصائص.بقدر ما تذهب الأسماء المتغيرة، يستخدم بعض الأشخاص _ والبعض الآخر يستخدم m_ والبعض الآخر يستخدم فقط غلاف الجمل القديم البسيط.أعتقد أنه طالما أنك متسق هنا، فلا ينبغي أن يهم.

Answer 9

أعتقد أنه يتعين عليك تحمل ما ينص عليه معيار الترميز لمكان عملك، مهما كنت لا تحبه شخصيًا.ربما يومًا ما في المستقبل ستتمكن من إملاء معايير الترميز الخاصة بك.

أنا شخصياً أحب أن تستخدم قواعد البيانات أسماء النموذج "fish_name" و"tank_id" وما إلى ذلك للجداول والحقول، في حين أن الكود المكافئ لنموذج قاعدة البيانات سيكون "fishName" و"tankID".أنا أيضًا لا أحب تسمية "_fooname" عندما يكون "fooName" متاحًا.لكن يجب أن أكرر أن هذا أمر شخصي، وأن الأشخاص المختلفين سيكون لديهم أفكار مختلفة حول ما هو جيد وما هو سيئ بسبب خبرتهم السابقة وتعليمهم.

Answer 10

في الواقع، ليس هناك اتفاقية "قياسية" في هذا الشأن.هناك إرشادات تم تحريرها من Microsoft في مكان ما، وكما هو الحال مع أي إرشادات أخرى لاصطلاحات التسمية، فمن المؤكد أن هناك إرشادات أخرى تدحضها، ولكن إليك ما فهمته على أنه "اتفاقية غلاف C# القياسية".

1. PerWordCaps في أسماء الأنواع (الفئات والتعدادات) والثوابت والخصائص.
2. CamelCase للمتغيرات المحلية الطويلة جدًا والمتغيرات المحمية/الخاصة
3. لا يوجد ALL_CAPS أبدًا (حسنًا، فقط في تعريف المترجم، ولكن ليس في التعليمات البرمجية الخاصة بك)
4. يبدو أن بعض فئات النظام تستخدم أسماء تحتها شرطة (_name) للمتغيرات الخاصة، ولكن أعتقد أن ذلك يأتي من خلفية الكاتب الأصلي حيث أن معظمها جاء مباشرة من C++.لاحظ أيضًا أن VB.NET ليس حساسًا لحالة الأحرف، لذا لن تتمكن من الوصول إلى المتغيرات المحمية إذا قمت بتوسيع الفصل الدراسي.

في الحقيقة، FxCop سوف يفرض عددًا قليلاً من هذه القواعد، ولكن (AFAIK) يتجاهل أي تهجئة تستخدمها للمتغيرات المحلية.

Answer 11

أنا أحب اصطلاحات الترميز المنصوص عليها في خنزير الأرض مواصفات المشروع

Answer 12

كان هذا المثال لـ .NET الذي نشرته عبارة عن وظيفة."المعيار" المعتمد للطرق/الوظائف هو علبة الجمل المغطاة (أو باسكال، إذا كنت تريد أن تسميها كذلك).

أنا متمسك بحالة الجمل حيث أستطيع.يتيح لك معرفة الفرق بين المتغير والطريقة بسهولة.

بالإضافة إلى ذلك، أنا من محبي وضع شرطة سفلية أمام متغيرات الفئة المحلية.على سبيل المثال: _localVar.

Answer 13

اليوم الذي أتوقف فيه عن البرمجة - هو اليوم الذي ستجعل فيه Microsoft CamelCase في لغة C# كمعيار قياسي.لأن منطقى المتنامي له أسباب عديدة لـ PascalCase، على عكس منطق الطفل، الذي يهتم فقط بالأسماء الأقصر أو الأسهل في الكتابة.

و راجع للشغل:يأتي CamelCasing بشكل أساسي من نمط مكتبة C++ STD، وهي اللغة القديمة الأصلية الموروثة من C.لذلك ورثت جافا من C++.لكن لغة #C هي لغة جديدة تمامًا، نظيفة وجميلة، مع قواعد جديدة.يجب على Oldfags البرمجة على Java أو C++، ويجب على الجيل الجديد البرمجة على C# - ويجب ألا يتفاعلوا أبدًا.

خذ بعين الاعتبار هذا المثال:1) حالة باسكال:list.Capacity.ToString();2) حالة الجمل:list.capacity.toString();

في (1) لدينا حالة الجمل على المدى الطويل!!!يعني listCapacityToString.وفي (2) لدينا هراء:listcapacitytoString.

هكذا قرأت.ولماذا يعتبر CamelCase غير منطقي في حد ذاته.يمكنني أن أقتل من أجل PascalCase، ولا ألمسه أبدًا، أيًا كان عمر الأطفال.

Microsoft - إلى الأبد أو حتى يستخدمون PascalCase.

Answer 14

ما تفضله هو ما يهم، ومن الواضح أن الالتزام بمعايير الفريق في المقام الأول.بشكل خاص، يمكنك كتابة التعليمات البرمجية بالطريقة التي تريدها، ولا يؤثر ذلك على المنتج النهائي سواء قمت بتسمية المتغير someVariable أو SomeVariable.