[Javascript] ماذا يفعل "استخدام صارم" في جافا سكريبت ، وما هو السبب وراء ذلك؟


Answers

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

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

"use strict";

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

Question

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

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

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

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

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




When adding "use strict"; , the following cases will throw a SyntaxError before the script is executing:

  • Paving the way for future ECMAScript versions , using one of the newly reserved keywords (in prevision for ECMAScript 6 ): implements , interface , let , package , private , protected , public , static , and yield .

  • Declaring function in blocks

    if(a<b){ function f(){} }
    
  • Octal syntax

    var n = 023;
    
  • this point to the global object.

     function f() {
          "use strict";
          this.a = 1;
     };
     f(); 
    
  • Declaring twice the same name for a property name in an object literal

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

    This is no longer the case in ECMAScript 6 ( bug 1041128 ).

  • Declaring two function arguments with the same name function

    f(a, b, b){}
    
  • Setting a value to an undeclared variable

    function f(x){
       "use strict";
       var a = 12;
       b = a + x*35; // error!
    }
    f();
    
  • Using delete on a variable name delete myVariable;

  • Using eval or arguments as variable or function argument name

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

مصادر:




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

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

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

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




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

يمكنك الرجوع إلى وثائق 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.
*/



باستخدام '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

قراءة متعمقة




The main reasons why developers should use "use strict" are:

  1. Prevents accidental declaration of global variables.Using "use strict()" will make sure that variables are declared with var before use. على سبيل المثال:

    function useStrictDemo(){
     'use strict';
     //works fine
     var a = 'No Problem';
    
     //does not work fine and throws error
     k = "problem"
    
     //even this will throw error
     someObject = {'problem': 'lot of problem'};
    }
    
  2. NB: The "use strict" directive is only recognized at the beginning of a script or a function.
  3. The string "arguments" cannot be used as a variable:

    "use strict";
    var arguments = 3.14;    // This will cause an error
    
  4. Will restrict uses of keywords as variables. Trying to use them will throw errors.

In short will make your code less error prone and in turn will make you write good code.

To read more about it you can refer http://www.w3schools.com/js/js_strict.asp .




Note that use strict was introduced in EcmaScript 5 and was kept since then.

Below are the conditions to trigger strict mode in ES6 and ES7 :

  • Global code is strict mode code if it begins with a Directive Prologue that contains a Use Strict Directive (see 14.1.1).
  • Module code is always strict mode code.
  • All parts of a ClassDeclaration or a ClassExpression are strict mode code.
  • Eval code is strict mode code if it begins with a Directive Prologue that contains a Use Strict Directive or if the call to eval is a direct eval (see 12.3.4.1) that is contained in strict mode code.
  • Function code is strict mode code if the associated FunctionDeclaration, FunctionExpression, GeneratorDeclaration, GeneratorExpression, MethodDefinition, or ArrowFunction is contained in strict mode code or if the code that produces the value of the function's [[ECMAScriptCode]] internal slot begins with a Directive Prologue that contains a Use Strict Directive.
  • Function code that is supplied as the arguments to the built-in Function and Generator constructors is strict mode code if the last argument is a String that when processed is a FunctionBody that begins with a Directive Prologue that contains a Use Strict Directive.



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

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




"use strict"; is the ECMA effort to make JavaScript a little bit more robust. It brings in JS an attempt to make it at least a little "strict" (other languages implement strict rules since the 90s). It actually "forces" JavaScript developers to follow some sort of coding best practices. Still, JavaScript is very fragile. There is no such thing as typed variables, typed methods, etc. I strongly recommend JavaScript developers to learn a more robust language such as Java or ActionScript3, and implement the same best practices in your JavaScript code, it will work better and be easier to debug.




There's a good talk by some people who were on the ECMAScript committee: Changes to JavaScript, Part 1: ECMAScript 5" about how incremental use of the "use strict" switch allows JavaScript implementers to clean up a lot of the dangerous features of JavaScript without suddenly breaking every website in the world.

Of course it also talks about just what a lot of those misfeatures are (were) and how ECMAScript 5 fixes them.




Normally java script does not follow strict rules hence increasing chances of errors. After using "use strict" , the java script code should follow strict set of rules as like in other programming languages such as use of terminators, declaration before initialization etc.

If "use strict" is used then the code should be written by following a strict set of rules hence decreasing the chances of errors and ambiguities.




Just wanted to add some more points.

The Reason to Use Strict Mode--->

  • Strict mode makes it easier to write "secure" JavaScript.

  • Strict mode changes previously accepted "bad syntax" into real
    أخطاء.

  • As an example, in normal JavaScript, mistyping a variable name
    creates a new global variable.

  • In strict mode, this will throw an error, making it impossible to accidentally create a global variable.

  • In strict mode, any assignment to a non-writable property, a
    getter-only property, a non-existing property, a non-existing
    variable, or a non-existing object, will throw an error.

The things that will throw errors in Strict Mode Using a variable, without declaring it, is not allowed:

"use strict";
 x = 3.14;                // This will cause an error

Objects are variables too.

Using an object, without declaring it, is not allowed:

  "use strict";
  x = {p1:10, p2:20};      // This will cause an error

Deleting a variable (or object) is not allowed.

  "use strict";
   var x = 3.14;
   delete x;                // This will cause an error

For security reasons, eval() is not allowed to create variables in the scope from which it was called:

"use strict";
 eval ("var x = 2");
 alert (x);               // This will cause an error

In function calls like f(), the this value was the global object. In strict mode, it is now undefined.

"use strict" is only recognized at the beginning of a script.