الأسماء الطويلة طويلة جدًا

مرحبا يا هبر! أقدم لكم ترجمة مقال "الأسماء الطويلة طويلة" للمخرج بوب نيستروم.

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

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

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

ولكن ، على أي حال ، هذا ليس هو الحال. لعنه ، ليس حتى السهام. ما أريد أن أتحدث عنه هو ما أراه في العديد من الرموز ، وما يدفعني إلى الجنون: الأسماء الطويلة جدًا .

نعم ، قد تكون الأسماء قصيرة جدًا. في تلك الأيام التي طالبت فيها C بأن تكون المعرفات الخارجية فقط فريدة حتى الأحرف الستة الأولى ؛ عندما لم يتم اختراع الإكمال التلقائي ؛ عندما كانت كل ضربة مفتاح مثل تسلق الجبال الشاهقة - كانت هذه مشكلة. أنا سعيد لأننا نعيش الآن في مدينة فاضلة مستقبلية ، حيث نادرة farts لوحة المفاتيح مثل p و idxcrpm و x3 .

لكن البندول تأرجح بعيدًا في الاتجاه الآخر. ليس من الضروري أن نكون Hemingway ، كما أننا لسنا بحاجة إلى أن نكون Tennessee Williams. الأسماء الطويلة جدًا تلحق الضرر بوضوح الشفرة المستخدمة. أسماء متغيرة طويلة جداً تلقي بظلالها على العمليات التي تقوم بها. رمز يصبح من الصعب مسح بصريا. لتلبية متطلبات عرض الشفرة ، تظهر فواصل أسطر إضافية تقاطع التدفق المنطقي للرمز. تخفي أسماء الطرق الطويلة قوائم الوسيطة الخاصة بها بنفس القدر من الأهمية. المتغيرات الطويلة مزعجة من إعادة الاستخدام ، مما يؤدي إلى امتداد سلاسل الطرق أو الشلالات.

رأيت أسماء المتغيرات أطول من 60 حرفا. يمكنك وضع haiku أو koan هناك (وربما تنوير القارئ أكثر من الاسم الذي تختاره). لكن لا تخف ، أنا هنا للمساعدة.

اختيار اسم جيد

أي اسم في البرمجة له ​​هدفين:

• يجب أن يكون الاسم واضحًا : يجب أن تعرف ما يشير إليه.
• يجب أن يكون الاسم دقيقًا : يجب أن تعرف ما لا ينطبق عليه.

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

1. تجنب الكلمات المحددة صراحة في متغير أو نوع المعلمة

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

بالنظر إلى هذا ، ليس من الضروري الإشارة إلى النوع في اسم المتغير. لقد تخلينا عن التدوين المجري . دعنا ننسى وننسى :

 // : String nameString; DockableModelessWindow dockableModelessWindow; // : String name; DockableModelessWindow window; 

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

 // : List<DateTime> holidayDateList; Map<Employee, Role> employeeRoleHashMap; // : List<DateTime> holidays; Map<Employee, Role> employeeRoles; 

وهذا ينطبق أيضا على أسماء الطريقة. لا يحتاج اسم الطريقة إلى وصف المعلمات أو أنواعها - قائمة المعلمات ستفعل ذلك من أجلك.

 // : mergeTableCells(List<TableCell> cells) sortEventsUsingComparator(List<Event> events, Comparator<Event> comparator) // : merge(List<TableCell> cells) sort(List<Event> events, Comparator<Event> comparator) 

ينتج عن هذا قراءة المكالمات بشكل أفضل من هذا:

 mergeTableCells(tableCells); sortEventsUsingComparator(events, comparator); 

هل أنا فقط ، أم أن هناك صدى صدى هنا؟

2. تجنب الكلمات التي لا تلتبس من الاسم

يميل بعض الأشخاص إلى دفع كل ما يعرفونه عن شيء ما إلى اسم المتغير. تذكر أن الاسم معرف : فهو يشير إلى المكان الذي تم تعريفه فيه. هذا ليس كتالوجًا شاملاً لكل ما قد يرغب القارئ في معرفته حول الكائن. التعريف سيجعله أفضل. الاسم سيوجهه فقط هناك.

عندما أرى الاسم recentlyUpdatedAnnualSalesBid ، تم تحديثه سنويًا ، فأنا أسأل نفسي:

• هل هناك أي أوامر مبيعات سنوية محدثة ليست هي الأحدث؟
• هل هناك أي طلبات مبيعات سنوية حديثة لم يتم تحديثها؟
• هل هناك أي تطبيقات غير مبيعات سنوية تم تحديثها مؤخرًا؟
• هل هناك بيانات مبيعات سنوية محدّثة مؤخرًا ليست عطاءات؟

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

 // : finalBattleMostDangerousBossMonster; weaklingFirstEncounterMonster; // : boss; firstMonster; 

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

3. تجنب الكلمات الواضحة من السياق.

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

 // : class AnnualHolidaySale { int _annualSaleRebate; void promoteHolidaySale() { ... } } // : class AnnualHolidaySale { int _rebate; void promote() { ... } } 

في الممارسة العملية ، هذا يعني أنه كلما تم تضمين الاسم بشكل أعمق ، كلما زاد السياق المحيط به. نتيجة لذلك ، اتضح أن هذا الاسم سيكون أقصر. نتيجة لذلك ، يمكنك رؤية نموذج: المعرفات الموجودة في منطقة أضيق لها أسماء أقصر.

4. تجنب الكلمات التي لا تعني شيئا.

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

في معظم الحالات ، لا تحمل هذه الكلمات أي معلومات مفيدة للمطور. عادةً ما تقع الشكوك حول كلمات مثل: data state amount value manager engine object entity instance .

اسم جيد يرسم صورة في ذهن القارئ. وصف أي شيء بأنه "مدير" ، لا نعطي القارئ أي معلومات حول ما يجب أن يفعله هذا الكائن. هل تقوم بحساب تقييم الأداء؟ يعين الترقية لموظفيها؟

اسأل نفسك: "هل هذا الاسم يعني نفس الشيء إذا أخذت هذه الكلمة بعيدًا؟" إذا كانت الإجابة بنعم ، فالكلمة لا تهم - طرد من الجزيرة.

تطبيق الدليل على ... بسكويتات الوفل

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

 class DeliciousBelgianWaffleObject { void garnishDeliciousBelgianWaffleWithStrawberryList( List<Strawberry> strawberryList) { ... } } 

بفضل نوع المعلمة ، نعلم أن الطريقة تقبل قائمة الفراولة (# 1). لنقطع هذه المعلومات من اسم:

 class DeliciousBelgianWaffleObject { void garnishDeliciousBelgianWaffle( List<Strawberry> strawberries) { ... } } 

إذا لم تكن هناك الفطائر البلجيكية المذاق أو الفطائر من أي جنسيات أخرى في البرنامج ، فيمكننا تجاهل جميع الصفات بأمان (# 2):

 class WaffleObject { void garnishWaffle(List<Strawberry> strawberries) { ... } } 

هذه الطريقة موجودة داخل WaffleObject ، لذلك من السياق نعلم بالضبط ما WaffleObject (# 3):

 class WaffleObject { void garnish(List<Strawberry> strawberries) { ... } } 

من الواضح أن هذا كائن. كل شيء كائن في البرمجة الموجهة للكائنات (# 4):

 class Waffle { void garnish(List<Strawberry> strawberries) { ... } } 

الآن أفضل بكثير.

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