اسمحوا مقابل كونت - ماذا تستخدم؟

مرحبا يا هبر! أقدم إليكم ترجمة المقال "On let vs const" للمخرج دان أبراموف .

نشرتي السابقة تحتوي على هذه الفقرة:

let vs const vs var : عادة ، كل ما تحتاجه هو let . إذا كنت بحاجة إلى منع إعادة كتابة متغير ، يمكنك استخدام const . (بعضها متحذّر للغاية بشأن هذا ويفضل استخدام const عندما يكون هناك مهمة واحدة متغيرة فقط).

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

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

لماذا تفضل const

• قاعدة واضحة: هذا عبء إضافي للعقل عندما يتعين عليك التفكير في كل مرة سواء كان استخدام const أو السماح أفضل. تحرر القاعدة "استخدم دائمًا const حيث تعمل" من مشاحنات لا لزوم لها وتترك هذه المهمة إلى linter.
• يمكن أن تتسبب عمليات إعادة التعيين في حدوث أخطاء: في الوظائف الكبيرة ، قد لا تلاحظ ما إذا كان قد تم إعادة تعيين متغير ، وهذا قد يكون سبب الأخطاء. خاصة في الإغلاقات. يمنحك Const تأكيدًا بأنك سترى دائمًا نفس القيمة.
• فهم الطفرة: أولئك الذين بدأوا لتعلم جافا سكريبت قد يسيئون فهم مبدأ const ، معتقدين أنه يمنع طفرة المتغير. من المهم أن نفهم الفرق بين تحوير المتغير وإعادة التعيين. استخدام const يفرض عليك فهم هذا التمييز ومواجهته مبكرًا.
• عمليات إعادة التعيين التي لا معنى لها: في بعض الأحيان ، لا تكون إعادة تعيين متغير منطقية على الإطلاق. على سبيل المثال ، في React Hooks ، فإن القيم التي تحصل عليها من الخطاف - مثل useState - تشبه المعلمات. إنهم يسيرون في نفس الاتجاه. رؤية خطأ في مهمتهم ، سوف تتعرف على تدفق بيانات React.
• مزايا التنفيذ: هناك أيضًا مطالبات نادرة بأن مشغل JavaScript يمكنه تنفيذ التعليمات البرمجية بشكل أسرع عند استخدام const ، لأنه يعلم أنه لا يمكن الكتابة فوق متغير.

لماذا لا تفضل const

• Const يفقد معناها: إذا استخدمنا const في كل مكان ، فسوف نفقد القدرة على فهم ما إذا كان من المهم عدم إعادة تخصيص شيء ما.
• الإحراج بالحصانة: في كل نقاش يقولون إنه يجب عليك دائمًا استخدام const ، هناك من يشوشون حول مسألة الحصانة. هذا ليس مفاجئًا لأن كلتا العمليتين (الإعلان وإعادة التعيين) تستخدم نفس عامل التشغيل "=". ردا على هذا ، يقولون عادة أنك تحتاج فقط إلى "تعلم اللغة". ومع ذلك ، فإن الحيل المضادة هي أنه إذا كانت الطريقة ، وهي منع أخطاء المبتدئين ، تربك هؤلاء المبتدئين ، فهذا ليس مفيدًا جدًا. ولسوء الحظ ، لا يساعد هذا في منع أخطاء الطفرة التي تمتد إلى الوحدات النمطية وتؤثر على كل شيء.
• الضغط لتجنب الإفراط في الإعلان: يفرض أنصار الأسلوب "const-first" على مطوري البرامج عدم استخدام السماح للمتغيرات التي تم الإعلان عنها في الحالة. على سبيل المثال ، يمكنك الكتابة

  const a = cond ? b : c 

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

رأيي

لا يهمني

يمكنني استخدام أي قاعدة يستخدمها الآخرون.

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

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

رابط إلى المقال الأصلي - On let vs const .