هل تستخدم اصطلاحات معينة لتسمية المتغيرات التكميلية؟

Question

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

قد يتم تفسير ذلك بشكل أفضل من خلال مثال مضاد - أحتفظ بتطبيق يطبع رسمين كجزء من إعلان مطبوع.يتم تخزينها في قاعدة البيانات باسم TopLogo و LowerLogo, ، والتي يجب علي إيقافها والتحقق منها مرة أخرى في كل مرة أستخدمها فيها لأنني أتوقع ذلك top لتكمل bottom, ، و lower ينبغي أن تكمل upper.

هناك بعض الأمثلة الواضحة التي أعتقد أنها تعمل بشكل جيد:

client / server
source / target لنسخ/نقل البيانات أو الملفات من متغير إلى آخر
minimum / maximum

ولكن هناك بعض المفاهيم التي لا تصلح لمخططات التسمية الأنيقة هذه.على سبيل المثال، عند تصفح السجلات، هل كلمة "الأخير" تعني "نهائي" أم "سابق"؟لقد رأيت مؤخرًا بعض التعليمات البرمجية المستخدمة firstPage, previousPage, nextPage و finalPage لتجنب الغموض lastPage تماما، والذي اعتقدت أنه كان فوزا كبيرا، ومن هنا هذا السؤال.

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

Answer 1

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

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

Answer 2

في قواعد البيانات الخاصة بي ستجد العديد من للدولة صالحة الزمني ( "التاريخ") الجداول التي تحتوي على زوج من الأعمدة اسمه start_date وend_date. لا نقاط مكافأة بالنسبة لي، بعد ذلك، لأنني تفضل استخدام استخداما 'نهاية' من محاولة الخروج ببديل بديهية مع نفس العدد من الحروف ككلمة "بداية".

وأنا أميل إلى تفضيل هذه المصطلحات العامة حتى عندما مزيد من المصطلحات المحددة السياق قد يكون قابلا للتطبيق على سبيل المثال تفضل employee_start_date على employee_hire_date (ماذا لو بدأ عملهم لسبب آخر غير كونها رسميا التعاقد على سبيل المثال كانت شركتهم موضوع الحيازة). وقال أن تفضل person_birth_date على person_start_date:)

Answer 3

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

تختفي المشكلة أيضًا إذا كان هناك JavaDoc جيد أو أيًا كان نظام التوثيق، وإذا كان لديك أسماء فئات جيدة تتوافق معها.على سبيل المثال، إذا كان لديك مثيل لـ a Connection فئة ولها طريقة تسمى طريقة setDestination, ، فلا بأس، ولكن إذا كنت تعلم أن setDestination يأخذ معلمة واحدة تسمى destination وهو من Server كلاس، أنت رائع..على الرغم من أنك قد تفضل تسميتها target, aimHere, placeToSendTheData, ، أو whatever (والأسماء المقابلة، source, comingFromHere, ، و placeToGetTheDataFrom).بالإضافة إلى أن نظام الوثيقة يقول ما هو الشيء ل, ، وهذا لا يقدر بثمن.

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

[أيضًا، بدلاً من كتابة أسماء المتغيرات الخاصة بك، قم بتعيين سلسلة ثابتة لهم في مكان ما في التعليمات البرمجية الخاصة بك واستخدمها، لذلك إذا أطلقوا عليها اسم أقل أو أقل بدلاً من منخفض، فلا تزال بخير.]

Answer 4

نعم، أنا لا محاولة لتسمية مجموعات متكاملة من المتغيرات بشكل منهجي بحيث تماثل واضح. الأمر ليس سهلا دائما؛ في بعض الأحيان، لم يكن ممكنا حتى. حسنا، لم يكن ممكنا باستخدام القواعد انبطحت لنفسي - وهو ما يعني أنني عادة في محاولة لديها أسماء نفس الطول. ان "كبار" و "أقل" المثال تدفع لي معتوه (على افتراض أنني لست معتوه بالفعل، وهو ليس من المؤكد)؛ كنت على الارجح استخدام 'العليا' وأقل لأن تلك هي نفس الطول؛ "كبار" و "القاع" من شأنه أن يحبط لي جدا بسبب الفرق في الطول.