Rumah  >  Artikel  >  hujung hadapan web  >  Analisis ringkas tentang empat cara biasa untuk menulis pengisytiharan Javascript bagi pembolehubah gelung_Pengetahuan asas

Analisis ringkas tentang empat cara biasa untuk menulis pengisytiharan Javascript bagi pembolehubah gelung_Pengetahuan asas

WBOY
WBOYasal
2016-05-16 15:36:381123semak imbas

Di manakah pengisytiharan pembolehubah gelung dalam Javascript harus diletakkan?

Tabiat 1: Gunakan terus tanpa mengisytiharkan

function loop(arr) { 
 for (i = 0; i < arr.length; i++) { 
  // do something 
 } 
} 

Tabiat penggunaan yang sangat berbahaya Secara amnya, pembolehubah gelung akan menjadi atribut pada objek tetingkap dan digunakan secara global, yang berkemungkinan besar menjejaskan pelaksanaan logik biasa program.
Adalah penting untuk menyebut bahawa dalam mod yang ketat, tugasan langsung tanpa mengisytiharkan pembolehubah akan secara langsung membuang pengecualian Ini sepatutnya dilakukan sejak dahulu lagi! Memetik petikan daripada Lampiran C standard ecma-262:
"Penugasan kepada pengecam yang tidak diisytiharkan atau sebaliknya rujukan yang tidak boleh diselesaikan tidak mencipta sifat dalam objek global. Apabila tugasan mudah berlaku dalam kod mod ketat, LeftHandSidenya tidak boleh menilai kepada Rujukan yang tidak boleh diselesaikan. Jika ia melakukan pengecualian ReferenceError dibuang (6.2 .3.2)."
Dalam erti kata lain, jika pembolehubah yang tidak diisytiharkan digunakan semula, pengecualian ReferenceError akan dilemparkan.

Tabiat 2: Letakkannya di blok pernyataan awal gelung for dan isytiharkan

berulang kali
function loop(arr) { 
 for (var i = 0; i < arr.length; i++ ){ 
  // do someting 
 } 
 // console.log(i); 
 for (var i = 0; i < arr.length; i++ ){ 
  // do something else 
 } 
} 

Kaedah ini nampaknya paling selamat dan paling standard Ramai pelajar yang beralih dari C dan Java kepada pembangunan front-end Malah, ini mungkin disebabkan oleh salah faham konsep penting dalam Javascript. pembolehubah. Tidak seperti C dan Java, Javascript tidak mempunyai skop peringkat blok sebenar, iaitu selepas gelung pertama tamat, console.log(i) tidak akan mencetak tanpa definisi atau membuang pengecualian ReferenceError, tetapi akan menjadi perkara biasa arr.panjang.
Sudah tentu, walaupun cara penulisan ini mempunyai sedikit makna selain daripada cantik, ia telah lama serasi dan tidak melanggar sebarang spesifikasi - standard ecma tidak melarang pengisytiharan berulang pembolehubah yang sama dalam skop tertentu.

Tabiat 3: Tentukan secara berpusat

di bahagian atas fungsi bersama-sama dengan pembolehubah lain
function loop(arr) { 
 var var1; 
 var var2; 
 var i; 
 
 for (i = 0; i < arr.length; i++) { 
  // do something 
 } 
} 

Kaedah definisi pembolehubah seperti c89 ini hampir sempurna dalam Javascript Ia tidak akan menyebabkan salah faham bahawa Javascript menyokong skop peringkat blok, tidak mencemarkan skop global, dan tidak melanggar sebarang piawaian dan spesifikasi Terutamanya pembolehubah gelung dan badan gelung mungkin berjauhan. Tanpa menggunakan lebih banyak kod, nampaknya tiada penyelesaian yang lebih baik untuk masalah ini selain daripada menunggu pengeluar penyemak imbas arus perdana utama untuk melaksanakan kata kunci let dalam ECMAScript 6.

Tabiat 4: Merangkumkan kod gelung ke dalam IIFE

function loop(arr) { 
 (function () { 
  for (var i = 0; i < arr.length; i++) { 
   // do something 
  } 
 })(); 
} 

Kebiasaan terakhir ialah IIFE (Ekspresi Fungsi Segera-Invoked), yang biasa kepada pengaturcara bahagian hadapan, yang bermaksud melaksanakan fungsi dengan segera. Kelemahan utama kaedah ini ialah ia agak menyusahkan untuk menulis dan mempunyai kehilangan prestasi yang tidak perlu (sangat kecil), tetapi ia berfungsi dengan baik dari segi keserasian dan pematuhan dengan pelbagai piawaian. Pembangun boleh mengambil pendekatan ini jika ia tidak terlalu menyusahkan.

Di atas adalah pengenalan ringkas dan analisis tabiat menulis empat definisi pembolehubah gelung biasa dalam Javascript Setiap satu mempunyai kebaikan dan keburukan tersendiri.

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn