Haruskah saya menggunakan validasi JSLint atau JSHint JavaScript? [Tutup]


454

Saat ini saya memvalidasi JavaScript saya terhadap JSLint dan membuat kemajuan, ini membantu saya untuk menulis JavaScript yang lebih baik - khususnya dalam bekerja dengan perpustakaan Jquery.

Saya sekarang menemukan JSHint , garpu JSLint .
Jadi saya bertanya-tanya untuk aplikasi web, yang sangat didorong oleh JavaScript, yang merupakan alat validasi yang lebih baik atau paling dapat diterapkan untuk mengatasi:

  • JSLint atau JSHint?

Saya ingin memutuskan sekarang pada mekanisme validasi dan bergerak maju, gunakan ini untuk validasi sisi klien.

Dan Perbedaan antara jshint dan jslint? Tolong jelaskan dalam contoh javascript tunggal.

Tautan:

  1. jshint - http://www.jshint.com/

  2. jslint - http://jslint.com/


4
Bagaimana dengan ESLint ? Meskipun tidak sempurna: Combine this with the previous 'var' statement-> Do not mix 'require' and other declarations, paradoks.
nyuszika7h



Bukan pengembang JS. Tapi saya menemukan JSHint sangat berguna selama proses peninjauan kode kami. Saya merekomendasikannya.
Chetan Vashistth

Jawaban:


156

[EDIT]
Jawaban ini telah diedit. Saya meninggalkan jawaban asli di bawah ini untuk konteks (jika tidak komentar tidak masuk akal).

Ketika pertanyaan ini awalnya diajukan, JSLint adalah alat linting utama untuk JavaScript. JSHint adalah garpu baru JSLint, tetapi belum banyak menyimpang dari aslinya.

Sejak itu, JSLint tetap statis, sementara JSHint telah banyak berubah - JSLint telah membuang banyak aturan JSLint yang lebih antagonistik, telah menambah banyak aturan baru, dan umumnya menjadi lebih fleksibel. Juga, alat ESLint lain sekarang tersedia, yang bahkan lebih fleksibel dan memiliki lebih banyak opsi aturan.

Dalam jawaban asli saya, saya mengatakan bahwa Anda tidak harus memaksakan diri untuk mematuhi aturan JSLint; selama Anda mengerti mengapa itu memberikan peringatan, Anda dapat membuat keputusan untuk diri sendiri tentang apakah akan mengubah kode untuk menyelesaikan peringatan atau tidak.

Dengan aturan ultra-ketat JSLint dari 2011, ini adalah saran yang masuk akal - Saya telah melihat sangat sedikit kode JavaScript yang dapat lulus tes JSLint. Namun dengan aturan yang lebih pragmatis tersedia di alat JSHint dan ESLint hari ini, itu adalah usulan yang jauh lebih realistis untuk mencoba membuat kode Anda melewatinya dengan nol peringatan.

Mungkin kadang-kadang masih ada kasus-kasus di mana linter akan mengeluh tentang sesuatu yang telah Anda lakukan dengan sengaja - misalnya, Anda tahu bahwa Anda harus selalu menggunakan ===tetapi hanya kali ini saja Anda memiliki alasan yang baik untuk menggunakannya ==. Tetapi meskipun demikian, dengan ESLint Anda memiliki opsi untuk menentukan di eslint-disablesekitar baris yang dimaksud sehingga Anda masih dapat memiliki tes serat yang lulus dengan nol peringatan, dengan sisa kode Anda mematuhi aturan. (Hanya saja, jangan melakukan hal semacam itu terlalu sering!)


[ORIGINAL JAWABAN BERIKUT]

Dengan segala cara gunakan JSLint. Tapi jangan terpaku pada hasil dan memperbaiki semua yang diperingatkan. Ini akan membantu Anda meningkatkan kode Anda, dan itu akan membantu Anda menemukan bug potensial, tetapi tidak semua yang dikeluhkan JSLint ternyata menjadi masalah nyata, jadi jangan merasa Anda harus menyelesaikan proses ini dengan nol peringatan.

Hampir semua kode Javascript dengan panjang atau kompleksitas yang signifikan akan menghasilkan peringatan di JSLint, tidak peduli seberapa baik ditulisnya. Jika Anda tidak percaya, coba jalankan beberapa perpustakaan populer seperti JQuery melaluinya.

Beberapa peringatan JSLint lebih berharga daripada yang lain: pelajari yang mana yang harus diperhatikan, dan mana yang kurang penting. Setiap peringatan harus dipertimbangkan, tetapi jangan merasa berkewajiban untuk memperbaiki kode Anda untuk menghapus setiap peringatan yang diberikan; tidak apa-apa untuk melihat kode dan memutuskan Anda senang dengan itu; ada kalanya hal-hal yang JSlint tidak suka sebenarnya adalah hal yang benar untuk dilakukan.


3
Bagian terbaik dari jsHint adalah ia memiliki flag untuk menerima jQuery dan tidak mengganggu / ketat seperti jslint. Misalnya: for (i = 0; i < dontEnumsLength; i++)melempar ke Unexpected '++'tempat yang tidak apa-apa. dll.
RaphaelDDL

2
Tolong, jangan abaikan peraturan, ini adalah hal terburuk yang dapat Anda lakukan dengan linter. Atur saja, atau jika Anda tidak bisa melakukannya, ubah. Kombinasi JSHint dan JSCS luar biasa
AuthorProxy

JSHint mengatakan, "Diharapkan penugasan atau panggilan fungsi dan sebagai gantinya melihat ekspresi." ke ternary yang digunakan untuk operasi saja. Dokumentasi Mozilla: mengatakan "Anda juga dapat menggunakan evaluasi terner di ruang kosong untuk melakukan operasi yang berbeda". developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/… @AuthorProxy Saya akan menggunakan Mozilla dan mengabaikan JSHint. Maaf.
dewd

1
Pada saat ini sepertinya ESLint adalah arah industri menuju keseluruhan, bersama dengan konfigurasi populer seperti airbnb.
jinglesthula

369

tl; dr takeaway :

Jika Anda mencari standar yang sangat tinggi untuk diri sendiri atau tim, JSLint. Tapi itu belum tentu THE standar, hanya standar A, beberapa di antaranya datang kepada kita secara dogmatis dari dewa javascript bernama Doug Crockford. Jika Anda ingin sedikit lebih fleksibel, atau memiliki beberapa pro lama di tim Anda yang tidak setuju dengan pendapat JSLint, atau akan bolak-balik antara JS dan bahasa C-family lainnya secara teratur, coba JSHint.

versi panjang :

Alasan di balik garpu menjelaskan dengan cukup baik mengapa JSHint ada:

http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to -jshint /

Jadi saya kira idenya adalah "didorong oleh komunitas" dan bukan oleh Crockford. Secara praktis, JSHint umumnya sedikit lebih lunak (atau paling tidak dapat dikonfigurasi atau agnostik) pada beberapa "pendapat" sintaksis gaya dan minor yang digunakan JSLint.

Sebagai contoh, jika Anda berpikir A dan B di bawah baik-baik saja, atau jika Anda ingin menulis kode dengan satu atau lebih aspek A yang tidak tersedia di B, JSHint cocok untuk Anda. Jika menurut Anda B adalah satu-satunya pilihan yang benar ... JSLint. Saya yakin ada perbedaan lain, tetapi ini menyoroti beberapa.

A) Lulus JSHint di luar kotak - gagal JSLint

(function() {
  "use strict";
  var x=0, y=2;
  function add(val1, val2){
    return val1 + val2;
  }
  var z;
  for (var i=0; i<2; i++){
    z = add(y, x+i);
  }
})();

B) Melewati JSHint dan JSLint

(function () {
    "use strict";
    var x = 0, y = 2, i, z;
    function add(val1, val2) {
       return val1 + val2;
    }
    for (i = 0; i < 2; i += 1) {
        z = add(y, x + i);
    }
}());

Secara pribadi saya menemukan kode JSLint sangat bagus untuk dilihat, dan satu-satunya fitur keras yang saya tidak setuju adalah kebenciannya terhadap lebih dari satu deklarasi var dalam suatu fungsi dan var i = 0deklarasi for-loop , dan beberapa penegakan spasi putih untuk deklarasi fungsi .

Beberapa hal spasi putih yang diterapkan JSLint, saya menemukan belum tentu buruk, tetapi tidak sinkron dengan beberapa konvensi ruang putih standar yang cukup untuk bahasa lain dalam keluarga (C, Java, Python, dll ...), yang sering diikuti sebagai konvensi dalam Javascript juga. Karena saya menulis dalam berbagai bahasa ini sepanjang hari, dan bekerja dengan anggota tim yang tidak suka spasi putih ala Lint dalam kode kami, saya menemukan JSHint menjadi keseimbangan yang baik. Ini menangkap hal-hal yang merupakan bug yang sah atau bentuk yang benar-benar buruk, tetapi tidak menggonggong pada saya seperti JSLint (kadang-kadang, dengan cara saya tidak dapat menonaktifkan) untuk pendapat gaya atau nitpicks sintaksis yang tidak saya pedulikan.

Banyak perpustakaan yang bagus tidak Lint'able, yang bagi saya menunjukkan bahwa ada beberapa kebenaran dengan gagasan bahwa beberapa JSLint hanya tentang mendorong 1 versi "kode yang baik" (yang memang kode yang baik). Tapi sekali lagi, perpustakaan yang sama (atau yang bagus lainnya) mungkin juga tidak bisa dihubungi, jadi, sentuhlah.


11
... Saya harus mengakui, saya kecewa dengan kualitas saran yang tidak profesional yang baru-baru ini saya lihat berkembang biak sehubungan dengan gaya pengkodean untuk JS (dan CSS juga, kebetulan, kebetulan). Seolah-olah kegilaan dengan bahasa tertentu telah mengesampingkan kebutuhan praktisi non-ahli (yaitu audiens target). Ini memalukan mengingat mereka membutuhkan nasihat yang baik, dan akan secara membabi buta mengikuti dan mengabadikan apa pun yang disebut-sebut sebagai praktik terbaik, tanpa mengetahui yang lebih baik. Seringkali itu tidak sesuai dengan standar lain yang diadopsi oleh komunitas pengguna yang lebih mapan untuk bahasa lain. :(
Lee Kowalkowski

67
@LeeKowalkowski Alasan yang membuat JSLint putus asa for (var i = 0; ...; i++)adalah karena itu tidak membuat loop mandiri. Ruang lingkup iadalah fungsinya. Sintaksisnya sepertinya menciptakan ruang lingkup blok, tetapi tidak dan itu menyebabkan programmer JavaScript yang kurang berpengalaman dan orang-orang yang menulis dalam berbagai bahasa untuk salah paham ruang lingkup variabel dan yang dapat mengakibatkan bug halus. Banyak dari kita (termasuk saya sendiri) mungkin tidak suka tampilannya menempatkan semua deklarasi di atas, tetapi ini adalah pengingat yang baik bahwa JavaScript tidak memiliki ruang lingkup blok.
Mark Evans

25
@ MarkEvans Cukup berisi dari pandangan bahwa jika Anda hanya memindahkan loop ke fungsi lain, itidak akan secara tidak sengaja menjadi global. Fakta bahwa ifungsi scoped bukan block scoped bukan alasan yang cukup baik untuk mendeklarasikan variabel di atas, variabel harus selalu dinyatakan sedekat mungkin dengan tempat mereka digunakan ( programmers.stackexchange.com/questions/56585/… ).
Lee Kowalkowski

17
@MarkEvans Saya pikir Anda terlalu fokus pada detail implementasi bahasa. Standar pemrograman harus untuk manusia, bukan penyusun. Ketergantungan pada alat analisis kode statis untuk menangkap perangkap umum bukanlah pengganti untuk mengadopsi kebiasaan baik yang menghindarinya sejak awal. Saya tidak dapat memahami alasan mengapa variabel iterator untuk loop sederhana harus dinyatakan dengan jarak yang jauh dari loop yang memerlukannya. Banyak standar pengkodean untuk bahasa lain mengatakan deklarasikan variabel sedekat mungkin dengan yang digunakan, agar mudah dibaca. Saya belum melihat alasan yang baik untuk tidak melakukan ini di JS.
Lee Kowalkowski

11
Menggunakan variabel iterator di luar loop adalah hal yang harus diperiksa oleh linter.
Lee Kowalkowski

61

Ada lagi "pemain" dewasa dan aktif dikembangkan di depan javascript linting - ESLint:

ESLint adalah alat untuk mengidentifikasi dan melaporkan pola yang ditemukan dalam kode ECMAScript / JavaScript. Dalam banyak hal, ini mirip dengan JSLint dan JSHint dengan beberapa pengecualian:

  • ESLint menggunakan Esprima untuk parsing JavaScript.
  • ESLint menggunakan AST untuk mengevaluasi pola dalam kode.
  • ESLint sepenuhnya dapat dicolokkan, setiap aturan adalah plugin dan Anda dapat menambahkan lebih banyak saat runtime.

Yang benar-benar penting di sini adalah dapat diperpanjang melalui plugin / aturan khusus . Sudah ada beberapa plugin yang ditulis untuk tujuan yang berbeda. Di antara yang lainnya , ada:

Dan, tentu saja, Anda dapat menggunakan alat bangun pilihan Anda untuk menjalankan ESLint:


1
Nilai memiliki linter yang berjalan di editor Anda saat Anda mengetik tidak dapat dikecilkan. ESLint digunakan dengan cara ini secara ekstensif. Saya belum pernah mendengar tentang dukungan editor JSLint atau JSHint (1 poin data anekdotal).
jinglesthula

17

Saya punya pertanyaan yang sama beberapa minggu yang lalu dan sedang mengevaluasi JSLint dan JSHint.

Bertentangan dengan jawaban dalam pertanyaan ini, kesimpulan saya bukanlah:

Dengan segala cara gunakan JSLint.

Atau:

Jika Anda mencari standar yang sangat tinggi untuk diri sendiri atau tim, JSLint.

Seperti Anda dapat mengkonfigurasi hampir aturan yang sama di JSHint seperti pada JSLint. Jadi saya berpendapat bahwa tidak ada banyak perbedaan dalam aturan yang bisa Anda capai.

Jadi alasan untuk memilih satu lebih dari yang lain lebih bersifat politis daripada teknis.

Kami akhirnya memutuskan untuk menggunakan JSHint karena alasan berikut:

  • Tampaknya lebih dapat dikonfigurasi JSLint itu.
  • Tampak jelas lebih didorong oleh komunitas daripada pertunjukan satu orang (tidak peduli betapa kerennya The Man ).
  • JSHint cocok dengan gaya kode kami OOTB lebih baik dari JSLint.

1
Terima kasih atas jawaban singkat dan ringkas. Ini menyelesaikan kekosongan saya tentang masalah ini.
akauppi

13

Saya akan membuat saran ketiga, Google Closure Compiler (dan juga Clinter Linter ). Anda dapat mencobanya online di sini .

Closure Compiler adalah alat untuk membuat unduhan JavaScript dan berjalan lebih cepat. Ini adalah kompiler sejati untuk JavaScript. Alih-alih mengkompilasi dari bahasa sumber ke kode mesin, ini mengkompilasi dari JavaScript ke JavaScript yang lebih baik. Ini mem-parsing JavaScript Anda, menganalisisnya, menghilangkan kode mati dan menulis ulang dan meminimalkan apa yang tersisa. Ini juga memeriksa sintaks, referensi variabel, dan jenis, dan memperingatkan tentang perangkap JavaScript umum.


4
Apa yang diambil oleh Kompilator Penutupan yang tidak dimiliki linter?
James McMahon

4
Saya tidak melihat satu peringatan yang dihasilkan oleh alat ini, padahal sudah seharusnya. JSLint dan JSHint menghasilkan begitu banyak peringatan untuk input yang sama, sehingga keduanya memberikan "terlalu banyak kesalahan".
wallyk

6
kami menggunakan penutupan pada proyek baru-baru ini dan tidak akan melakukannya lagi. linter tidak dapat dikonfigurasikan untuk mengaktifkan pemeriksaan tertentu (banyak di antaranya adalah hal-hal yang tidak Anda pedulikan) dan kompiler benar-benar hanya membuahkan hasil jika Anda bekerja secara eksklusif dengan pustaka ramah-penutupan (yang sebenarnya tidak ada di luar google).
Robert Levy

4
Ini tidak mengacu pada Google Closure Comepiler per se, tetapi alat Google harus selalu dilihat dengan sebutir garam. Mereka dibuat untuk memecahkan tujuan Google tertentu, dan mereka mungkin tidak sesuai dengan tujuan Anda.
Pacerier

@ RobertTevy terima kasih telah mengomentari pengalaman Anda, Anda telah ... saya sedang membaca panduan gaya google untuk javascript dan merekomendasikan closure-compiler karena ini adalah program lint. tetapi sekarang saya melihat ada orang lain seperti jslint dan jshint
Trevor Boyd Smith

13

Kata Pengantar: Ya, itu meningkat dengan cepat. Tetapi memutuskan untuk melakukannya. Semoga jawaban ini bermanfaat bagi Anda dan pembaca lainnya.

Saya agak terbawa suasana di sini

Petunjuk Kode

Meskipun JSLint dan JSHint adalah alat yang baik untuk digunakan, selama bertahun-tahun saya menghargai apa yang disebut teman saya @ugly_syntax :

ruang desain yang lebih kecil .

Ini adalah prinsip umum, seperti "biarawan zen", membatasi pilihan yang harus dibuat, seseorang dapat lebih produktif dan kreatif.

Karenanya, gaya kode JS nol konfigurasi favorit saya saat ini:

StandardJS .

PEMBARUAN :

Aliran telah meningkat banyak. Dengan itu, Anda dapat menambahkan jenis ke JS Anda dengan akan membantu Anda mencegah banyak bug. Tapi itu juga bisa menghalangi Anda, misalnya ketika menghubungkan JS yang tidak diketik. Cobalah!

Mulai cepat / TL; DR

Tambahkan standardsebagai ketergantungan pada proyek Anda

npm install --save standard

Lalu package.json, tambahkan skrip pengujian berikut:

"scripts": {
    "test": "node_modules/.bin/standard && echo put further tests here"
},

Untuk keluaran yang lebih bagus saat mengembangkan, npm install --global snazzydan jalankan sebagai gantinya npm test.

Catatan: Jenis pemeriksaan versus Heuristik

Teman saya ketika menyebutkan ruang desain yang mengacu pada Elm dan saya mendorong Anda untuk mencoba bahasa itu.

Mengapa? JS sebenarnya terinspirasi oleh LISP, yang merupakan kelas bahasa khusus, yang kebetulan tidak diketik . Bahasa seperti Elm atau Purescript adalah bahasa pemrograman fungsional yang diketik .

Ketik membatasi kebebasan Anda agar kompiler dapat memeriksa dan memandu Anda saat Anda akhirnya melanggar bahasa atau aturan program Anda sendiri; terlepas dari ukuran (LOC) program Anda.

Kami baru-baru ini memiliki kolega yunior mengimplementasikan antarmuka reaktif dua kali: sekali di Elm, sekali di React; lihatlah untuk mendapatkan beberapa gagasan tentang apa yang saya bicarakan.

Bandingkan Main.elm(diketik) ⇔ index.js(tidak diketik , tidak ada tes)

(ps. perhatikan bahwa kode Bereaksi tidak idiomatik dan dapat ditingkatkan)

Satu komentar terakhir,

kenyataannya adalah bahwa JS tidak diketik. Siapa yang saya sarankan untuk mengetik program untuk Anda?

Lihat, dengan JS kita berada di domain yang berbeda: terbebas dari tipe, kita dapat dengan mudah mengekspresikan hal-hal yang sulit atau tidak mungkin untuk memberikan tipe yang tepat (yang tentunya bisa menjadi keuntungan).

Tetapi tanpa tipe ada sedikit untuk menjaga program kami di cek, jadi kami dipaksa untuk memperkenalkan tes dan (untuk memperluas) gaya kode.

Saya sarankan Anda melihat LISP (misalnya ClojureScript ) untuk inspirasi dan berinvestasi dalam pengujian kode Anda. Baca Cara subtack untuk mendapatkan ide.

Perdamaian.


Mengapa downvote? Saya tentu tidak keberatan, tetapi karena OP menulis "ini membantu saya untuk menulis JavaScript yang lebih baik" Saya pikir ini adalah jawaban yang berguna? Bagaimana menurut anda?
Kabel

1
tidak terkait dengan downvotes, tetapi tautan Main.elm dan index.js Anda adalah 404
an

1
Pertanyaannya jelas jslint atau jshint, tidak meminta alternatif.
jzacharuk

1
Gif layak mendapatkan suara positif.
sr9yar

8

Nah, Alih-alih melakukan pengaturan serat manual kita bisa memasukkan semua pengaturan serat di bagian atas file JS kita sendiri misalnya

Nyatakan semua var global dalam file itu seperti:

/*global require,dojo,dojoConfig,alert */

Nyatakan semua pengaturan serat seperti:

/*jslint browser:true,sloppy:true,nomen:true,unparam:true,plusplus:true,indent:4 */

Semoga ini bisa membantu Anda :)


1

Ada juga alternatif lain yang dikembangkan secara aktif - JSCS - JavaScript Code Style :

JSCS adalah linter gaya kode untuk secara terprogram menegakkan panduan gaya Anda. Anda dapat mengonfigurasi JSCS untuk proyek Anda secara detail menggunakan lebih dari 150 aturan validasi, termasuk preset dari panduan gaya populer seperti jQuery, Airbnb, Google, dan banyak lagi.

Itu datang dengan beberapa preset yang dapat Anda pilih dengan hanya menentukan presetdalam .jscsrcfile konfigurasi dan menyesuaikannya - menimpa, mengaktifkan atau menonaktifkan aturan apa pun:

{
    "preset": "jquery",
    "requireCurlyBraces": null
}

Ada juga plugin dan ekstensi yang dibangun untuk editor populer.

Lihat juga:

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.