คำอธิบายเกี่ยวกับการทำลายบรรทัด Bad ของ JSHint ก่อนข้อผิดพลาด '+'


125

ใครช่วยอธิบายให้ฉันฟังได้ไหมว่าทำไม JSHint ถึงบ่นเรื่องต่อไปนี้

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

ด้วยข้อผิดพลาด Bad line breaking before '+' error

ฉันเข้าใจว่าข้อผิดพลาดนี้สามารถกำหนดค่าได้ด้วยlaxbreak ตัวเลือกซึ่งอธิบายไว้ว่า

ตัวเลือกนี้จะระงับคำเตือนส่วนใหญ่เกี่ยวกับการแตกบรรทัดที่อาจไม่ปลอดภัยในโค้ดของคุณ ไม่ระงับคำเตือนเกี่ยวกับรูปแบบการเข้ารหัสที่ต้องใช้เครื่องหมายจุลภาค ในการปราบปรามผู้ที่คุณต้องใช้ laxcomma (ดูด้านล่าง)

คำอธิบายนี้ค่อนข้างสั้นและฉันก็อยากรู้ว่าทำไมการทำลายเส้นแบบนี้จึงถือว่าไม่ดีหรือหละหลวมในตอนแรก

โปรดทราบว่าฉันไม่ได้พยายามเริ่มสงครามศักดิ์สิทธิ์ที่นี่ฉันแค่มองหาคำตอบที่เป็นเป้าหมายว่าทำไมคน JSHint ถึงคิดว่าสิ่งนี้ไม่ดีไม่ว่าจะเป็นเพียงความชอบสไตล์ที่พวกเขาฉีดเข้าไปในเศษของพวกเขา (ฉันคิดว่า JSLint เป็น ความคิดเห็นของตัวอักษร) หรือหากมีบางอย่างที่อาจผิดพลาดกับล่ามบางตัวเมื่อสายขาดด้วยวิธีนี้


6
ฉันคิดว่ามันเป็นแค่ "สไตล์ที่ไม่ดี" ตาม JSHint คุณจะได้รับผลเช่นเดียวกันหากคุณใช้ลูกน้ำนำหน้า เพื่อความสามารถในการอ่านอย่างน้อยฉันควรเขียนใหม่ด้วยเครื่องหมาย + ที่ท้ายบรรทัด
Iwan

28
คนเกียจคร้าน ฉันคิดว่าสไตล์นี้เป็นสไตล์ที่อ่านง่ายที่สุดที่จะใช้กับสตริงหลายบรรทัดโดยเฉพาะอย่างยิ่งเมื่อดูโค้ดในหน้าต่างแคบ ๆ
Lambart

12
นำหน้าด้วยโทเค็นที่ดำเนินการต่อคำสั่งจะช่วยจัดแนวสิ่งต่างๆและแสดงความต่อเนื่องทางสายตาในส่วนด้านซ้ายของบล็อกโค้ดซึ่งเป็นที่ที่เราคาดหวังว่าจะพบองค์ประกอบโครงสร้างโดยเฉพาะอย่างยิ่งหากสแกนอย่างรวดเร็ว มันเป็นไปได้และสมเหตุสมผลอย่างแน่นอนและไม่ใช่สไตล์ที่ไม่ดี อย่างไรก็ตามมีปัญหาด้านความสมบูรณ์ของรหัสสำหรับการบังคับใช้กฎนี้ซึ่งเป็นเรื่องที่โชคร้าย
Adam Tolley

1
@AdamTolley ฉันเห็นด้วยอย่างยิ่งและเมื่อฉันถามเกี่ยวกับเรื่องนี้สิ่งที่ดูเหมือนจะเป็นการยืนยันว่านี่คือ FUD มันถูกนำมาภายใต้การตรวจสอบข้อเท็จจริงหลังจาก "meta effect"; และการตรวจสอบข้อเท็จจริงนั้นดูเหมือนจะยืนยันว่าสิ่งนี้เป็นไปได้และสมเหตุสมผล
HostileFork บอกว่าอย่าไว้ใจ SE

2
ปัจจุบัน ( JSHint 2.9.4 ) ข้อความแสดงข้อผิดพลาดคือการแบ่งบรรทัดที่ทำให้เข้าใจผิดก่อน "+" ผู้อ่านอาจตีความว่านี่เป็นขอบเขตการแสดงออก
RhinoDevel

คำตอบ:


107

มันเป็นคำแนะนำรูปแบบงบหลีกเลี่ยงที่จะต้องระวางโทษสมมติฐานเกี่ยวกับการแทรกอัฒภาคอัตโนมัติ

แนวคิดก็คือคุณทำให้ชัดเจนในตอนท้ายของบรรทัดว่านิพจน์นั้นจบลงตรงนั้นหรือสามารถดำเนินการต่อในบรรทัดถัดไป


6
ขอบคุณสำหรับคำตอบการมีเหตุผลเบื้องหลังข้อผิดพลาดทำให้ฉันสามารถปรับการเปลี่ยนแปลงเพื่อเอาใจ JSHint ได้ง่ายขึ้นมาก
James McMahon

36
การแทรกอัฒภาคอัตโนมัติเป็นเหตุผลที่เหมาะสมสำหรับการบังคับใช้สไตล์นี้ แต่เมื่อนิพจน์อยู่ในวงเล็บคำเตือนจะยังคงอยู่ และนั่นทำให้ฉันเศร้า
Ben Hyde

23
ที่สอง @BenHyde และโดยทั่วไปแล้วมนุษย์สามารถอ่านได้มากกว่าเมื่ออ่านโค้ดเพื่อนำไปสู่บรรทัดด้วยไฟล์+. มันง่ายกว่าในสายตา (และมีแนวโน้มที่จะผิดพลาดน้อยกว่า) ที่จะติดตามคอลัมน์เดียวทางด้านซ้ายมากกว่าการกระโดดไปที่ปลายสุดของแต่ละบรรทัดเพื่อดูว่าบรรทัดถัดไปจะถูกต่อท้ายหรือไม่ แม้ไวยากรณ์จะไม่แน่น: "บรรทัด 118 ต่อท้าย 117" กับ "บรรทัด 117 จะต่อท้ายด้วยบรรทัด 118"
worc

9
โดยส่วนตัวแล้วฉันเกลียดตัวดำเนินการต่อท้าย (และลูกน้ำ) ที่ท้ายบรรทัดเพราะฉันผ่านมันไป มันง่ายกว่าสำหรับฉันที่จะอ่านตรรกะในคำสั่งบูลีนแบบหลายบรรทัด (&& หรือ || ที่จุดเริ่มต้นของบรรทัดแทนที่จะเป็นตอนท้าย) และฉันสามารถบอกรายการที่คั่นด้วยจุลภาคได้อย่างรวดเร็วนอกเหนือจากคำสั่งหลายบรรทัดอื่น ๆ โดยเริ่มต้นด้วย จุลภาค ขอบคุณพระเจ้าสำหรับ laxbreak
aaaaaa

2
@ บาร์นีย์คุณจะปรับความกังวลเกี่ยวกับการแทรกอัฒภาคอัตโนมัติกับคำตอบที่ให้ไว้สำหรับคำถามที่คล้ายกันของฉันได้อย่างไร ความเสี่ยงที่สมเหตุสมผลของรูปแบบนี้คืออะไร? สำหรับฉันแล้วมันมีความสามารถในการสแกน
HostileFork บอกว่าอย่าไว้วางใจใน

8

Jshint จะไม่ติดธงว่านี่เป็นการแบ่งบรรทัดที่ไม่ถูกต้องหากคุณใช้ + ก่อนตัวแบ่งบรรทัดซึ่งตรงข้ามกับในบรรทัดใหม่ ชอบมาก:

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

10
นี่ไม่ตอบคำถามแม้แต่ iota เดียว ทำไมโหวตถึงเยอะจัง?
Lambart

4
บางที แต่นี่เป็นวิธีหนึ่งในการแก้ไขปัญหานี้โดยไม่ต้องเปลี่ยนการตั้งค่า jshint ของคุณ
asulaiman

4
นี่ควรเป็นความคิดเห็นเนื่องจากไม่ได้ตอบคำถาม แต่ให้ข้อมูลที่มีค่า
tomtomssi

3

ไม่ใช่คำตอบโดยตรงสำหรับคำถาม แต่สำหรับใครก็ตามที่เจอปัญหานี้จาก Googling (เหมือนที่ฉันเคยทำ) ที่ต้องการรักษากฎ แต่แก้ไขคำเตือนต่อไปนี้อาจเป็นประโยชน์ ...

เมื่อใช้ Notepad ++ (เช่นกับปลั๊กอิน JSLint) สามารถแก้ไขได้โดยใช้การค้นหาและแทนที่ต่อไปนี้:

  • หาอะไร: (\r\n|\n|\r)( *)\+
  • แทนที่ด้วย: (รวมช่องว่างแรกและช่องสุดท้าย) +$1$2 
  • โหมดค้นหา: นิพจน์ทั่วไป

(ทดสอบเฉพาะบน Windows แต่ regex ควรใช้กับส่วนท้ายบรรทัด Unix หรือ Mac OS ด้วย)

ที่จะทำสิ่งที่คล้ายกันสำหรับ||, &&, ==, !=, <=หรือ>=แทนการ+ใช้นี้

  • หาอะไร: (\r\n|\n|\r)( *)(\|\||&&|==|!=|<=|>=)
  • แทนที่ด้วย: (รวมช่องว่างแรกและช่องสุดท้าย) $3$1 $2 

5
อาจเป็นประโยชน์สำหรับผู้ที่ต้องการเปลี่ยนการจัดรูปแบบ แต่มันล้มเหลวอย่างสิ้นเชิงที่จะตอบคำถาม (โดยนัย): "ฉันอยากรู้ว่าทำไมการทำลายเส้นแบบนี้จึงถือว่าไม่ดีหรือหละหลวมในตอนแรก"
Lambart

จุดที่เป็นธรรมได้เพิ่มบันทึกที่ด้านบนเพื่ออธิบายว่าเหตุใดฉันจึงโพสต์สิ่งนี้
Steve Chambers
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.