كود النينجا

التعلم بدون تفكير هو جهد ضائع. التفكير دون تعلم أمر محفوف بالمخاطر.

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

يبحث عنها خبراء مراجعة التعليمات البرمجية في مهام الاختبار.

أحيانًا يستخدمها المطورون المبتدئون بشكل أفضل من النينجا المبرمجين.

اقرأها بعناية واكتشف من أنت - نينجا أم مبتدئ أم ربما مراجع أكواد؟

تم الكشف عن المفارقة

يحاول الكثير اتباع مسارات النينجا. قليلون ينجحون.

الإيجاز هو روح الطرافة

اجعل الرمز قصيرًا قدر الإمكان. أظهر مدى ذكائك.

دع ميزات اللغة الدقيقة ترشدك.

على سبيل المثال، ألقِ نظرة على عامل التشغيل الثلاثي '?' :

 // مأخوذ من مكتبة جافا سكريبت المعروفة
أنا = أنا ؟ أنا <0؟ Math.max(0, len + i) : i : 0;

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

أخبرهم أن الأقصر هو الأفضل دائمًا. أدخلهم في مسارات النينجا.

متغيرات من حرف واحد

يختبئ الداو في صمت. فقط الداو هو الذي بدأ بشكل جيد واكتمل بشكل جيد.

هناك طريقة أخرى لرمز أقصر وهي استخدام أسماء متغيرة ذات حرف واحد في كل مكان. مثل a أو b أو c .

يختفي متغير قصير في الكود مثل النينجا الحقيقي في الغابة. لن يتمكن أحد من العثور عليه باستخدام "البحث" في المحرر. وحتى لو فعل شخص ما ذلك، فلن يتمكن من "فك رموز" ما يعنيه الاسم a أو b .

…ولكن هناك استثناء. النينجا الحقيقي لن يستخدم i أبدًا كعداد في حلقة "for" . في أي مكان، ولكن ليس هنا. انظر حولك، هناك العديد من الرسائل الغريبة. على سبيل المثال، x أو y .

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

استخدم الاختصارات

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

مثله:

• list → lst .

• userAgent → ua .

• browser → brsr .

• …إلخ

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

ترتفع عاليا. كن مجردًا.

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

أثناء اختيار الاسم، حاول استخدام الكلمة الأكثر تجريدًا. مثل obj ، data ، value ، item ، elem وما إلى ذلك.

• الاسم المثالي للمتغير هو data . استخدامه في كل مكان يمكنك. في الواقع، كل متغير يحمل البيانات ، أليس كذلك؟

  …ولكن ماذا تفعل إذا تم أخذ data بالفعل؟ جرب value ، فهي أيضًا عالمية. ففي نهاية المطاف، يحصل المتغير على قيمة .

• تسمية المتغير حسب نوعه: str , num ...

  جربهم. قد يتساءل المبتدئ الشاب: هل هذه الأسماء مفيدة حقًا للنينجا؟ في الواقع، هم!

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

  من السهل اكتشاف نوع القيمة عن طريق التصحيح. ولكن ما معنى المتغير؟ ما هي السلسلة/الرقم الذي يتم تخزينه؟

  لا توجد طريقة لمعرفة ذلك دون التأمل الجيد!

• …ولكن ماذا لو لم يعد هناك المزيد من هذه الأسماء؟ ما عليك سوى إضافة رقم: data1, item2, elem5 ...

اختبار الانتباه

فقط المبرمج اليقظ حقًا هو الذي يجب أن يكون قادرًا على فهم الكود الخاص بك. ولكن كيف يمكن التحقق من ذلك؟

إحدى الطرق - استخدام أسماء متغيرة مماثلة، مثل date data .

مزجها حيث يمكنك.

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

المرادفات الذكية

الطاو الذي يمكن قوله ليس الطاو الأبدي. الاسم الذي يمكن تسميته ليس الاسم الأبدي.

إن استخدام أسماء متشابهة لنفس الأشياء يجعل الحياة أكثر إثارة ويظهر إبداعك للجمهور.

على سبيل المثال، ضع في اعتبارك بادئات الوظائف. إذا كانت إحدى الوظائف تعرض رسالة على الشاشة - ابدأها بـ display… ، مثل displayMessage . وبعد ذلك، إذا أظهرت وظيفة أخرى شيئًا آخر على الشاشة، مثل اسم المستخدم، فابدأها بـ show… (مثل showName ).

ألمح إلى أن هناك فرقًا دقيقًا بين هذه الوظائف، بينما لا يوجد أي منها.

عقد اتفاقًا مع زملائه من النينجا في الفريق: إذا بدأ جون "بإظهار" الوظائف مع display... في الكود الخاص به، فيمكن لبيتر استخدام render.. وAnn - paint... . لاحظ كم أصبح الكود أكثر إثارة للاهتمام وتنوعًا.

…والآن هاتريك!

بالنسبة لوظيفتين مع وجود اختلافات مهمة - استخدم نفس البادئة!

على سبيل المثال، ستستخدم الدالة printPage(page) الطابعة. وستقوم الدالة printText(text) بوضع النص على الشاشة. اسمح للقارئ غير المألوف بالتفكير جيدًا في وظيفة تحمل اسمًا مشابهًا printMessage : "أين تضع الرسالة؟ إلى الطابعة أم على الشاشة؟”. لجعلها تتألق حقًا، يجب أن تقوم printMessage(message) بإخراجها في النافذة الجديدة!

إعادة استخدام الأسماء

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

أضف متغيرًا جديدًا فقط عند الضرورة القصوى.

بدلاً من ذلك، قم بإعادة استخدام الأسماء الموجودة. فقط اكتب قيمًا جديدة فيها.

في إحدى الوظائف، حاول استخدام المتغيرات التي تم تمريرها كمعلمات فقط.

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

أحد الأشكال المتقدمة لهذا النهج هو استبدال القيمة سرًا (!) بشيء مماثل في منتصف حلقة أو دالة.

على سبيل المثال:

 وظيفة النينجاFunction(عنصر) {
  // 20 سطرًا من التعليمات البرمجية تعمل مع العنصر

  elem = clone(elem);

  // 20 سطرًا إضافيًا، تعمل الآن مع نسخة العنصر!
}

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

ينظر في التعليمات البرمجية بانتظام. فعالة بشكل مميت حتى ضد النينجا ذوي الخبرة.

يؤكد على المتعة

ضع الشرطة السفلية _ و __ قبل أسماء المتغيرات. مثل _name أو __value . سيكون أمرا رائعا لو كنت تعرف معناها فقط. أو من الأفضل إضافتها للمتعة فقط، دون أي معنى محدد على الإطلاق. أو معاني مختلفة في أماكن مختلفة.

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

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

أظهر حبك

دع الجميع يرون مدى روعة كياناتك! أسماء مثل superElement و megaFrame و niceItem سوف تنير القارئ بالتأكيد.

في الواقع، من ناحية، هناك شيء مكتوب: super.. ، mega.. ، nice.. ولكن من ناحية أخرى - هذا لا يحمل أي تفاصيل. قد يقرر القارئ البحث عن معنى خفي والتأمل لمدة ساعة أو ساعتين من وقت عمله المدفوع الأجر.

تداخل المتغيرات الخارجية

عندما تكون في النور، لا تستطيع رؤية أي شيء في الظلام.
عندما تكون في الظلام تستطيع أن ترى كل شيء في النور.

استخدم نفس الأسماء للمتغيرات داخل وخارج الوظيفة. بهذه البساطة. لا توجد جهود لاختراع أسماء جديدة.

 السماح للمستخدم = AuthenticateUser();

تقديم الوظيفة () {
  السماح للمستخدم = AnotherValue();
  ...
  .. أسطر كثيرة ...
  ...
  ... // <-- يريد المبرمج العمل مع المستخدم هنا و...
  ...
}

من المحتمل أن يفشل المبرمج الذي يقفز داخل render في ملاحظة وجود user محلي يتتبع المستخدم الخارجي.

ثم سيحاولون العمل مع user على افتراض أنه المتغير الخارجي، نتيجة لـ authenticateUser() ... لقد انتشر الفخ! مرحباً أيها المصحح...

الآثار الجانبية في كل مكان!

هناك وظائف تبدو وكأنها لا تغير أي شيء. مثل isReady() و checkPermission() و findTags() … من المفترض أن تقوم بإجراء العمليات الحسابية والعثور على البيانات وإعادتها دون تغيير أي شيء خارجها. وبعبارة أخرى، دون "آثار جانبية".

الحيلة الجميلة حقًا هي إضافة إجراء "مفيد" لهم إلى جانب المهمة الرئيسية.

تعبير المفاجأة الذهول على وجه زميلك عندما يرى وظيفة مسماة is.. ، check.. أو find... تغيير شيء ما - سيوسع بالتأكيد حدود عقلك.

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

أظهر تفكيرك الأصلي! دع استدعاء checkPermission لا يُرجع true/false ، بل كائنًا معقدًا مع نتائج الفحص.

هؤلاء المطورون الذين يحاولون كتابة if (checkPermission(..)) سوف يتساءلون لماذا لا يعمل. قل لهم: "اقرأ المستندات!". وإعطاء هذه المادة.

وظائف قوية!

الطاو العظيم يتدفق في كل مكان،
سواء إلى اليسار أو اليمين.

لا تقصر الوظيفة على ما هو مكتوب باسمها. كن أوسع.

على سبيل المثال، يمكن لوظيفة validateEmail(email) (إلى جانب التحقق من صحة البريد الإلكتروني) أن تعرض رسالة خطأ وتطلب إعادة إدخال البريد الإلكتروني.

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

يؤدي ضم عدة إجراءات إلى إجراء واحد إلى حماية التعليمات البرمجية الخاصة بك من إعادة الاستخدام.

تخيل أن مطورًا آخر يريد فقط التحقق من البريد الإلكتروني، وعدم إخراج أي رسالة. وظيفتك validateEmail(email) التي تعمل على حد سواء لن تناسبهم. لذلك لن يكسروا تأملك بسؤال أي شيء عنه.

ملخص

جميع "النصائح" المذكورة أعلاه مأخوذة من كود حقيقي... وفي بعض الأحيان، كتبها مطورون ذوو خبرة. وربما أكثر خبرة منك ;)

• اتبع بعضها، وسيصبح رمزك مليئًا بالمفاجآت.

• اتبع العديد منها، وسوف يصبح الكود الخاص بك ملكك حقًا، ولن يرغب أحد في تغييره.

• اتبع كل شيء، وسوف يصبح الكود الخاص بك درسًا قيمًا للمطورين الشباب الذين يبحثون عن التنوير.