Какво прави „стриктен“ в JavaScript и какви са причините за това?

Наскоро пуснах JavaScript кода си чрез Crockford JSLint и той даде следната грешка:

Проблем в първия знак 1: Липсва изявление „използвайте стриктно“.

Докато вършах някои търсения, осъзнах, че някои хора добавят "use strict"; във вашия JavaScript код. Веднага след като добавих израза, грешката престана да се появява. За съжаление Google не разкри голяма част от историята на тази операторска линия. Разбира се, това трябва да е свързано с начина, по който JavaScript се интерпретира от браузъра, но не знам какъв ще бъде ефектът.

И така, какво е "use strict"; е всичко за това, което това предполага, и все още ли е уместно?

Всеки настоящ браузър отговаря на "use strict"; или за бъдеща употреба?

6989
26 авг. определени от Марк Роджърс 26 авг. 2009-08-26 19:10 '09 в 19:10 2009-08-26 19:10
@ 30 отговора

Тази статия във Javascript Strict Mode може да ви заинтересува: John Resig - ECMAScript 5 Строг режим, JSON и др.

За да цитирам някои интересни части:

Строг режим е нова функция в ECMAScript 5, която ви позволява да поставите програма или функция в "строг" работен контекст. Този строг контекст предотвратява предприемането на определени действия и поставя повече изключения.

И още:

Строгият режим помага по няколко начина:

  • Той улавя някои обикновени кодиращи гърмежи, хвърляйки изключения.
  • Той предотвратява или създава грешки, когато се предприемат относително "опасни" действия (например, получаване на достъп до глобален обект).
  • Това забранява функции, които са объркани или лошо обмислени.

Също така имайте предвид, че можете да приложите "строг режим" към целия файл ... Или можете да го използвате само за определена функция (все още цитирайки статията на John Resig):

 // Non-strict code... (function(){ "use strict"; // Define your library strictly... })(); // Non-strict code... 

Какво може да е полезно, ако трябва да смесите стария и новия код ;-)

Така че предполагам, че е малко като "use strict" можете да използвате в Perl (оттук и името?): Помага ви да правите по-малко грешки, като откривате още неща, които могат да доведат до аварии.

В момента тя се поддържа от всички основни браузъри (IE 9 панел и по-долу).

4587
26 авг. отговорът е даден от Pascal MARTIN 26 август. 2009-08-26 19:15 '09 в 19:15 2009-08-26 19:15

Това е нова характеристика на ECMAScript 5. John Resig написа добро резюме .

Това е само ред, който поставяте във вашите JavaScript файлове (или в горната част на файла, или във функция), който изглежда така:

border=0
 "use strict"; 

Активирането на този код вече не трябва да създава проблеми с настоящите браузъри, тъй като това е само низ. Това може да доведе до проблеми с кода в бъдеще, ако кодът прекъсне прагма. Например, ако в момента имате foo = "bar" без първо да дефинирате foo , вашият код ще се срине ... което според мен е добро.

1152
26 авг. отговорът е даден сет 26 авг. 2009-08-26 19:14 '09 в 19:14 2009-08-26 19:14

Изявлението "use strict"; инструктира браузъра да използва Strict режим, който е намален и по-сигурен набор от JavaScript функции.

Списък на функциите (неизчерпателен)

  1. Забранява глобални променливи. (Премахва липсващите декларации и грешки при имена на променливи)

  2. Тихите неуспешни задачи ще доведат до грешка в строг режим (присвояване на NaN = 5; )

  3. Опитите за премахване на отказоустойчиви свойства ще доведат до ( delete Object.prototype )

  4. Изисква всички имена на свойства в обекта да бъдат уникални ( var x = {x1: "1", x1: "2"} )

  5. Имената на функционалните параметри трябва да са уникални ( function sum (x, x) {...} )

  6. Забранява - осмичен синтаксис ( var x = 023; някои разработчици погрешно смятат, че предишната нула не прави нищо, за да промени броя.)

  7. Забраняващ with ключова дума

  8. eval в строг режим не въвежда нови променливи

  9. Деактивиране на простото изтриване на име ( delete x; )

  10. Деактивиране на свързването или именуването на eval и arguments под всякаква форма

  11. Строг режим не поддържа свойствата на обекта arguments с формални параметри. (т.е. във function sum (a,b) { return arguments[0] + b;} Това работи, защото arguments[0] са свързани с a и т.н.)

  12. arguments.callee не се поддържа

[Връзка: Строг режим , Mozilla Developer Network]

567
25 нояб. отговорът е даден от gprasant 25 ноември. 2014-11-25 00:22 '14 в 0:22 2014-11-25 00:22

Ако хората са загрижени за use strict можете да проверите тази статия:

Поддръжка на ECMAScript 5 Strict Mode в браузъри. Какво означава това?
NovoGeek.com - Блогът на Кришна

Той говори за поддръжката на браузъра, но по-важното е как да се справя с нея:

 function isStrictMode(){ return !this; }  function isStrictMode(){ "use strict"; return !this; }  
385
16 июля '12 в 2:25 2012-07-16 02:25 Отговорът е даден от Jamie Hutber 16 юли, '12 в 2:25 ч. 2012-07-16 02:25

Дума на предпазливост, всичко, което програмирате с твърдо зареждане: прилагането на "use strict" към съществуващия код може да бъде опасно! Това нещо не е някакъв хубав, щастлив стикер, който можете да напишете върху кода, за да го направите "по-добър". С "use strict" правилни "use strict" правни "use strict" прагми, браузърът внезапно хвърля изключения в произволни места, които никога преди не е хвърлял, просто защото на това място правите това, което JavaScript позволява по подразбиране / безплатно, но не като строг JavaScript ! Може да имате строги нарушения, които са скрити в рядко използвани повиквания към кода ви, което ще генерира изключение само когато те са в крайна сметка - например в производствена среда, която ползват клиентите за плащане!

Ако ще предприемете решителна стъпка, препоръчваме да използвате "use strict" заедно с цялостни тестове на единици и строго конфигурираната JSHint задача за изграждане, която ще ви даде увереност, че няма тъмен ъгъл на модула, който да експлодира зле, защото сте включили строг режим. Или, хей, ето друг вариант: просто не добавяйте "use strict" на някой от остарелите си кодове, това вероятно е по-безопасно, честно. ОПРЕДЕЛЕНО НЕ добавяйте "use strict" за всички модули, които не притежавате или поддържате, като например модули на трети страни.

Мисля, че дори и да е смъртоносен стомах в клетка, "use strict" може да е добре, но трябва да го направите както трябва. Най-доброто време за строг е, когато вашият проект е нов и започнете от нулата. Настройте JSHint/JSLint с всички предупреждения и опции, сгънати толкова силно, колкото екипът ви може да избледнее, за да получите добра система за изграждане / тестване / одобрение, която може да бъде конфигурирана като Grunt+Karma+Chai , и само THEN ще маркира всичките ви нови модули като "use strict" . Бъдете готови да излекувате много грешки и предупреждения. Уверете се, че всеки разбира гравитацията, като настрои устройството на FAIL, ако JSHint/JSLint причини някакви нередности.

Проектът ми не беше нов проект, когато възприех "use strict" . В резултат на това моята IDE е пълна с червени знаци, защото не "use strict" striming "use strict" на половината от модулите си и JSHint се оплаква от това. Това ми напомня какво трябва да направя в бъдеще. Моята цел е да бъда червена марка безплатно, заради всичките ми липсващи "use strict" изявления, но това е било от много години.

193
03 марта '14 в 10:37 2014-03-03 10:37 Отговорът е даден от DWoldrich на 03.03.2014 в 10:37 2014-03-03 10:37

Използвайте 'use strict'; не прави кода по-добър.

Строг режим на JavaScript е функция в ECMAScript 5 . Можете да разрешите строг режим, като го обявите в горната част на скрипта / функцията.

 'use strict'; 

Когато JavaScript механизмът види тази директива, тя ще започне да интерпретира кода в специален режим. В този режим възникват грешки, когато се открият някои методи на кодиране, които могат да бъдат потенциални грешки (което е аргумент в полза на строг режим).

Разгледайте този пример:

 var a = 365; var b = 030; 

В своята мания за изграждане на числови литерали, разработчикът по невнимание инициализира променливата b осмо литерал. Не-строг режим ще интерпретира това като цифров литерал със стойност 24 (в база 10). Въпреки това, строг режим ще предизвика грешка.

За неизчерпателен списък на специалитети в строг режим вижте Този отговор .


Къде трябва да използвам 'use strict'; ?

  • В новия ми javascript приложение: Абсолютно! Строг режим може да се използва като информатор, когато правите нещо глупаво с вашия код.

  • В моя съществуващ javascript код: Вероятно не! Ако вашият съществуващ JavaScript код съдържа инструкции, които са забранени в строг режим, приложението просто ще прекъсне. Ако имате нужда от строг режим, трябва да сте готови за отстраняване на грешки и да коригирате съществуващ код. Ето защо използването на 'use strict'; не прави кода по-добър.


Как да се използва строг режим?

  1. Вмъкнете 'use strict'; в горната част на скрипта си:

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

    Моля, имайте предвид, че всичко в myscript.js ще се интерпретира в строг режим.

  2. Или поставете 'use strict'; Изявлението над функциите на тялото ви:

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

    Всичко в лексикалния обхват на функцията doSomething ще се интерпретира в строг режим. Лексиката на думата е важна тук. Вижте този отговор за по-добро обяснение.


Какви неща са строго забранени?

Намерих добра статия, описваща няколко неща, които са строго забранени (имайте предвид, че това не е изключителен списък):

обем

Исторически, JavaScript е объркан за това как са покрити функциите. Понякога те изглеждат статично заловени, но някои функции ги принуждават да се държат така, сякаш динамично са обхванати от даден регион. Това е объркващо, което прави програмите за четене и разбиране трудни. Неразбирането причинява грешки. Това също е проблем с производителността. Дефинирането на статичен домейн би позволило променливо обвързване при компилационно време, но изискването за динамичен домейн означава, че свързването трябва да бъде отложено до времето на изпълнение, което е свързано със значително намаляване на производителността.

Строг режим изисква всички свързвания на променливи да бъдат статично изпълнени. Това означава, че функциите, които са изисквали преди това динамично свързване, трябва да бъдат елиминирани или модифицирани. По-специално, операторът с е изключен и способността на eval-функциите да се намесва в средата на повикващия е строго ограничена.

Едно от предимствата на стриктния код е, че инструменти като YUI Compressor могат да работят по-добре при обработката им.

Обяснени глобални променливи

JavaScript предполага глобални променливи. Ако не декларирате изрично променлива, глобалната променлива се имплицитно обявява за вас. Това опростява програмирането за начинаещи, тъй като те могат да пренебрегнат някои от основните им бизнес задачи. Това обаче затруднява управлението на по-големи програми и значително намалява надеждността. По този начин, в строг режим, подразбиращите се глобални променливи вече не се създават. Трябва изрично да декларирате всичките си променливи.

Глобални течове

Има редица ситуации, които могат да причинят this бъде свързано с глобален обект. Например, ако сте забравили да предоставите new префикса, когато извиквате конструктор, this конструкция ще бъде неочаквано свързана с глобален обект, така че вместо да инициализирате нов обект, вместо това той мълчаливо ще фалшифицира с глобални променливи. В тези ситуации строгият режим вместо това свързва this с undefined , което кара конструктора да хвърли изключение вместо това, което му позволява да открие грешката по-рано.

Шумна грешка

JavaScript винаги имаше свойства само за четене, но не можете да ги създадете сами, докато функцията Object.createProperty е отворена за Object.createProperty функцията Object.createProperty . Ако се опитате да присвоите стойност на свойство само за четене, то ще се провали. Присвояването няма да промени стойността на имота, но програмата ви ще действа така. Това е опасност от почтеност, която може да доведе до преход на програми в непоследователно състояние. В строг режим опитът за промяна на свойството само за четене ще доведе до изключение.

осмична

8-битовото представяне на числата беше изключително полезно, когато се извършва машинно програмиране на машини, чийто размер на думата е кратен на 3. Когато се работи с мейнфрейм CDC 6600, който има размер на думата от 60 бита, се нуждаеше от осмично число. Ако можете да прочетете осмичната, можете да погледнете думата като 20 цифри. Две цифри представляват операционния код, а една цифра идентифицира един от 8-те регистъра. По време на бавния преход от машинни кодове към езици на високо ниво, беше счетено за полезно да се осигурят осмични форми в езиците за програмиране.

В C беше избрана изключително жалко идеята за окталността: водещата нула. Така в C 0100 означава 64, а не 100, а 08 е грешка, а не 8. Още повече, за съжаление, този анахронизъм беше копиран на почти всички съвременни езици, включително JavaScript, където се използва само за създаване на грешки. Това няма друга цел. По този начин, в строг режим, осмичните форми вече не са позволени.

И така нататък

Аргументите на псевдо масив стават малко повече като масиви в ES5. В строг режим тя губи callee и caller свойства. Това ви позволява да предавате arguments ненадежден код, без да оставяте много конфиденциален контекст. В допълнение, arguments собственост на функции се изключва.

В строг режим дублиращите се ключове в литерала на функциите дават синтактична грешка. Не може да функционира има два параметъра със същото име. Не може да функционира има променлива със същото име като един от нейните параметри. Функцията не може да delete има свои променливи. Опитите за delete свойство, което не може да се конфигурира, сега поставя изключение. Примитивните стойности не са имплицитно опаковани.


Запазени думи за бъдещи версии на javascript

ECMAScript 5 добавя списък със запазени думи. Ако ги използвате като променливи или аргументи, строгия режим ще генерира грешка. Запазени думи:

implements , interface , let , package , private , protected , public , static и yield


Допълнително четене

144
29 янв. отговор, даден от sampathsris 29 януари 2016-01-29 14:35 '16 в 14:35 2016-01-29 14:35

Силно препоръчвам на всички разработчици да започнат да използват строг режим. Има достатъчно браузъри, които го поддържат, че стриктният режим ще ни помогне да спасим грешките, които дори не сме знаели, че са в кода ви.

Очевидно в началния етап ще има грешки, които никога преди не сме срещали. За да извлечем максимална полза, трябва да извършим правилно тестване след преминаването към строг режим, за да сме сигурни, че всички сме уловени. Определено просто не use strict в нашия код и вярваме, че няма грешки. Така, че е време да започнем да използваме тази невероятно полезна езикова функция, за да пишем по-добър код.

Например

 var person = { name : 'xyz', position : 'abc', fullname : function () { "use strict"; return this.name; } }; 

JSLint е дебъгер, написан от Дъглас Крокфорд. Просто го поставете в скрипта си и бързо сканира за забележими проблеми и грешки в кода ви.

128
05 июля '13 в 22:38 2013-07-05 22:38 отговорът е даден на Pank на 05 юли'13 в 10:38 2013-07-05 22:38

Бих искал да предложа малко по-обоснован отговор, който допълва другите отговори. Надявах се да редактирам най-популярния отговор, но не можах. Опитах се да го направя възможно най-пълна и пълна.

За повече информация можете да се обърнете към документацията на MDN .

Директивата "use strict" въведена в ECMAScript 5.

Директивите са като изявления, но различни.

  • use strict не съдържа ключови думи: директива е проста операция на израз, която се състои от специален символен низ (в единични или двойни кавички). Двигателите на JavaScript, които не прилагат ECMAScript 5, просто виждат израза без странични ефекти. Очаква се бъдещите версии на стандартите ECMAScript да въведат use като истинска ключова дума; По този начин котировките ще остареят.
  • use strict може да се използва само в началото на скрипт или функция, т.е. трябва да предхожда всяко друго (реално) изявление. Това не трябва да бъде първата инструкция в функционалния скрипт: тя може да бъде предшествана от други операторни изрази, които се състоят от низови литерали (и JavaScript изпълненията могат да се разглеждат като директиви, специфични за изпълнението). Струнните литерали, които следват първия реален оператор (в скрипт или функция), са прости изрази. Преводачите не трябва да ги тълкуват като директиви и нямат ефект.

use strict директивата use strict посочва, че следният код (в скрипт или функция) е строг код. Кодът на най-високото ниво на скрипта (код, който не е във функцията) се счита за строг код, когато скриптът съдържа use strict use strict директивата за use strict . Съдържанието на дадена функция се счита за строг код, когато самата функция е дефинирана в строг код или когато функцията съдържа use strict . Кодът, предаван на метода eval() , се счита за строг код, когато eval() се извиква от низ код или съдържа use strict директива.

Строг режим на ECMAScript 5 е ограничен подгрупа на езика на JavaScript, който елиминира съответните езикови недостатъци и осигурява по-строга проверка на грешките и повишена сигурност. По-долу са разликите между строг режим и нормален режим (от които първите три са особено важни):

  • Не можете да го използвате with изречение в строг режим.
  • В строг режим всички променливи трябва да бъдат декларирани: ако присвоите стойност на идентификатор, който не е деклариран като променлива, функция, параметър на функция, параметър catch-clause или глобално свойство Object , тогава ще получите ReferenceError . В нормален режим идентификаторът се обявява косвено като глобална променлива (като свойство на глобален Object )
  • В строг режим, this има функциите, undefined като стойност, които са били извикани като функции (а не като методи). (В нормален режим this винаги означава глобален Object ). Это различие можно использовать для проверки, поддерживает ли реализация строгий режим:
 var hasStrictMode = (function() { "use strict"; return this===undefined }()); 
  • Также, когда функция вызывается с call() или apply в строгом режиме, this точно значение первого аргумента call() или apply() . (В нормальном режиме null и undefined заменяются глобальным Object а значения, которые не являются объектами, преобразуются в объекты.)

  • В строгом режиме вы получите TypeError , когда вы пытаетесь назначить свойства readonly или определить новые свойства для не растяжимого объекта. (В обычном режиме оба просто обходятся без сообщения об ошибке.)

  • В строгом режиме при передаче кода в eval() вы не можете объявлять или определять переменные или функции в области вызывающего (как это можно сделать в обычном режиме). Вместо этого для eval() создается новая область, и переменные и функции находятся в пределах этой области. Эта область уничтожается после того, как eval() завершает выполнение.
  • В строгом режиме аргумент-объект функции содержит статическую копию значений, которые передаются этой функции. В нормальном режиме аргумент-объект имеет несколько "магическое" поведение: элементы массива и именованные функциональные параметры ссылаются на одно и то же значение.
  • В строгом режиме вы получите SyntaxError когда за оператором delete следует неквалифицированный идентификатор (переменная, функция или параметр функции). В нормальном режиме выражение delete ничего не сделает и будет оценено как false .
  • В строгом режиме вы получите TypeError при попытке удалить неконфигурируемое свойство. (В обычном режиме попытка просто терпит неудачу, а выражение delete - false ).
  • В строгом режиме это считается синтаксической ошибкой при попытке определить несколько свойств с тем же именем для литерала объекта. (В нормальном режиме ошибки нет.)
  • В строгом режиме это считается синтаксической ошибкой, когда объявление функции имеет несколько параметров с тем же именем. (В нормальном режиме ошибки нет.)
  • В строгом режиме не допускаются восьмеричные литералы (это литералы, начинающиеся с 0x . (В нормальном режиме некоторые реализации позволяют делать восьмеричные литералы).
  • В строгом режиме идентификаторы eval и arguments обрабатываются как ключевые слова. Вы не можете изменить их значение, не можете присвоить им значение, и вы не можете использовать их в качестве имен для переменных, функций, параметров функций или идентификаторов блока catch.
  • В строгом режиме больше ограничений на возможности проверки стека вызовов. arguments.caller и arguments.callee вызывают TypeError в функции в строгом режиме. Кроме того, некоторые свойства caller- и аргументы функций в строгом режиме вызывают TypeError при попытке их прочитать.
88
ответ дан Ely 15 мая '15 в 9:58 2015-05-15 09:58