javascript شرح ماذا يفعل "استخدام صارم" في جافا سكريبت ، وما هو السبب وراء ذلك؟




use strict شرح (17)

باستخدام 'use strict'; لا يجعل كودك فجأة أفضل.

يعتبر وضع صارم جافا سكريبت ميزة في ECMAScript 5 . يمكنك تمكين الوضع المتشدد عن طريق التصريح بذلك في الجزء العلوي من البرنامج النصي / الوظيفة.

'use strict';

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

خذ بعين الاعتبار هذا المثال:

var a = 365;
var b = 030;

في هاجسهم لمحاذاة القيم الحرفية الرقمية ، قام المطور بطريق الخطأ بتهيئة المتغير b بالحرف الثماني. سوف يفسر الوضع غير الصارم هذا بأنه حرفي رقمي بقيمة 24 (في الأساس 10). ومع ذلك ، فإن وضع صارم رمي خطأ.

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

أين يمكنني استخدام 'use strict'; ؟

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

  • في شفرة جافا سكريبت الحالية الخاصة بي: على الأرجح لا! إذا كانت شفرة JavaScript الموجودة لديك تحتوي على عبارات محظورة في الوضع المقيد ، فسيتم تعطيل التطبيق ببساطة. إذا كنت تريد وضعًا صارمًا ، فيجب أن تكون مستعدًا لتصحيح الأخطاء وتصحيح التعليمات البرمجية الموجودة لديك. هذا هو السبب في استخدام 'use strict'; لا يجعل كودك فجأة أفضل .

كيف أستخدم الوضع المقيد؟

  1. أدخل 'use strict'; بيان على الجزء العلوي من البرنامج النصي الخاص بك:

    // File: myscript.js
    
    'use strict';
    var a = 2;
    ....
    

    لاحظ أنه سيتم تفسير كل شيء في الملف myscript.js في الوضع المقيد.

  2. أو ، أدخل 'use strict'; بيان على الجزء العلوي من جسمك الوظيفي:

    function doSomething() {
        'use strict';
        ...
    }
    

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

ما الأشياء المحظورة في الوضع الصارم؟

لقد عثرت على مقالة لطيفة تصف العديد من الأشياء المحظورة في الوضع المقيد (لاحظ أن هذه ليست قائمة حصرية):

نطاق

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

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

واحدة من مزايا الكود الصارم هي أن أدوات مثل YUI Compressor يمكنها القيام بعمل أفضل عند معالجتها.

متغيرات عالمية ضمنية

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

تسرب عالمي

هناك عدد من الحالات التي قد تتسبب في ربط هذا الكائن العام. على سبيل المثال ، إذا نسيت توفير البادئة new عند استدعاء دالة منشئ ، فسيكون this المنشئ مرتبطًا بشكل غير متوقع بالكائن العمومي ، وذلك بدلاً من تهيئة كائن جديد ، وبدلاً من ذلك سيؤدي ذلك إلى التلاعب بصمت بالمتغيرات العامة. في هذه المواقف ، سيقوم الوضع المقيد بدلاً من ذلك بربط this إلى undefined ، مما يؤدي إلى قيام المُنشئ بطرح استثناء بدلاً من ذلك ، مما يسمح باكتشاف الخطأ في وقت أقرب بكثير.

الفشل الصاخب

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

أوكتال

كان التمثيل الثماني (أو الأساس 8) للأرقام مفيدًا للغاية عند القيام بالبرمجة على مستوى الآلة على الآلات التي كانت أحجام كلماتها متعددة 3. كنت بحاجة إلى ثماني عند العمل مع CDC 6600 mainframe ، الذي كان حجم كلمة 60 بت. إذا كان بإمكانك قراءة الكلمة الثمانية ، يمكنك البحث عن كلمة مكونة من 20 رقمًا. يمثل رقمين رمز المرجع ، وحدد رقم واحد واحد من 8 سجلات. أثناء الانتقال البطيء من رموز الماكينة إلى اللغات عالية المستوى ، كان يُعتقد أنه من المفيد تقديم نماذج ثمانية في لغات البرمجة.

في C ، تم اختيار تمثيل مؤسف للغاية للثماني: يؤدي إلى الصفر. إذن في C ، 0100 تعني 64 وليس 100 و 08 خطأ ، وليس 8. للأسف ، تم نسخ هذه المفارقة التاريخية إلى جميع اللغات الحديثة تقريبًا ، بما في ذلك JavaScript ، حيث يتم استخدامها فقط لإنشاء أخطاء. ليس لها غرض آخر. لذلك في الوضع المقيد ، لا يُسمح باستخدام النماذج الثمانية.

إلى آخره

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

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

الكلمات المحجوزة لإصدارات JavaScript المستقبلية

يضيف ECMAScript 5 قائمة بالكلمات المحجوزة. إذا كنت تستخدمها كمتغيرات أو حجج ، فإن الوضع المقيد سيؤدي إلى حدوث خطأ. الكلمات المحجوزة هي:

implements ، interface ، let ، package ، private ، protected ، public ، static ، yield

قراءة متعمقة

https://code.i-harness.com

في الآونة الأخيرة ، JSLint بعض شفرات جافا سكريبت من خلال JSLint من Crockford ، وقدمت الخطأ التالي:

المشكلة في السطر 1 حرف 1: مفقودة عبارة "استخدام صارم".

عند القيام ببعض البحث ، أدركت أن بعض الأشخاص يضيفون "use strict"; في شفرة جافا سكريبت الخاصة بهم. بمجرد إضافة العبارة ، توقف الخطأ عن الظهور. للأسف ، لم تكشف Google عن الكثير من التاريخ وراء بيان السلسلة هذا. من المؤكد أنه يجب أن يكون هناك علاقة مع كيفية تفسير جافا سكريبت من قبل المتصفح ، ولكن ليس لدي أي فكرة عما سيكون التأثير.

إذن ما هو "use strict"; ماذا تعني ، وماذا يعني ذلك؟

هل يرد أي من المتصفحات الحالية على "use strict"; سلسلة أو هو للاستخدام في المستقبل؟


أود تقديم إجابة أكثر رسوخًا إلى حدٍ ما تكمل الإجابات الأخرى. كنت آمل في تحرير الإجابة الأكثر شعبية ، لكنه فشل. حاولت أن أجعله شاملاً وكاملاً قدر المستطاع.

يمكنك الرجوع إلى وثائق MDN لمزيد من المعلومات.

"use strict" لتوجيه قدم في ECMAScript 5.

التوجيهات مشابهة للبيانات ، لكنها مختلفة.

  • use strict لا يحتوي على كلمات مفتاحية: التوجيه هو عبارة تعبير بسيط ، والذي يتكون من سلسلة خاصة حرفية (في مفرد أو مزدوج الاقتباس). محركات JavaScript ، التي لا تقوم بتطبيق ECMAScript 5 ، تشاهد عبارة تعبيرات بدون آثار جانبية. من المتوقع أن تستخدم الإصدارات المستقبلية من معايير ECMAScript use ككلمة رئيسية حقيقية ؛ وبذلك تصبح العتبات بالية.
  • use strict يمكن أن يستخدم فقط في بداية البرنامج النصي أو وظيفة ، أي أنه يجب أن يسبق كل بيان (حقيقي) آخر. ليس من الضروري أن تكون أول تعليمة في برنامج نصي للوظيفة: يمكن أن يسبقها تعبيرات عبارة أخرى تتكون من حرفية سلسلة (ويمكن لتطبيقات جافا سكريبت معاملتها كتوجيهات محددة للتنفيذ). العبارات الحرفية السلسلة ، التي تتبع أول بيان حقيقي (في برنامج نصي أو وظيفة) هي عبارات بسيطة للتعبير. يجب ألا يفسر المترجمون أنفسهم على أنهم توجيهات وليس لها أي تأثير.

يشير use strict التوجيه use strict إلى أن التعليمة البرمجية التالية (في برنامج نصي أو دالة) هي تعليمات برمجية صارمة. يعتبر الرمز الموجود في أعلى مستوى من البرنامج النصي (رمز غير موجود في إحدى الوظائف) رمزًا صارمًا عندما يحتوي البرنامج النصي على توجيه use strict . يعتبر محتوى الدالة رمزًا صارمًا عندما يتم تعريف الدالة نفسها في شفرة صارمة أو عندما تحتوي الدالة على use strict توجيه use strict . يعتبر الرمز الذي يتم تمريره إلى طريقة eval() رمزًا صارمًا عند استدعاء eval() من شفرة صارمة أو يحتوي على use strict توجيه use strict بحد ذاته.

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

  • لا يمكنك استخدام with -atatim في الوضع المقيد.
  • في الوضع المقيد يجب أن يتم الإعلان عن جميع المتغيرات: إذا قمت بتعيين قيمة لمعرف لم يتم تعريفه كمتغير أو دالة أو معلمة دالة أو معلمة catch-group أو خاصية Object ، فستحصل على ReferenceError . في الوضع العادي يتم تعريف المعرّف ضمنيًا كمتغير شامل (كخاصية Object )
  • في الوضع المتشدد ، الكلمة الأساسية this لها القيمة undefined في الوظائف التي تم استدعاؤها كوظائف (ليس كطرق). (في الوضع العادي يشير this دائمًا إلى Object ). يمكن استخدام هذا الاختلاف لاختبار ما إذا كان التنفيذ يدعم الوضع المتشدد:
var hasStrictMode = (function() { "use strict"; return this===undefined }());
  • أيضا عندما يتم استدعاء دالة مع call() أو apply في الوضع المقيد ، فإن this هو بالضبط قيمة الوسيطة الأولى من call() أو apply() الاستدعاء. (في الوضع العادي null وغير undefined يتم استبداله Object والقيم العالمية ، والتي ليست كائنات ، يتم إرسالها إلى كائنات.)

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

  • في الوضع المقيد ، عند تمرير التعليمة البرمجية إلى eval() ، لا يمكنك تعريف أو تعريف المتغيرات أو الدالات في نطاق المتصل (كما يمكنك القيام بذلك في الوضع العادي). بدلاً من ذلك ، يتم إنشاء نطاق جديد لـ eval() وتكون المتغيرات والوظائف داخل هذا النطاق. يتم إتلاف هذا النطاق بعد انتهاء eval() التنفيذ.
  • في الوضع المتشدد يحتوي كائن الوسيطات للدالة على نسخة ثابتة من القيم ، والتي يتم تمريرها إلى هذه الوظيفة. في الوضع العادي ، يحتوي كائن الوسيطات على سلوك "سحري" إلى حد ما: تشير عناصر الصفيف ومعلمات الدالة المسماة إلى نفس القيمة.
  • في الوضع SyntaxError ستحصل على SyntaxError عندما يتبع عامل delete معرف غير مؤهل (متغير أو دالة أو معلمة دالة). في الوضع العادي ، لن يؤدي تعبير delete أي شيء ويتم تقييمه إلى false .
  • في الوضع المقيد سوف تحصل على TypeError عند محاولة حذف خاصية غير قابلة للتكوين. (في الوضع العادي ، تفشل المحاولة ببساطة ويتم تقييم تعبير delete إلى false ).
  • في الوضع الصارم ، يعتبر خطأً بناء عليه عندما تحاول تحديد عدة خصائص بنفس الاسم لكائن حَرَري. (في الوضع العادي لا يوجد خطأ.)
  • في الوضع الصارم ، يعتبر خطأً بناء عليه عندما يكون لإعلان الدالة عدة معلمات بنفس الاسم. (في الوضع العادي لا يوجد خطأ.)
  • في الوضع الصارم لا يسمح بالمعايير الحرفية الثمانية (هذه هي القيم الحرفية التي تبدأ بـ 0x . (في الوضع العادي ، تسمح بعض التطبيقات بالخصائص الثماني.)
  • في الوضع المقيد يتم التعامل مع معرفات eval arguments مثل الكلمات الرئيسية. لا يمكنك تغيير قيمتها ، ولا يمكن تعيين قيمة لها ، ولا يمكنك استخدامها كأسماء للمتغيرات أو الدالات أو معلمات الدالة أو معرفات كتلة catch.
  • في الوضع الصارم أكثر القيود على إمكانيات لفحص مكدس الاستدعاءات. تسبب arguments.callee و arguments.callee TypeError في وظيفة في الوضع المقيد. علاوة على ذلك ، تتسبب بعض خصائص المتصل والحجج للوظائف في الوضع المقيد في TypeError عند محاولة قراءتها.

إذا كان الناس قلقين من use strict ، فقد يكون من المفيد مراجعة هذا المقال:

دعم ECMAScript 5 'وضع صارم' في المتصفحات. ماذا يعني هذا؟
NovoGeek.com - مدونة كريشنا

يتحدث عن دعم المتصفح ، ولكن الأهم من ذلك كيفية التعامل معه بأمان:

function isStrictMode(){
    return !this;
} 
/*
   returns false, since 'this' refers to global object and 
   '!this' becomes false
*/

function isStrictMode(){   
    "use strict";
    return !this;
} 
/* 
   returns true, since in strict mode the keyword 'this'
   does not refer to global object, unlike traditional JS. 
   So here, 'this' is 'undefined' and '!this' becomes true.
*/

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

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


انها ميزة جديدة من ECMAScript 5. كتب جون رسيج ملخصا لطيفا لذلك.

إنها مجرد سلسلة تضعها في ملفات جافا سكريبت (إما في أعلى ملفك أو داخل إحدى الوظائف) تبدو كالتالي:

"use strict";

يجب ألا يتسبب وضعه في شفرتك الآن في حدوث أي مشكلات في المتصفحات الحالية لأنها مجرد سلسلة. قد يتسبب ذلك في حدوث مشكلات في التعليمات البرمجية في المستقبل في حالة انتهاك التعليمات البرمجية الخاصة بك pragma. على سبيل المثال ، إذا كان لديك حاليًا foo = "bar" بدون تعريف foo أولاً ، foo شفرتك بالفشل ... وهذا أمر جيد في رأيي.


عند إضافة "use strict"; ، ستقوم الحالات التالية بإلقاء SyntaxError قبل تنفيذ البرنامج النصي:

  • تمهيد الطريق لإصدارات ECMAScript المستقبلية ، باستخدام إحدى الكلمات الرئيسية المحجوزة حديثًا (في النسخة السابقة من ECMAScript 6 ): implements، interface، let، package، private، protected، public، static، ، و yield.

  • الإعلان عن وظيفة في كتل

    if(a<b){ function f(){} }
    
  • تركيب أوكتال

    var n = 023;
    
  • this أشر إلى الكائن العام.

     function f() {
          "use strict";
          this.a = 1;
     };
     f(); 
    
  • التصريح مرتين بنفس الاسم لاسم خاصية في كائن حرفي

     {a: 1, b: 3, a: 7} 
    

    لم يعد هذا هو الحال في ECMAScript 6 ( علة 1041128 ).

  • التصريح عن وسيطتي وظيفتين بنفس وظيفة الاسم

    f(a, b, b){}
    
  • ضبط قيمة لمتغير غير مُعلن

    function f(x){
       "use strict";
       var a = 12;
       b = a + x*35; // error!
    }
    f();
    
  • باستخدام deleteاسم متغيرdelete myVariable;

  • استخدام evalأو argumentsكوسيطة متغير أو وظيفة

    "use strict";
    arguments++;
    var obj = { set p(arguments) { } };
    try { } catch (arguments) { }
    function arguments() { } 
    

مصادر:


كلمة تحذير ، كل ما تحتاجه من المبرمجين: تطبيق "use strict" على الكود الموجود يمكن أن يكون خطيراً! هذا الشيء ليس بعض الملائات الجيدة ، والملصقة على الوجه الذي يمكنك وضعه على الكود لجعله "أفضل". مع pragma "use strict" ، سوف يقوم المتصفح فجأة بإلغاء الاستثناءات في الأماكن العشوائية التي لم يلقيها من قبل فقط لأن في هذه البقعة تقوم بعمل شيء يفيد جافا سكريبت الافتراضي / المفيد لحسن الحظ لكن جامعات JavaScript صارمة! قد يكون لديك مخالفات صارمة مختبئة في المكالمات القليلة الاستخدام في شفرتك والتي ستلقي استثناءً فقط عندما يتم تشغيلها في النهاية - ولنفترض في بيئة الإنتاج التي يستخدمها العملاء الذين يستخدمون الدفع!

إذا كنت ستأخذ الهبوط ، فمن المستحسن تطبيق "use strict" إلى جانب اختبارات الوحدة الشاملة ومهمة إنشاء JSHint التي تم تكوينها بشكل صارم والتي ستمنحك بعض الثقة أنه لا يوجد ركن مظلم من الوحدة النمطية التي ستفجر بشكل مرعب لمجرد أنك شغلت وضع Strict Mode. أو ، ها هي خيار آخر: لا تضيف "use strict" لأي من التعليمات البرمجية القديمة ، فمن المحتمل أن تكون أكثر أمانًا بهذه الطريقة ، بصراحة. بالتأكيد لا تضيف "use strict" إلى أي وحدات لا تملكها أو تحتفظ بها ، مثل وحدات طرف ثالث.

أعتقد أنه على الرغم من أنه حيوان مميت في القفص ، إلا أن "use strict" يمكن أن يكون شيئًا جيدًا ، ولكن عليك القيام به بشكل صحيح. أفضل وقت لتضييق الخناق هو عندما يكون مشروعك هو greenfield وأنت تبدأ من الصفر. قم بتكوين JSHint/JSLint مع جميع التحذيرات والخيارات التي تم JSHint/JSLint ، والحصول على بنية / اختبار / تأكيد جيد على نظام jour مزور مثل Grunt+Karma+Chai ، JSHint/JSLint فقط JSHint/JSLint جميع JSHint/JSLint الجديدة كـ "use strict" . كن مستعدًا لعلاج الكثير من الأخطاء والتحذيرات. تأكد من أن الجميع يفهم الجاذبية من خلال تكوين JSHint/JSLint على FAIL إذا كان JSHint/JSLint ينتج أي انتهاكات.

لم يكن مشروعي مشروعًا جديدًا عندما اعتمدت "use strict" . ونتيجة لذلك ، فإن IDE الخاص بي مليء بالعلامات الحمراء لأنه ليس لدي "use strict" في نصف وحداتي ، و JSHint يشكو من ذلك. إنه تذكير لي بشأن إعادة البناء التي ينبغي علي القيام بها في المستقبل. هدفي هو أن أكون علامة حمراء حرة بسبب كل بياناتي "use strict" عداد المفقودين ، ولكن هذا هو سنوات بعيدا الآن.


يجعل الوضع المقيد العديد من التغييرات على دلالات JavaScript السليمة:

  • يحل بعض أخطاء جافا سكريبت الصامتة عن طريق تغييرها لرمي الأخطاء.

  • إصلاح الأخطاء التي تجعل من الصعب على محركات جافا سكريبت إجراء عمليات التحسين.

  • يحظر بعض بناء الجملة من المحتمل أن يتم تعريفها في الإصدارات المستقبلية من ECMAScript.

لمزيد من المعلومات vistit Strict Mode - Javascript


"use strict"يجعل تعليمات JavaScript البرمجية تعمل في الوضع المقيد ، وهو ما يعني بالضرورة أن كل شيء يحتاج إلى تعريف قبل الاستخدام. السبب الرئيسي لاستخدام الوضع الصارم هو تجنب الاستخدامات العالمية غير المقصودة للطرق غير المحددة.

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

"use strict"هناك حاجة كبيرة لاستخدامها في ECMA5 ، في ECMA6 جزء من جافا سكريبت بشكل افتراضي ، لذلك لا تحتاج إلى إضافتها إذا كنت تستخدم ES6.

انظر إلى هذه العبارات والأمثلة من MDN:

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

أمثلة على استخدام "استخدام صارم":
وضع صارم للوظائف: وبالمثل ، لاستدعاء وضع صارم لوظيفة ، ضع العبارة الدقيقة "استخدام صارم" ؛ (أو "استخدام صارم" ؛) في جسم الدالة قبل أي عبارات أخرى.

1) وضع صارم في وظائف

 function strict() {
     // Function-level strict mode syntax
     'use strict';
     function nested() { return 'And so am I!'; }
     return "Hi!  I'm a strict mode function!  " + nested();
 }
 function notStrict() { return "I'm not strict."; }

 console.log(strict(), notStrict());

2) وضع النص الكامل الوضع الصارم

'use strict';
var v = "Hi! I'm a strict mode script!";
console.log(v);

3) التنازل إلى عالمي غير قابل للكتابة

'use strict';

// Assignment to a non-writable global
var undefined = 5; // throws a TypeError
var Infinity = 5; // throws a TypeError

// Assignment to a non-writable property
var obj1 = {};
Object.defineProperty(obj1, 'x', { value: 42, writable: false });
obj1.x = 9; // throws a TypeError

// Assignment to a getter-only property
var obj2 = { get x() { return 17; } };
obj2.x = 5; // throws a TypeError

// Assignment to a new property on a non-extensible object.
var fixed = {};
Object.preventExtensions(fixed);
fixed.newProp = 'ohai'; // throws a TypeError

يمكنك قراءة المزيد عن MDN .


use strict طريقة لجعل رمزك أكثر أمانًا ، لأنك لا تستطيع استخدام ميزات خطيرة لا تعمل كما هو متوقع. وكما تم كتابتها قبل أن تجعل الشفرة أكثر صرامة.


مثال صغير للمقارنة:

وضع غير صارم:

for (i of [1,2,3]) console.log(i)

// output:
// 1
// 2
// 3

الوضع الصارم:

'use strict';
for (i of [1,2,3]) console.log(i)

// output:
// Uncaught ReferenceError: i is not defined

يستخدم استخدام Strict لإظهار الأخطاء الشائعة والمتكررة بحيث يتم التعامل معها بشكل مختلف ، وتغيير طريقة تشغيل برنامج java ، وهذه التغييرات هي:

  • يمنع globals عرضي

  • لا يوجد نسخ مكررة

  • يختفي مع

  • يقضي على هذا الإكراه

  • أكثر أمانا ()

  • أخطاء للغير قابلة للتغيير

يمكنك أيضًا قراءة هذه article للحصول على التفاصيل


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

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

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

يجب أن تستحضر ممارسة JavaScript الحديثة دائما "استخدام صارم" ؛ PRAGMA. السبب الوحيد وراء جعل المجموعة ECMA وضع "Strict" الاختياري هو السماح للمبرمجين الأقل خبرة بالوصول إلى JavaScript وإعطاء الوقت للتكيف مع ممارسات الترميز الجديدة والأكثر أمانًا.


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


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

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


لاحظ أنه use strictتم تقديمه في EcmaScript 5 وتم الاحتفاظ به منذ ذلك الحين.

فيما يلي شروط تشغيل الوضع ES6 في ES6 و ES7 :

  • الشفرة العامة هي شفرة نمط صارمة إذا بدأت برمز توجيهي يتضمن توجيه استخدام صارم (انظر 14.1.1).
  • رمز الوحدة هو دائما رمز الوضع الصارم.
  • كافة أجزاء ClassDeclaration أو ClassExpression هي رمز وضع صارم.
  • شفرة Eval هي شفرة نمط صارمة إذا كانت تبدأ بـ Prologue Directive الذي يحتوي على استخدام Strict Directive أو إذا كانت الاستدلال على eval عبارة عن eval مباشر (راجع 12.3.4.1) الموجود في التعليمات البرمجية ذات الوضع الصارم.
  • رمز الدالة هو رمز الوضع الصارم إذا كان يتم تضمين الدالة FunctionDeclaration أو FunctionExpression أو GeneratorDeclaration أو GeneratorExpression أو MethodDefinition أو ArrowFunction في كود الوضع الصارم أو إذا كانت الشفرة التي تنتج قيمة الفتحة الداخلية [[ECMAScriptCode]] الخاصة بالوظيفة تبدأ بـ Prologue Directive Prologue يحتوي على استخدام توجيه صارم.
  • كود الدالة التي يتم توفيره والحجج على وظيفة المدمج في والصانعين مولد هو رمز وضع صارم إذا كانت الوسيطة الأخيرة هي سلسلة أنه عندما معالجتها هو FunctionBody الذي يبدأ مع مقدمة التوجيه التي تحتوي على استخدام التوجيه الصارم.

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







use-strict