استخدام الشرطة السفلية في متغيرات Java وأسماء الطرق [مغلق]

Question

حتى في الوقت الحاضر غالبًا ما أرى الشرطة السفلية في متغيرات وأساليب Java، ومن الأمثلة على ذلك متغيرات الأعضاء (مثل "m_count" أو "_count").بقدر ما أتذكر، فإن استخدام الشرطة السفلية في هذه الحالات يسمى أسلوبًا سيئًا من قبل صن.

المكان الوحيد الذي يجب استخدامها فيه هو الثوابت (كما في "public Final static int IS_OKAY = 1;")، لأن الثوابت يجب أن تكون بأحرف كبيرة وليست بأحرف الجمل.هنا، يجب أن تجعل الشرطة السفلية الكود أكثر قابلية للقراءة.

هل تعتقد أن استخدام الشرطة السفلية في Java هو أسلوب سيء؟إذا كان الأمر كذلك (أو لا)، لماذا؟

Answer 1

إذا لم يكن لديك رمز يستخدمه الآن، أقترح الاستمرار في ذلك.إذا كانت قاعدة التعليمات البرمجية الخاصة بك تستخدمها، فتابع ذلك.

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

Answer 2

sunDoesNotRecommendUnderscoresBecauseJavaVariableAndFunctionNamesTendToBeLongEnoughAsItIs();

as_others_have_said_consistency_is_the_important_thing_here_so_chose_whatever_you_think_is_more_readable();

Answer 3

قواعد:

1. افعل ما يفعله الكود الذي تقوم بتحريره
2. إذا لم يتم تطبيق رقم 1، استخدم CamelCase، بدون شرطات سفلية

Answer 4

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

يمكنك أيضًا تحقيق ذلك عن طريق إجبار المستخدمين على إضافة متغيرات المثيل مسبقًا بـ "هذا" ولكني أجد هذا شديد القسوة إلى حد ما.في كثير من النواحي، ينتهك DRY لأنه متغير مثيل، فلماذا يتم تأهيله مرتين.

أسلوبي الشخصي هو استخدام m_ بدلاً من _.والسبب هو أن هناك أيضًا متغيرات عالمية وثابتة.ميزة m_/_ هي أنه يميز نطاق المتغيرات.لذلك لا يمكنك إعادة استخدام _ لـ عام أو ثابت وبدلاً من ذلك اخترت g_ و s_ على التوالي.

Answer 5

"الأسلوب السيئ" هو أمر شخصي للغاية.إذا كانت هناك اتفاقيات معينة تناسبك أنت وفريقك، فأعتقد أن ذلك سيؤهل أسلوبًا سيئًا/جيدًا.

للإجابة على سؤالك:أستخدم الشرطة السفلية لتمييز المتغيرات الخاصة.أجد الأمر واضحًا ويمكنني مسح الرمز بسرعة ومعرفة ما يحدث.

(على الرغم من ذلك، لا أستخدم كلمة "هذا" أبدًا تقريبًا، باستثناء منع تضارب الأسماء.)

Answer 6

يؤدي استخدام 'm_' أو '_' في مقدمة المتغير إلى تسهيل اكتشاف متغيرات الأعضاء في الأساليب عبر الكائن.

كفائدة جانبية، كتابة 'm_' أو '_' سيجعل التحسس الذكي يظهر أولاً ;)

Answer 7

• يصادف أنني أحب الشرطة السفلية لمتغيرات المثيلات (الخاصة)، ويبدو أنه من الأسهل قراءتها وتمييزها. بالطبع يمكن أن يوقعك هذا الشيء في مشكلة مع حالات الحافة (على سبيل المثال.متغيرات الحالة العامة (ليست شائعة، أعلم) - في كلتا الحالتين، يمكنك تسمية هذه المتغيرات، حيث يمكن القول إنها تخالف اصطلاح التسمية الخاص بك:
• private int _my_int; public int myInt;? _my_int? )

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

- توليد الكود الآلي (على سبيل المثال.من غير المرجح أن يفهم (مولدات Eclipse's getters، setters) هذا الأمر، لذا سيتعين عليك إصلاحه يدويًا أو باستخدام Eclipse بدرجة كافية حتى يتعرف عليه.

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

Answer 8

هناك سبب يجعل استخدام الشرطة السفلية يعتبر أسلوبًا سيئًا في الأيام الخوالي.عندما كان مترجم وقت التشغيل أمرًا لا يمكن تحمله وكانت الشاشات تأتي بدقة مذهلة تبلغ 320 × 240 بكسل، لم يكن من السهل في كثير من الأحيان التمييز بين _name و __name.

Answer 9

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

Answer 10

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

بالنسبة لي، "_" من الصعب جدًا كتابتها :)

Answer 11

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

setBar( int bar)
{
   _bar = bar;
}

بدلاً من

setBar( int bar)
{
   this.bar = bar;
}

سيستخدم الآخرون الشرطة السفلية للإشارة إلى متغير محلي مؤقت سيخرج عن النطاق في نهاية استدعاء الأسلوب.(أجد هذا عديم الفائدة تمامًا - الطريقة الجيدة لا ينبغي أن تستغرق وقتًا طويلاً، والإعلان موجود هنا!لذلك أعلم أنه خارج النطاق) تحرير:لا سمح الله أن يتعاون مبرمج من هذه المدرسة ومبرمج من مدرسة memberData!سيكون الجحيم.

في بعض الأحيان، ستبدأ التعليمات البرمجية التي تم إنشاؤها المتغيرات بـ _ أو __.الفكرة هي أنه لا يمكن لأي إنسان أن يفعل هذا أبدًا، لذا فهو آمن.

Answer 12

أعتقد أن أي أسلوب يخالف إرشادات أسلوب اللغة الخاصة (بدون سبب وجيه) هو أسلوب قبيح وبالتالي "سيئ".

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

لا يستطيع بعض الأشخاص التكيف مع أنماط البرمجة الجديدة...

Answer 13

السبب الذي يجعل الناس يفعلون ذلك (في تجربتي) هو التمييز بين متغيرات الأعضاء ومعلمات الوظيفة.في Java يمكنك الحصول على فئة مثل هذا:

public class TestClass {
  int var1;

  public void func1(int var1) {
     System.out.println("Which one is it?: " + var1);
  }
}

إذا قمت بإنشاء متغير العضو _var1 أو m_var1، فلن يكون لديك الغموض في الوظيفة.

إذن كذلك أ أسلوب، ولن أسميه سيئا.

Answer 14

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

على الأقل، تعتبر IDEs مثل Eclispe ملحدة، مما يسمح بوضع قواعد مثل البادئات أو اللواحق المتغيرة، وأنماط مختلفة لوضع الأقواس وإدارة المساحة، وما إلى ذلك.لذلك يمكنك استخدامه لإعادة تنسيق التعليمات البرمجية على طول لك القواعد الارشادية.

ملحوظة:أنا من بين أولئك الذين احتفظوا بعاداتهم القديمة من C/C++، وترميز Java باستخدام بادئات m_ لمتغيرات الأعضاء (و s_ للمتغيرات الثابتة)، وبادئة القيم المنطقية بحرف b الأولي، واستخدام حرف كبير أولي لأسماء الوظائف ومحاذاة الأقواس ...الرعب للأصوليين جافا!؛-)
ومن المضحك أن هذه هي الاصطلاحات المستخدمة حيث أعمل ...ربما لأن المطور الأولي الرئيسي يأتي من عالم MFC!:-د

Answer 15

إنه مجرد أسلوبك الخاص، ولا يوجد رمز أسلوب سيئ، ولا شيء رمز أسلوب جيد، فقط قم باختلاف الكود الخاص بنا مع الآخرين.