Mengapa pergeseran terbaru untuk menghapus / menghilangkan titik koma dari Javascript?


80

Tampaknya baru-baru ini fashionable untuk menghilangkan titik koma dari Javascript. Ada posting blog beberapa tahun yang lalu yang menekankan bahwa dalam Javascript, titik koma adalah opsional dan inti dari postingan tersebut adalah bahwa Anda tidak boleh repot-repot dengan mereka karena mereka tidak perlu. Posting tersebut, dikutip secara luas, tidak memberikan alasan kuat untuk tidak menggunakannya, hanya saja meninggalkannya memiliki beberapa efek samping.

Bahkan GitHub telah melompat pada kereta musik no-titik koma, membutuhkan penghilangan mereka dalam kode yang dikembangkan secara internal, dan komitmen baru - baru ini untuk proyek zepto.js oleh pengelolanya telah menghapus semua titik koma dari basis kode. Pembenaran utamanya adalah:

  • ini masalah pilihan timnya;
  • kurang mengetik

Apakah ada alasan bagus lainnya untuk tidak melakukannya?

Terus terang saya tidak melihat alasan untuk menghilangkannya, dan tentu saja tidak ada alasan untuk kembali kode untuk menghapusnya. Ini juga bertentangan dengan ( tahun ) praktik yang disarankan , yang saya tidak benar-benar beli dengan argumen "pemujaan kargo". Jadi, mengapa semua titik koma-benci baru-baru ini? Apakah ada kekurangan yang menjulang? Atau ini hanya tren Javascript terbaru?


2
"tahun-tahun praktik yang direkomendasikan" merujuk pertanyaan tentang taging jajak pendapat SO yang dimasukkan ke dalam daftar hitam yang tidak mungkin membuatnya otoritatif untuk mendukung segala jenis pendapat
nyamuk

24
@gnat hanya karena orang membenci pertanyaan yang ada di SO tidak menjadikannya sumber pendapat orang yang kurang valid.
Ryathal

3
@gnat Pertanyaan yang "secara resmi dianggap tidak tepat di StackOverflow" terkadang dianggap sangat otoritatif oleh komunitas pakar. Sedih tapi benar.
MarkJ

4
@gnat Pertanyaan yang dimasukkan dalam daftar hitam sebenarnya memiliki beberapa contoh yang sangat menarik tentang mengapa menghilangkan kode ;dapat rusak. Jadi saya katakan itu referensi yang berguna untuk pertanyaan ini.
Andres F.

1
Ini mungkin terkait dengan meningkatnya popularitas hipsters di awal 2010-an.
Alex

Jawaban:


62

Saya kira alasan saya adalah yang paling lama: Saya memprogram dalam banyak bahasa yang berbeda secara bersamaan (Java, Javascript, PHP) - yang membutuhkan ';' jadi daripada melatih jari dan mata saya bahwa ';' tidak diperlukan untuk javascript, saya hanya selalu menambahkan ';'

Alasan lainnya adalah dokumentasi: dengan menambahkan ';' Saya secara eksplisit menyatakan pada diri sendiri di mana saya mengharapkan pernyataan itu berakhir. Kemudian lagi saya menggunakan {} sepanjang waktu juga.

Seluruh argumen jumlah byte yang saya rasa menjengkelkan dan tidak berguna:

1) untuk perpustakaan umum seperti jquery: gunakan google CDN dan perpustakaan mungkin sudah ada dalam cache browser

2) versi perpustakaan Anda sendiri dan mengaturnya untuk di-cache selamanya.

3) gzip dan kecilkan jika benar-benar diperlukan.

Tapi benarkah berapa banyak situs yang memiliki kecepatan terbesar sebagai penghambat kecepatan unduhan javascript mereka? Jika Anda bekerja untuk 100 situs teratas seperti twitter, google, yahoo, dll. Mungkin. Kita semua hanya perlu khawatir tentang kualitas kode bukan perang agama titik koma.


3
Saya kira yang sebaliknya juga bisa benar. Karena python menjadi lebih populer untuk web, JS Anda lebih mudah menyerupai python.
Ben DeMott

4
Coba tetapi kemudian prajurit byte yang sama akan mengejar saya untuk ruang kosong yang tidak perlu di awal baris. (Saya juga akan memiliki bug Javascript karena saya akan bergantung pada aturan indentasi Python daripada menggunakan {}
Pat

6
Jika mengurangi jumlah byte adalah penting, Anda akan memiliki sesuatu yang meminimalkan file sebanyak mungkin. Jika belum layak menggunakan minimizer, maka tidak ada gunanya khawatir menghapus ';' untuk menghemat jumlah byte.
Lawtonfogle

3
jumlah byte sebenarnya tidak perlu dikurangi, pada kenyataannya itu sebenarnya dapat ditingkatkan karena baris baru sering (tidak selalu) sebenarnya dua karakter (baris baru diikuti oleh carriage-return) sehingga dalam sebagian besar ruang efisien bentuk baru baris akan menjadi karakter yang sama dengan semi-kolon satu karakter (jika Anda memadatkan semua kode JS Anda dalam satu baris yang sering dilakukan untuk kode JS yang digunakan, bukan kode sumber pengembangan).
ALXGTV

Manusia membutuhkan lekukan untuk memahami sarang yang dalam, yang membutuhkan lebih banyak byte daripada titik koma. Namun, titik koma adalah limbah penekanan tombol yang mengganggu.
Cees Timmerman

39

Itu membuat metode chaining lebih mudah dan melakukan diffs lebih bersih

Jadi katakanlah saya bertanya tentang dan saya punya

$('some fancy selector')
  .addClass()
  .attr();

Jika saya ingin menambahkan barang - barang dan menjaga komit berbasis baris saya kecil , saya harus menambahkannya di atas attr. Jadi itu satu pemikiran lebih lama dari sekedar "tambahkan di akhir". Dan siapa yang mau berpikir? =)

$('some fancy selector')
  .addClass()
  // new method calls must go here
  .attr();

Tapi, ketika saya menjatuhkan titik koma, saya bisa menambahkan dan menyebutnya sehari

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate()
+   .click()

Juga, jika saya memutuskan untuk menghapus metode terakhir, saya tidak perlu menetapkan kembali semi-colon dan mencemari komit saya lagi.

  $('some fancy selector')
    .addClass()
    .attr()
    .animate()
-   .click()

Lawan uggo

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate();
-   .animate()
-   .click();

37
Ini adalah niche use case IMO.
JBRWilkinson

9
Namun tetap menarik.
Jonathan

8
Anda dapat memiliki titik koma di bagian akhir pada baris baru yang diberi indentasi sebagai garis awal. Kemudian Anda menyalin dan menyusun ulang hal-hal yang Anda inginkan. Ini juga menutup rantai dengan baik.
Nux

11
Apakah hanya saya yang bertanya-tanya mengapa ada orang yang peduli betapa rapi perbedaan komitmen mereka? sebagai aturan umum, orang membaca kode, bukan diffs.
Jules

11
@ Jules, cleaner diffs berarti penggabungan lebih mungkin berhasil.
joeytwiddle

22

semi-titik dua dalam JavaScript adalah opsional

Alasan pribadi saya untuk tidak menggunakan titik koma adalah OCD.

Ketika saya menggunakan titik dua, saya lupa 2% dari mereka dan harus terus-menerus memeriksa / menambahkannya kembali.

Ketika saya tidak menggunakan titik koma saya tidak pernah sengaja memasukkannya jadi saya tidak perlu memeriksa / menghapusnya.


3
Bagus Saya telah dibakar oleh satu atau dua baris titik koma di file semicoloned yang dinyatakan benar.
Jonathan

3
Ada parser (mis. GeSHi) yang tidak akan mem-parsing kode Anda dengan benar jika titik koma tidak ada. Anda bisa mengatakan bahwa manusia tidak akan membuat kesalahan seperti itu ... Tapi serius - acara jika semua tim Anda akan berhasil mengingat di mana titik koma benar-benar perlu diletakkan, apakah Anda benar-benar berpikir mereka akan mengingatnya tanpa kopi pagi? Dan mereka akan kode di banyak negara pikiran. Pastikan itu.
Nux

16

Baru-baru ini saya menulis parser / analyzer untuk JavaScript, di mana saya harus menerapkan ASI dengan susah payah, dan saya juga memiliki salinan Crockford's JavaScript: The Good Parts di rak buku saya, yang selalu dianjurkan menggunakan titik koma. Niatnya baik, tetapi tidak selalu membantu dalam praktik.

Jelas, orang-orang yang menulis kerangka kerja seperti jQuery, zepto, dll. Adalah master sintaksis JavaScript dan karenanya mereka tahu perbedaan antara:

return
{
    status: true
};

dan

return {
    status: true
};

JavaScript, walaupun kuat, juga merupakan bahasa pemula dan keberuntungan menjelaskan hal ini kepada seseorang yang baru belajar apa itu forloop. Seperti memperkenalkan kebanyakan orang pada keterampilan baru, ada beberapa hal yang lebih rumit yang tidak ingin Anda jelaskan segera, jadi alih-alih Anda memilih menanamkan kepercayaan "kultus kargo" pada hal-hal tertentu hanya untuk membuat mereka keluar dari lapangan. Jadi, Anda memiliki dua pilihan saat mengajar pemula cara menulis JavaScript:

  1. Katakan kepada mereka "mengikuti aturan yang satu ini dan tidak bertanya mengapa", memberitahu mereka untuk menempatkan selalu titik koma pada akhir setiap baris. Sayangnya, ini tidak membantu dalam contoh di atas, atau contoh lain di mana ASI menghalangi. Dan Mr. atau Ms. programmer pemula menjadi bingung ketika kode di atas gagal.
  2. Beri tahu mereka "ikuti dua aturan ini dan jangan tanya kenapa", beri tahu mereka untuk tidak repot dengan titik koma di akhir setiap baris, dan sebaliknya selalu a) Ikuti returndengan a {, dan b) Ketika sebuah baris dimulai dengan a (, tambahkan dengan ;.

Memilih opsi 2 adalah seperangkat aturan "kultus kargo" yang lebih baik untuk diikuti (akan menghasilkan sangat sedikit bug terkait ASI), dan bahkan jika Anda benar-benar memahami topik ini, Anda memiliki lebih sedikit karakter yang tidak dibutuhkan di layar.


8
Baiklah, saya akan gigit. Bantu saya memahami perbedaan dalam sintaks antara dua contoh di atas. Mata saya yang tidak terlatih hanya melihat perbedaan dalam format.
Jesse C. Slicer

9
Atau, di sisi lain, saya menemukan jawaban karena kecelakaan belaka. Dalam contoh pertama, returndianggap sebagai pernyataan soliter dan garis-akhir adalah setara dengan titik koma. Contoh kedua sebenarnya mengembalikan objek. Berdandan.
Jesse C. Slicer

9
Saya rasa saya tidak bisa setuju dengan gagasan bahwa JavaScript adalah bahasa pemula, ada banyak ketidakkonsistenan dan efek kejutan dalam JavaScript yang tidak memiliki penjelasan sederhana. IMO bahasa pemula tidak akan seperti itu, saya akan menyebut JavaScript sebagai bahasa perantara.
Ryathal

2
@Ryathal Saya mengerti apa yang Anda maksud, tetapi menyebutnya sebagai bahasa perantara membuat saya bertanya-tanya dalam bahasa apa ia menjadi perantara. Anda membuatnya terdengar seolah-olah itu adalah langkah dalam perjalanan ke sesuatu yang lain daripada tujuan itu sendiri.
Racheet

9
Titik klarifikasi: returncontoh ini sebenarnya merupakan pengecualian untuk perilaku JS normal yang mencoba untuk menarik garis bersama ketika titik koma dihilangkan. return,, breakdan continuesemua menunjukkan perilaku luar biasa ini di mana baris baru yang tertinggal selalu ditafsirkan sebagai akhir dari pernyataan. (Sumber adalah "JavaScript: The Definitive Guide" dari Flanagan hlm. 25-26). Secara pribadi, saya mengusahakan ide "kode kejutan paling tidak." Meninggalkan semi-titik dua cenderung menghasilkan lebih banyak kejutan daripada apa pun (saya umumnya juga menjaga kurung kurawal saya bahkan untuk pernyataan sederhana).
Kyle

16

Tidak ada informasi yang berlebihan, hanya desain yang buruk.

- Edward Tufte

Ini adalah aturan umum dalam desain grafis untuk mengabaikan elemen dan ornamen yang tidak perlu untuk mengurangi kebisingan.

Lebih sedikit elemen visual pada layar berarti lebih sedikit kerja untuk otak kita untuk mengurai informasi berguna yang sebenarnya.

let foo = 1

vs.

let /* variable */ foo = 1; // EOL

Contoh berlebihan tentu saja, tetapi menggambarkan prinsip umum: Elemen visual tambahan harus ditambahkan jika dan hanya jika mereka melayani tujuan. Jadi, apakah titik koma memiliki tujuan?

Alasan historis untuk menggunakan titik koma dalam JavaScript adalah:

  • Pertahankan kesamaan dengan C / Java
  • Hindari masalah kompatibilitas dengan browser dan alat yang ditulis dengan buruk
  • Membantu manusia dan mesin mendeteksi kesalahan kode
  • Penyisipan Titik Koma Otomatis membawa penalti kinerja

Masalah kompatibilitas tidak menjadi masalah saat ini. Linter modern dapat mendeteksi kesalahan kode sama baiknya tanpa titik koma. Kemiripan dengan C / Java / PHP masih bisa menjadi pertimbangan (lihat jawaban yang diterima oleh Pat), tetapi hanya karena bahasa lain mengandung elemen sintaks yang berlebihan tidak berarti kita harus menyimpannya dalam JavaScript, terutama karena banyak bahasa lain (Coffeescript, Python, Ruby, Scala, Lua) tidak memerlukannya.

Saya melakukan tes cepat untuk melihat apakah ada penalti performa di V8. Ini adalah Io.js mem-parsing file JavaScript 41 MB (Lodash diulang 100 kali) dengan titik koma dan kemudian dengan titik koma dihapus:

$ time node lodashx100.js
node lodashx100.js  2.34s user 1.30s system 99% cpu 3.664 total
$ time node lodashx100s.js
node lodashx100s.js  2.34s user 1.15s system 99% cpu 3.521 total

Setiap orang harus memutuskan gaya pengkodean pilihan mereka sendiri untuk proyek mereka, tetapi saya tidak lagi melihat manfaat nyata dalam menggunakan titik koma, jadi untuk mengurangi kebisingan visual, saya sudah berhenti.


Saya akan melawan argumen ini dengan mengabaikan elemen-elemen yang tidak perlu di dalam load yang sekarang harus dilakukan pikiran untuk menambahkan kembali dalam sintaksis opsional. Sekarang titik koma bukanlah tekanan mental yang besar jika dihilangkan. Ini adalah masalah yang saya alami dengan Ruby dan Scala. Ketika itu menjadi rantai panggilan dengan panggilan di dalam panggilan, dan mereka semua dihilangkan setiap paren, itu adalah beban untuk memisahkan.
Seamus

8

Memilih konvensi pemrograman sama efektifnya dengan memilih subset dari bahasa target. Kita semua melakukan ini karena alasan biasa: keterbacaan kode, pemeliharaan, stabilitas, portabilitas, dll - sambil berpotensi mengorbankan fleksibilitas. Alasan-alasan ini adalah alasan bisnis yang nyata.

Alasan seperti "menghemat penekanan tombol," dan "programmer harus mempelajari aturan JavaScript" adalah alasan bisnis marjinal sehingga hanya sedikit membawa beban praktis.

Dalam kasus saya, saya harus mempercepat JavaScript dengan sangat cepat, jadi memanfaatkan sebagian bahasa secara terbatas adalah keuntungan saya. Jadi saya memilih subset JSLint dari JavaScript, mengaktifkan aplikasi Rockstar JSLinter di Eclipse ke pengaturan paling restriktif yang bisa saya tahan, dan belum melihat ke belakang.

Saya bersyukur bisa menghindari detail perbedaan antara "==" dan "===", atau detail penyisipan titik koma, karena saya sudah punya mil daftar tugas yang tinggi dan detail-detail itu tidak akan bantu menyelesaikan pekerjaan itu satu detik sebelumnya.

Tentu saja hal yang paling penting tentang sebuah konvensi adalah konsistensi, dan menganggapnya sebagai bagian bahasa membantu memperkuat keharusan ini. Dan meskipun ini mungkin tidak membantu menjawab pertanyaan OP, saya pikir mungkin membantu dengan pembingkaian praktisnya.


5

Pertanyaan yang cukup lama, namun saya terkejut tidak ada yang menyebutkan:

Minifikasi: Jika Anda memotong minifikan JavaScript yang tidak secara eksplisit mengakhiri pernyataan dengan karakter semi-kolon, Anda mungkin akan kesulitan mencari tahu apa yang salah dengan snippet yang baru berfungsi sebelum minifikasi dan sekarang tidak berfungsi.

Ambiguitas: Semi-titik dua adalah opsional, benar, namun dengan menghilangkannya dari kode sumber, Anda mungkin meninggalkan beberapa skenario ambigu ke parser untuk memutuskan sendiri. Jika Anda menulis 100 baris kode untuk toko online, ya, mungkin itu tidak masalah, tetapi tugas yang lebih serius akan membutuhkan kejelasan 100%.

Dahulu kala saya membaca analogi yang sangat bagus tentang sesuatu yang lain tetapi sangat benar dalam kasus ini juga: (Dalam kasus kami) Menghilangkan semi-titik dua sama seperti menyeberang di lampu merah. Anda mungkin baik-baik saja pada akhirnya atau Anda mungkin tertabrak truk.

Mengapa hari ini menjadi lebih populer?

Saya pribadi percaya bahwa menjalankan JavaScript di sisi server memiliki banyak efek pada komunitas JavaScript itu sendiri. Dalam kasus kami, jelas tidak ada yang akan mengecilkan JavaScript di sisi server (karena kode sumber tidak seharusnya dikirimkan ke browser web klien), jadi tanpa semi-titik tampak jauh lebih aman yang benar; namun pengembang lain yang belajar dari buku, artikel, dan video ini, sayangnya mereka mengabaikan fakta bahwa JavaScript di sisi server tidak persis sama dengan JavaScript di sisi klien.


Minifier dapat meninggalkan baris baru karakter tunggal atau menyisipkan semi-titik dua ketika semi-titik dua tidak hadir tanpa penalti ukuran. Saya tidak tahu minifiers mana (jika ada) yang melakukan ini. Bahayanya masih ada di setidaknya beberapa dari mereka, jadi poin Anda masih berlaku dalam praktek.
outis

3

Ada alasan bagus untuk menyimpannya.

Mereka tidak benar-benar opsional, JS dapat menambahkannya kembali dengan penyisipan titik koma otomatis ketika mereka hilang tetapi itu bukan hal yang sama.

JavaScript Douglas Crockford: The Good Parts mengatakan pada dua kesempatan terpisah bahwa itu adalah ide yang buruk. Penyisipan titik koma otomatis dapat menyembunyikan bug di program Anda dan menciptakan ambiguitas.

JSLint tidak menyetujui.


3

JavaScript tidak membutuhkan semi-titik dua untuk mengakhiri pernyataan dalam lebih dari satu dekade. Itu karena karakter baris baru dianggap sebagai terminator pernyataan (saya percaya ini juga disebutkan dalam spesifikasi ECMAScript awal). Ini benar-benar masuk akal, terutama karena benar-benar tidak ada alasan [mengapa saya tahu] mengapa JavaScript perlu sering menggunakan semi-titik dua tetapi tidak bahasa deklaratif lain yang ditafsirkan seperti Ruby atau Python.

Membutuhkan semi-titik dua dapat membuatnya lebih mudah untuk menulis parser untuk suatu bahasa, tetapi jika setiap penerjemah di luar sana mendukung penghapusan semi-titik dua maka apa gunanya?

Apa yang terjadi adalah seberapa berpengetahuan seorang programmer: jika Anda tahu bahwa Anda dapat menghilangkan titik koma, jangan ragu untuk memahami bahwa mungkin ada atau tidak ada konsekuensinya. Manusia adalah mesin pembuat keputusan dan hampir semua keputusan membutuhkan kompromi atau pertukaran. Pertukaran dengan hanya melemparkan semi-titik dua di sekitar kode Anda (bahkan di tempat-tempat di mana mereka tidak diperlukan) adalah bahwa kode Anda menjadi kurang dapat dibaca (tergantung pada yang Anda tanyakan) dan JSLint tidak akan mengeluh (siapa yang peduli ). Di sisi lain, trade-off untuk menghilangkan semi-titik dua adalah kenyataan bahwa 90% programmer JavaScript akan menghukum Anda untuk itu, tetapi Anda mungkin akhirnya lebih suka menulis JavaScript karena itu.

Apa yang terdengar lebih baik bagi Anda; membuat keputusan berdasarkan informasi atau membuat keputusan secara buta / mentalitas kawanan?


Saya tertarik untuk mengetahui mengapa ini menerima downvotes. JavaScript tidak perlu semi-titik dua untuk mengakhiri pernyataan; itu pasti bisa menggunakannya, tetapi mereka tidak berarti suatu keharusan. Jika dibutuhkan, maka penjelasan orang lain tidak akan berfungsi. Fakta (ya, fakta) bahwa Anda dapat menulis seluruh aplikasi JavaScript dengan sedikit atau tanpa titik koma menunjukkan hal ini. Selain itu, saya tidak melihat bagaimana memahami cara alat bekerja dan menggunakan alasan sendiri untuk membuat keputusan, entah bagaimana, tidak dapat diterima, berbeda dengan "lakukan saja". Itulah yang dikenal sebagai agama.
Ravenstine

Saya tidak downvote, tetapi masalahnya mungkin ini faktanya tidak benar seperti yang tertulis. Baris baru tidak dianggap sebagai terminator pernyataan dalam javascript. Anda dapat meninggalkan titik koma karena fitur yang disebut penyisipan titik koma otomatis yang memungkinkannya untuk memperbaiki kesalahan parse secara otomatis dalam keadaan tertentu. Orang-orang yang menganjurkan titik koma berpendapat bahwa banyak programmer javascript tampaknya kurang memahami aturan ini. Tulisan Anda tampaknya menjadi argumen yang menguntungkan mereka. (Dalam keadilan, saya sebagian besar setuju dengan tesis Anda, tetapi untuk alasan yang berbeda)
Tim Seguine

@TimSeguine Ya, saya menulis ini kembali sebelum saya memiliki pemahaman yang lebih baik. Saya masih tidak berpikir itu salah secara objektif untuk tidak menggunakan titik koma selama orang-orang itu mengerti apa sebenarnya yang mereka lakukan. Saya harus mengerjakan ulang posting saya, atau mungkin menyingkirkannya karena cukup banyak orang lain yang ikut membahas hal ini. Terima kasih atas kritiknya yang sopan! :)
Ravenstine

2

Saya punya dua teori:

SEBUAH)

Hal tentang pilihan ini adalah bahwa pada hari itu, ketika JSLint dll berlaku, Anda memilih untuk menghabiskan banyak waktu menangkap kesalahan sintaksis yang tidak jelas, atau jumlah waktu yang wajar untuk menegakkan kebijakan standar tentang kode.

Namun, ketika kita bergerak lebih ke arah kode Unit- driven tes dan integrasi terus menerus jumlah waktu (dan interaksi manusia) yang diperlukan untuk menangkap kesalahan sintaks telah menurun secara besar-besaran. Umpan balik dari pengujian akan dengan cepat menunjukkan apakah kode Anda berfungsi seperti yang diharapkan, jauh sebelum mendekati pengguna akhir, jadi mengapa membuang waktu menambahkan verbositas opsional?

B)

Pemrogram yang malas akan melakukan apa saja untuk membuat hidup mereka lebih mudah dalam jangka pendek. Kurang mengetik -> kurang usaha -> lebih mudah. (juga, tidak harus titik koma akan menghindari ketegangan jari tangan kanan Anda, menghindari RSIness).

(NB Saya tidak setuju dengan gagasan menghilangkan sesuatu yang merusak pernyataan).


1
jshint masih merupakan alat yang penting.
Raynos

Adapun pernyataan ambigu, keduanya \ndan ;\nsama
Raynos

2
@ Raynos Sebenarnya, saya telah menemukan bahwa JSLint cenderung agak tidak berguna dengan kompleksitas beberapa kode kerangka kerja yang sering saya kerjakan. Plus,; \ n dan \ n tidak sama dalam semua keadaan , jika tidak, tidak akan pernah ada kebutuhan untuk;
Ed James

7
jslint tidak berguna, namun jshint adalah alat yang berbeda.
Raynos

0

Saya tidak meninggalkannya, tetapi saya mengubah aturan kapan memasukkannya.

Aturan yang digunakan kebanyakan orang adalah

  • Sebelum setiap baris berakhir
  • Kecuali garis berakhir dengan }datang dari pernyataan fungsi
  • Tapi hanya pernyataan fungsi, bukan penugasan ke fungsi literal

Aturan saya adalah: Di awal setiap baris dimulai dengan brace pembuka / braket.

Milik saya lebih sederhana, karena itu lebih mudah diikuti dan lebih rentan terhadap bug. Juga rendahnya jumlah titik koma membuatnya mudah untuk menemukan bug yang dibuat dengan meninggalkannya.


Argumen lain adalah bahwa return\nvaluebug terkenal berasal dari tidak mengetahui tentang ASI. Aturan saya memaksa Anda untuk mengetahui tentang ASI, sehingga orang yang menggunakan aturan saya cenderung tidak akan jatuh ke dalam perangkap bug itu.


0

Hitungan Byte. Soalnya, orang jahat biasanya mencoba memasukkan begitu banyak ke dalam satu baris kode. Secara teknis, ini tidak akan mungkin terjadi tanpa semi-titik dua. Anggapan saya adalah bahwa ini lebih merupakan tindakan pengamanan daripada sekadar persyaratan terprogram. Entah bagaimana, ini akan secara signifikan mengurangi XSS ketika itu menjadi persyaratan daripada saran.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.