يوجد شيئان فقط في علوم الكمبيوتر: إبطال ذاكرة التخزين المؤقت
وتسمية الأشياء.
- فيل كارلتون
نحن ، المطورين ، نقضي وقتًا أطول في قراءة الكود بدلاً من كتابته. من المهم أن تكون الشفرة قابلة للقراءة وواضح فيما يتعلق بقصدها.
فيما يلي بعض النصائح بناءً على تجربتي في تسمية الأشياء.
معنى
يجب أن يعكس الاسم ، سواء أكان متغيرًا أو خاصية أو فئة أو واجهة ، الغرض من سبب تقديمه وكيفية استخدامه.
استخدام أسماء دقيقة
إذا كان لا يمكن للمرء الحصول على فكرة عن الاستخدام والغرض دون تعليقات إضافية ، فإن الاسم ليس جيدًا بما يكفي. إذا كان الاستخدام الفوري أو فكرة الغرض القائمة على التسمية خاطئة ، فهذا يعني أن التسمية غير مقبولة.
أسوأ تسمية ممكنة هي عندما يكمن اسم الطريقة في الشخص الذي يقرأها.
تجنب أسماء لا معنى لها
هذه أسماء مثل $i ، $j ، $k إلخ. على الرغم من أنها مناسبة للاستخدام في الدورات ، إلا أنها في حالات أخرى تهدر قابلية القراءة.
أحد المصادر الشائعة لمثل هذه الأسماء هو العلم الكلاسيكي حيث تستخدم معظم الصيغ متغيرات ذات حرف واحد بحيث تكون الكتابة أسرع. ونتيجة لذلك ، لا يمكنك فهم هذه الصيغ بدون فقرة تمهيدية تشرح التسمية. في كثير من الأحيان هذه الفقرة من الصعب العثور عليها.
نظرًا لأن تعليم علوم الكمبيوتر يتضمن عددًا كبيرًا من تخصصات العلوم الكلاسيكية ، فإن الطلاب يعتادون على هذه التسمية ويضعونها في البرمجة.
تسمية الفئات والواجهات والخصائص والأساليب
يجب أن يكون اسم الفئة اسمًا واحدًا أو عدة أسماء. لا ينبغي أن يكون هناك أفعال. حاول تجنب "البيانات" ، "مدير" ، "معلومات" ، "معالج" ، "معالج" ، "صانع" ، "استخدم" إلخ. لأن هذه عادة ما تكون مؤشرا على تسمية غامضة.
واجهات عادة ما تكون إما الأسماء أو الصفات. اختارت بعض الفرق ، بما في ذلك PHP-FIG ، واجهات postfix مع Interface . البعض يفعل ذلك مع I البادئة والبعض الآخر لا يستخدم البادئة أو postfix. أجد كل هذه مقبولة في حال كنت متسقة.
يجب تسمية الخصائص بالأسماء أو الصفات. بالنسبة للمنطقين ، استخدم عبارات إيجابية مسبوقة بـ "Is" أو "Can" أو "Has" عند الاقتضاء.
يجب أن تحتوي أسماء الطرق على فعل واحد أو أكثر لأنها أفعال. اختر الفعل الذي يصف الطريقة التي تعمل بها ، وليس الطريقة التي تعمل بها.
على الرغم من أنه ليس ضروريًا تمامًا ، إلا أنه من الجيد إنهاء اسم الفئة المشتقة باسم الفئة الأساسية:
class Exception {} class InvalidArgumentException extends Exception {}
الاتساق
استخدم اسمًا واحدًا لمفهوم واحد. أن تكون متسقة.
من الأمثلة الجيدة استخدام begin / end كل مكان بدلاً من مزجه مع start / finish .
اتبع اصطلاحات نمط الكود
عند تطوير مشروع ما ، يجب أن يتفق الفريق على نمط الشفرة واتفاقيات التسمية التي يستخدمونها واتباعها. إذا لم يتم قبول جزء من الاتفاقيات من قبل بعض أعضاء الفريق ، فيجب مراجعتها وتغييرها ووضع قاعدة جديدة.
بالنسبة لـ PHP ، الاتفاقية الأكثر شيوعًا هي PSR-2 ومعظم اتفاقيات المشروع الداخلية تستند إليها.
الإلحاح
تجنب إعادة استخدام الأسماء
يجب تجنب استخدام نفس الاسم للعديد من المفاهيم إن أمكن لأنه يجلب مشكلتين:
- عند القراءة ، عليك أن تضع السياق في الاعتبار. عادة ما يعني ذلك الوصول إلى مساحة الاسم أو إعلان الحزمة باستمرار.
- البحث عن مثل هذه الأسماء هو ألم.
تجنب الانقباضات
لا تستخدم الانقباضات. الأمثلة الشائعة هي:
function cntBigWrds($data, $length) { $i = 0; foreach ($data as $iter) { if (mb_strlen($iter) > $length) { $i++; } } return $i; } $data = ['I', 'am', 'word']; echo cntBigWrds($data, 3);
يصبح الرمز أعلاه عندما تم تسميته بشكل صحيح:
function countWordsLongerThan(array $words, int $minimumLength) { $count = 0; foreach ($words as $word) { if (mb_strlen($word) > $minimumLength) { $count++; } } return $count; } $words = ['I', 'am', 'word']; echo countWordsLongerThan($words, 3);
لاحظ أيضًا أن الأسماء التوضيحية القصيرة بدون الانقباضات أفضل من الأسماء التوضيحية الطويلة ، لذا لا تنتقل إلى النهاية القصوى بأسماء مثل processTextReplacingMoreThanASingleSpaceWithASingleSpace() .
إذا كان الاسم طويلًا جدًا فهذا يعني أنه يمكن إعادة صياغته لجعله أقصر أو أن الشيء الذي تسمونه يقوم به كثيرًا ويجب إعادة تشكيله في أشياء متعددة.
تجنب الاختصارات
تجنب الاختصارات والاختصارات باستثناء الأسماء المعروفة مثل HTML. أرسل Elon Musk رسالة بريد إلكتروني بعنوان "الاختصارات الخطيرة تمتص" لجميع موظفي SpaceX في مايو 2010:
هناك ميل زاحف لاستخدام المختصرات المكياج في SpaceX. يُعد الاستخدام المفرط للمختصرات المكونة للعقبات عائقًا كبيرًا أمام التواصل والحفاظ على التواصل جيدًا أثناء نمونا ، وهو أمر مهم للغاية. بشكل فردي ، قد لا تبدو بعض الاختصارات هنا وهناك سيئة للغاية ، ولكن إذا كان هناك ألف شخص يقومون بذلك ، فمع مرور الوقت ستكون النتيجة مسردًا ضخمًا يتعين علينا إصداره للموظفين الجدد. لا أحد يستطيع فعلاً أن يتذكر كل هذه الاختصارات ولا يريد الناس أن يبدووا أغبياء في اجتماع ، لذلك يجلسون هناك بجهل. هذا صعب بشكل خاص على الموظفين الجدد.
يجب أن يتوقف هذا على الفور أو سأتخذ إجراءات صارمة - لقد وجهت تحذيرات كافية على مر السنين. ما لم يتم اعتماد الاختصار من قبلي ، يجب ألا يدخل مسرد SpaceX. إذا كان هناك اختصار موجود لا يمكن تبريره بشكل معقول ، فيجب إزالته ، كما طلبت في الماضي.
على سبيل المثال ، لا ينبغي أن يكون هناك "HTS" [موقف اختبار أفقي] أو "VTS" [موقف اختبار عمودي] لحامل الاختبار. هذه هي غبية بشكل خاص ، لأنها تحتوي على كلمات غير ضرورية. "موقف" في موقع الاختبار لدينا هو موقف اختبار واضح. VTS-3 عبارة عن أربعة مقاطع لفظية مقارنة بـ "ترايبود" ، وهو مقطعان ، لذا فإن إصدار الاسم المختصر الدموي يستغرق وقتًا أطول لقوله من الاسم!
الاختبار الرئيسي للاختصار هو السؤال عما إذا كان يساعد أو يؤذي التواصل. اختصار يعرفه معظم المهندسين خارج SpaceX بالفعل ، مثل واجهة المستخدم الرسومية ، هو جيد للاستخدام. من المقبول أيضًا تكوين بعض الاختصارات / الانقباضات بين الحين والآخر ، على افتراض أنني قد وافقت عليها ، على سبيل المثال MVac و M9 بدلاً من Merlin 1C-Vacuum أو Merlin 1C-Sea Level ، لكن يجب الإبقاء على الحد الأدنى منها.
أنا أتفق معه.
سهولة القراءة
يجب أن تكون الشفرة قادرة على قراءتها بسهولة مثل النثر. اختر الكلمات التي تختار كتابة مقال أو كتاب. على سبيل المثال ، خاصية باسم TotalAmount قابلة للقراءة باللغة الإنجليزية أكثر من AmountTotal .
إخفاء تفاصيل التنفيذ
يتعلق الأمر بالتصميم الموجه للكائن ولكنه يؤثر على قابلية القراءة كثيرًا إذا تم الكشف عن تفاصيل التطبيق. حاول ألا تكشف الطرق المسماة مثل:
initializeinitcreatebuild
لغة المجال
يجب أن يستخدم الرمز نفس الأسماء المستخدمة في نموذج الأعمال أو النطاق تلقائيًا.
على سبيل المثال ، إذا كانت إحدى شركات السفر تستخدم "مكان" كاسم عام للمقاهي والفنادق ومناطق الجذب السياحي ، فمن المستحسن استخدام "مكان" في الكود لأنك أنت ومستخدميك سيتحدثون لغتين مختلفتين مما يجعله أكثر تعقيدًا مما ينبغي.
غالبًا ما تسمى هذه اللغة "اللغة في كل مكان". يمكنك معرفة المزيد من خلال كتاب مصغر بعنوان " تصميم يحركه المجال بسرعة " بواسطة InfoQ.
الإنجليزية
تستخدم غالبية لغات البرمجة اللغة الإنجليزية للبنيات المدمجة ، ومن الممارسات الجيدة تسمية الأشياء باللغة الإنجليزية أيضًا. من المهم للغاية بالنسبة للمطور أن يتعلم اللغة الإنجليزية على الأقل على المستوى الأساسي ، والأهم من ذلك ، أن يكون لديه مفردات جيدة يمكن للمرء استخدامها للعثور على اسم جيد.
بعض الأدوات المفيدة:
المراجع