Penjelasan pemutusan baris buruk JSHint sebelum kesalahan '+'


125

Adakah yang bisa menjelaskan kepada saya mengapa JSHint mengeluh tentang hal berikut,

window.location.href = String1
    + '#'
    + Sting2
    + '='
    + String3;

Dengan kesalahan itu, Bad line breaking before '+' error

Saya memahami bahwa kesalahan ini dapat dikonfigurasi dengan laxbreak opsi , yang dijelaskan sebagai

Opsi ini menahan sebagian besar peringatan tentang kerusakan baris yang mungkin tidak aman di kode Anda. Itu tidak menekan peringatan tentang gaya pengkodean yang mengutamakan koma. Untuk menekannya, Anda harus menggunakan laxcomma (lihat di bawah).

Penjelasan ini cukup singkat dan saya ingin tahu mengapa memutuskan garis dengan cara ini dianggap buruk atau kendor pada awalnya.

Ingatlah bahwa saya tidak mencoba memulai perang suci di sini, saya hanya mencari jawaban obyektif tentang mengapa orang-orang JSHint menganggap ini buruk, apakah itu hanya preferensi gaya yang mereka masukkan ke dalam linter mereka (saya pikir JSLint adalah linter yang beropini), atau jika ada sesuatu yang bisa salah pada interpreter tertentu saat garis melanggar cara ini.


6
Saya pikir itu hanya "gaya buruk" menurut JSHint. Anda akan mendapatkan efek yang sama jika menggunakan koma di depan. Untuk keterbacaan, saya setidaknya akan menulis ulang dengan + di akhir baris.
Iwan

28
Kekecewaan. Saya pikir gaya ini benar-benar gaya yang paling mudah dibaca untuk digunakan dengan string multi-baris, terutama saat melihat kode di jendela sempit.
Lambart

12
memimpin dengan token yang melanjutkan pernyataan membantu menyelaraskan sesuatu dan secara visual mengekspresikan kelanjutan di bagian kiri blok kode, yang merupakan tempat yang diharapkan untuk menemukan elemen struktural, terutama jika memindai dengan cepat. Ini pasti layak dan masuk akal dan bukan, obyektif, gaya yang buruk. Namun, ada masalah integritas kode untuk menegakkan aturan ini, yang sangat disayangkan.
Adam Tolley

1
@AdamTolley Saya sepenuhnya setuju, dan ketika saya bertanya tentang hal ini, saya mendapat konfirmasi bahwa ini adalah FUD. Itu dibawa di bawah pengawasan setelah "efek meta"; dan pengamatan yang cermat tampaknya mengkonfirmasi bahwa hal ini dapat dilakukan dan masuk akal.
HostileFork mengatakan jangan percaya SE

2
Saat ini ( JSHint 2.9.4 ) pesan kesalahannya adalah Hentian baris yang menyesatkan sebelum '+'; pembaca mungkin menafsirkan ini sebagai batas ekspresi.
RhinoDevel

Jawaban:


107

Ini adalah panduan gaya untuk menghindari pernyataan yang bisa menyebabkan asumsi tentang penyisipan titik koma otomatis .

Idenya adalah Anda memperjelas pada akhir baris apakah ekspresi berakhir di sana atau dapat dilanjutkan di baris berikutnya.


6
Terima kasih atas jawabannya, memiliki alasan di balik kesalahan membuat lebih mudah bagi saya untuk membenarkan membuat perubahan untuk menenangkan JSHint.
James McMahon

36
Penyisipan titik koma otomatis adalah alasan yang masuk akal untuk penerapan gaya ini. Namun jika ekspresi berada dalam beberapa tanda kurung, peringatan tetap ada. Dan itu membuatku sedih.
Ben Hyde

23
kedua @BenHyde, dan secara umum lebih mudah dibaca manusia saat menelusuri kode untuk memimpin baris dengan +. lebih mudah dilihat (dan tidak terlalu rentan terhadap kesalahan) untuk mengikuti satu kolom di sebelah kiri daripada melompat ke ujung paling jauh dari setiap baris untuk melihat apakah itu akan ditambahkan ke baris berikutnya. bahkan tata bahasanya tidak terlalu kikuk: "Baris 118 menambahkan 117" versus "Baris 117 akan ditambahkan dengan Baris 118."
Worc

9
Secara pribadi, saya benci menambahkan operator (dan koma) ke akhir baris karena saya melewatinya. Lebih mudah bagi saya untuk membaca logika dalam pernyataan boolean multi-baris (&& atau || di awal baris daripada di akhir), dan saya dapat dengan cepat membedakan daftar yang dipisahkan koma dari pernyataan multi-baris lainnya dengan memulainya dengan a koma. Terima kasih Tuhan untuk laxbreak
aaaaaa

2
@Barney Bagaimana Anda mendamaikan kekhawatiran tentang penyisipan titik koma otomatis dengan jawaban yang diberikan untuk pertanyaan saya yang sangat mirip ? Apa risiko yang dapat dibenarkan dari format ini? Bagi saya itu memiliki keunggulan dalam scannability.
HostileFork mengatakan jangan percaya SE

8

Jshint tidak akan menandai ini sebagai pemisah baris yang buruk jika Anda menggunakan + sebelum pemutusan baris sebagai lawan di baris baru. Seperti:

window.location.href = String1 +
'#' +
Sting2 +
'=' +
String3;

10
Ini tidak menjawab pertanyaan bahkan sedikit pun. Mengapa begitu banyak suara positif?
Lambart

4
Mungkin tetapi ini adalah salah satu cara untuk mengatasi masalah ini tanpa harus mengubah pengaturan jshint Anda.
asulaiman

4
Ini harus menjadi komentar karena tidak benar-benar menjawab pertanyaan tetapi memberikan informasi yang berharga.
tomtomssi

3

Bukan jawaban langsung untuk pertanyaan tetapi bagi siapa saja yang menemukan ini dari Googling (seperti yang saya lakukan) yang ingin mempertahankan aturan tetapi memperbaiki peringatan, berikut ini mungkin berguna ...

Saat menggunakan Notepad ++ (mis. Dengan plugin JSLint), ini dapat diperbaiki menggunakan pencarian & ganti berikut:

  • Menemukan apa: (\r\n|\n|\r)( *)\+
  • Ganti dengan: (termasuk spasi pertama dan terakhir) +$1$2 
  • Mode Pencarian: Ekspresi reguler

(Hanya diuji di Windows tetapi regex juga harus berfungsi dengan akhiran baris Unix atau Mac OS.)

Untuk melakukan hal yang sama untuk ||, &&, ==, !=, <=atau >=bukan +, gunakan ini:

  • Menemukan apa: (\r\n|\n|\r)( *)(\|\||&&|==|!=|<=|>=)
  • Ganti dengan: (termasuk spasi pertama dan terakhir) $3$1 $2 

5
Berguna, mungkin, untuk orang yang ingin mengubah format mereka. Tapi itu benar-benar gagal menjawab pertanyaan (tersirat): "Saya ingin tahu tentang mengapa melanggar garis seperti ini dianggap buruk atau kendor di tempat pertama."
Lambart

Poin yang adil, telah menambahkan catatan di bagian atas yang menjelaskan mengapa saya memposting ini.
Steve Chambers
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.