มีเหตุผลที่ถูกต้องในการบังคับใช้ความกว้างสูงสุด 80 อักขระในไฟล์รหัสวันนี้และอายุใช่ไหม [ปิด]

159

อย่างจริงจัง. บนหน้าจอขนาด 22 นิ้วมันครอบคลุมเพียงแค่เศษหนึ่งส่วนสี่ของหน้าจอฉันต้องการกระสุนเพื่อขว้างกฏนี้

ฉันไม่ได้บอกว่าไม่ควรมีขีด จำกัด ; ฉันแค่พูดว่า 80 ตัวอักษรมีขนาดเล็กมาก

text-editor  coding-style  policy 
— TraumaPony
แหล่งที่มา
คำตอบทั้งหมดระบุว่าฉันต้องการเพิ่มอะไร เพื่อให้เป็นตัวอย่างในชีวิตจริง - ฉันมี x61 ความละเอียดคือ 1024x768 เมื่อฉันอยู่บนท้องถนนฉันไม่มีจอแฟนซีของฉัน รหัสเปิดใน IDE ของฉันเป็นความเจ็บปวดเมื่อมันเกินกฎนี้
— จนถึง
อาจเป็นไปได้ซ้ำกับstackoverflow.com/questions/95575/…
แม้ว่าคุณจะมีจอภาพ 3 ชุด นี่ไม่ใช่เหตุผลที่จะเขย่าหัวขวาไปซ้ายและกลับ ตลอดไป อาฮ่า ที่จริงแล้วดวงตาเคลื่อนที่เร็วกว่าหัว คุณรู้เกี่ยวกับคอลัมน์ในหนังสือพิมพ์หรือไม่? เหตุผลของความกว้างคือความสะดวกสบายของตา / หัว / คน
— Ivan Black
— RBT

คำตอบ:

258

ฉันคิดว่าวิธีปฏิบัติในการเก็บโค้ดไว้ที่ 80 (หรือ 79) คอลัมน์นั้นถูกสร้างขึ้นเพื่อสนับสนุนผู้ใช้ในการแก้ไขโค้ดบนเทอร์มินัลใบ้ 80 คอลัมน์หรือในงานพิมพ์ 80 คอลัมน์ ความต้องการเหล่านั้นส่วนใหญ่หายไปแล้ว แต่ยังมีเหตุผลที่ถูกต้องในการรักษากฎคอลัมน์ 80 คอลัมน์:

  • เพื่อหลีกเลี่ยงการตัดคำเมื่อคัดลอกรหัสลงในอีเมลเว็บเพจและหนังสือ
  • หากต้องการดูหน้าต่างแหล่งที่มาหลายแห่งเคียงข้างกันหรือใช้มุมมอง diff-by-side
  • เพื่อปรับปรุงการอ่าน รหัสแคบสามารถอ่านได้อย่างรวดเร็วโดยไม่ต้องสแกนตาจากทางด้านข้าง

ฉันคิดว่าจุดสุดท้ายนั้นสำคัญที่สุด แม้ว่าการแสดงมีการเติบโตในขนาดและความละเอียดในช่วงไม่กี่ปีที่ผ่านมาได้มีตาไม่ได้

— Will Harris
แหล่งที่มา
7
พวกเขาอาจมี "หายไปส่วนใหญ่" แต่ไม่ใช่ทั้งหมด ฉันมักจะทำงานกับการตั้งค่าที่แตกต่างกันสองแบบ: 1) ในหน้าต่าง ssh ที่เชื่อมต่อกับเครื่องระยะไกล ซึ่งมีความกว้าง 80 อักขระโดยค่าเริ่มต้น และ 2) ใน Visual Studio มีสองพาเนลเคียงข้างกันดังนั้นฉันสามารถดูไฟล์ส่วนหัวและ cpp ในเวลาเดียวกัน
— Enno
10
@steffenj: ที่จริงแล้วหนังสือมักจะถ่ายได้ประมาณ 66 ตัวอักษรต่อบรรทัด (แม้ว่าจะแตกต่างกันไปขึ้นอยู่กับพารามิเตอร์อื่น ๆ ) เพราะบรรทัดที่ยาวกว่าจะทำให้การอ่านยากขึ้น ความยาวบรรทัดโค้ดสูงสุดสามารถโต้แย้งได้ แต่ 80 สะดวกสำหรับเหตุผลทางประวัติศาสตร์และการปฏิบัติ
— Steve S
70
ปัญหาคือโดยการบังคับให้คนที่จะให้ความยาวสายสั้นที่พวกเขามีแนวโน้มที่จะใช้ชื่อ meaningfull น้อย ..
— เอียน Ringrose
4
ฉันพบข้อสังเกตเกี่ยวกับความสามารถในการอ่านที่น่าสนใจเพราะสิ่งที่ฉันเกลียดเกี่ยวกับการเขียนโปรแกรมการพิมพ์บทความ / หนังสือ / ... คือว่าบรรทัดสั้น ๆ ที่ใช้สำหรับตัวอย่างโค้ดนั้นยากมากที่จะอ่าน มันสามารถใช้เป็นอย่างมากในการย้ายบางสิ่งไปยังบรรทัดใหม่ แต่การจัดกลุ่มควรเกิดขึ้นอย่างมีเหตุมีผลทำให้การแสดงออกที่เกิดขึ้นซ้ำไม่เกิดขึ้นเนื่องจากอุปกรณ์เอาต์พุตมีข้อ จำกัด ถึงโดยไม่ตั้งใจ IOW ฉันพบว่าอุปกรณ์ที่กำหนดข้อ จำกัด แคบ ๆ นี้ไม่เหมาะที่จะแสดงรหัส
— Chris Lercher
4
ฉันคิดว่าปัญหาของผู้บังคับใช้ 80 คอลัมน์คือพวกเขาลืมว่าโค้ดจะเติบโตในทิศทางแนวตั้งแทน คุณได้รับปัญหาเดียวกัน แต่ในแนวดิ่งและด้านบนของรหัสที่ทันสมัยนี้ดูแย่มากเมื่อคุณต้องแบ่งงบเดี่ยวมากกว่าสองหรือบางครั้งถึงสี่หรือห้าบรรทัด มันไม่สามารถอ่านได้มากขึ้น ด้วยโค้ดที่ทันสมัยฉันหมายถึงชื่อตัวแปรอธิบายและการสืบทอดคุณสมบัติเนมสเปซคลาส ฯลฯ โปรดหยุด nonsese 80 คอลัมน์ใช้สามัญสำนึกแทน 120 ดีกว่า แต่ก็ไม่ควรเป็นกฎเช่นกัน
— Larswad
79

ต้นกำเนิดของการจัดรูปแบบข้อความ 80 คอลัมน์อยู่ก่อนหน้าเทอร์มินัล 80 คอลัมน์ - บัตรเจาะไอบีเอ็มของ IBM มีอายุย้อนไปถึงปี 1928 ! นี่เป็นการระลึกถึงเรื่องราว(หลักฐาน)ที่ทางรถไฟของสหรัฐอเมริกาถูกกำหนดโดยความกว้างของล้อรถม้าในโรมันบริเตน

บางครั้งฉันคิดว่ามันหดเล็กน้อย แต่ก็จะทำให้ความรู้สึกที่มีบางวงเงินมาตรฐานดังนั้น 80 คอลัมน์มันเป็น

นี่คือหัวข้อเดียวกันที่ครอบคลุมโดยSlashdot

และนี่คือคำแถลงของ Fortran แบบโรงเรียนเก่า:

ฟอร์แทรนหมัดการ์ด

— John Carter
แหล่งที่มา
59

80 ตัวอักษรเป็นข้อ จำกัด ที่ไร้สาระวันนี้ แยกบรรทัดโค้ดของคุณออกตามความเหมาะสมโดยไม่ จำกัด จำนวนอักขระโดยพลการ

— วันเครก
แหล่งที่มา
1
การ จำกัด จำนวนอักขระไม่ได้บอกคุณว่าคุณต้องแยกบรรทัดของรหัสที่ใด แต่เมื่อ
— gztomas
ไม่มันไม่ใช่. หากคุณเขียนบรรทัดที่ยาวเกิน 80 ตัวอักษรคุณอาจมีปัญหาเกี่ยวกับความซับซ้อนในการแสดงออกหรือกลยุทธ์การตั้งชื่อ ตามที่คนอื่น ๆ ได้กล่าวถึงการอ่านเป็นสิ่งที่น่ากังวลและความเร็วในการอ่านเริ่มลดลงเหนือระดับ 60-66 ตัวอักษร (การพิมพ์ตามสรีรวิทยาของมนุษย์)
— โซลา
@sola ความคิดเห็นของคุณปรากฏที่นี่ด้วย 98 ตัวอักษรและมันเป็นภาษาที่ไม่ใช่ภาษาท้องถิ่นที่มีความหนาแน่นสูง (สำหรับฉัน) ที่จะเข้าใจ อ่านได้ชัดเจน รหัสที่มีความยาวได้ถึง 3-4 เยื้องเครื่องหมายไวยากรณ์ ฯลฯ นั้นง่ายยิ่งขึ้น
— viyps
ฉันเผลอลงคำตอบนี้โดยไม่ตั้งใจและไม่สามารถลงคะแนนได้อีกต่อไป :(
— แอนดี้
35

คุณควรทำเพื่อประโยชน์ของทุกคนที่ไม่มีจอไวด์สกรีนขนาด 22 นิ้ว โดยส่วนตัวฉันทำงานบนจอภาพ 17 นิ้ว 4: 3 และฉันพบว่ากว้างพอสมควร อย่างไรก็ตามฉันมีจอภาพ 3 จอดังนั้นฉันยังมีพื้นที่หน้าจอที่ใช้งานได้มากมาย

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

— Kibbee
แหล่งที่มา
14
ไม่ใช่เมื่อคุณเพิ่มการเยื้องลงในส่วนผสม หากคุณใช้ช่องว่าง 4 รายการต่อการเยื้องและคุณอยู่ในชื่อเนมสเปซ -> class-> method-> if-> for นั่นคือ 1 / 5th ของ Space ของคุณ
— TraumaPony
คุณสามารถตั้งกฎไว้ที่ 80 ตัวอักษรจากการเยื้อง ด้วยวิธีนี้ตาสามารถติดตามได้อย่างง่ายดาย
— Vincent McNabb
บางครั้ง (แต่ไม่เสมอไป) ฉันต้องการ. Net มีการกำหนดเนมสเปซอัตโนมัติเพื่อให้คุณไม่ต้องกำหนดเนมสเปซในไฟล์ ที่ยุ่งกับการจัดตำแหน่งรหัสของคุณอย่างจริงจัง ถ้าคุณต้องการเนมสเปซที่ซ้อนกันคุณมีปัญหาใหญ่จริงๆ
— Kibbee
13
อย่างไรก็ตามการอ่านร้อยแก้วไม่เหมือนกับรหัสอ่าน
— Atario
3
+1 สำหรับหนังสือพิมพ์เป็นตัวอย่างที่ดี @Atario การอ่านรหัส GOOD เป็นเหมือนการอ่านร้อยแก้ว
— ทอดด์แชฟฟี
23

เมื่อคุณมีลำดับของข้อความสั่งที่ทำซ้ำกับความผันแปรเล็ก ๆ น้อย ๆ คุณจะสามารถเห็นความเหมือนและความแตกต่างได้ง่ายขึ้นหากพวกมันถูกจัดกลุ่มเป็นบรรทัด

ฉันขอยืนยันว่าสิ่งต่อไปนี้อ่านได้ง่ายกว่าที่คิดหากฉันแยกมันเป็นหลายบรรทัด:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

อัปเดต:ในความคิดเห็นมีคนแนะนำว่านี่จะเป็นวิธีที่กระชับยิ่งขึ้นในการทำตามข้างต้น

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY;

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

— Sam Hasler
แหล่งที่มา
8
การบอกว่ามีความแตกต่างเพียงเล็กน้อยจากบรรทัดหนึ่งไปอีกบรรทัดคุณก็บอกว่ามีรหัสซ้ำซ้อนมากมาย การลบบางส่วนอาจลดจำนวนคอลัมน์ลงอย่างมากและยังคงอยู่ในแนวตั้ง
— foraidt
@mxp: ตกลง หากมีวิธีที่รัดกุมมากขึ้นในการเขียนข้างต้นฉันสนใจที่จะเห็นมัน
— Sam Hasler
ฉันเห็นด้วยกับแนวคิดทั่วไป แต่เป็นตัวอย่าง ... สิ่งที่เกี่ยวกับสิ่งนี้: switch (... ) {case ... BL: dxDir = - 1; dyDir = - 1; หยุดพัก; กรณี ... BR: dxDir = + 1; dyDir = - 1; หยุดพัก; ... } ... ["X"] = pt1.x + dxDir * Rad ... X; ... ["Y"] = pt1.y + dyDir * Rad ... Y;
— Yarik
38
ความจริงที่ว่าฉันต้องเลื่อนตัวอย่างแรกจากสองตัวอย่างในแนวนอนพิสูจน์ไพนต์เกี่ยวกับเส้นที่สั้นกว่านั้นจะดีกว่า :-)
— Enno
1
ฉันไม่เข้าใจความเกลียดชังที่มีต่อการเลื่อน มันเป็นความคิดเห็นทั่วไปและฉันไม่ได้พูดว่ามันผิดฉันแค่ไม่เข้าใจ โดยเฉพาะอย่างยิ่งถ้าคุณอยู่ในโปรแกรมแก้ไขโค้ดคุณไม่จำเป็นต้องขยับมือออกจากคีย์บอร์ดเพื่อไปที่เม้าส์ - (ctrl+)arrowเหนือหรือกดend
— KOGI
16

ฉันใช้ประโยชน์จากหน้าจอที่ใหญ่ขึ้นเพื่อให้มีโค้ดหลายชิ้นติดกัน

คุณจะไม่ได้รับกระสุนจากฉัน ในความเป็นจริงฉันเกลียดที่จะเห็นการเปลี่ยนแปลงตั้งแต่ในกรณีฉุกเฉินฉันยังคงเห็นกรณีที่หายากที่ฉันต้องเปลี่ยนรหัสจากคอนโซลข้อความ

— Twan
แหล่งที่มา
14

เส้นที่ยาวเป็นพิเศษนั้นอ่านยาก เพียงเพราะคุณสามารถรับ 300 ตัวอักษรในจอภาพของคุณไม่ได้หมายความว่าคุณควรสร้างบรรทัดที่มีความยาว อักขระ 300 ตัวนั้นซับซ้อนเกินไปสำหรับคำสั่งยกเว้นว่าคุณไม่มีทางเลือก (การโทรที่ต้องการพารามิเตอร์จำนวนมาก)

ฉันใช้ 80 ตัวอักษรเป็นกฎทั่วไป แต่ฉันจะไปไกลกว่านั้นถ้าบังคับใช้มันจะหมายถึงการวางเส้นแบ่งในตำแหน่งที่ไม่พึงประสงค์

— Loren Pechtel
แหล่งที่มา
มีการศึกษาที่แสดงว่าผู้คนสามารถอ่านและติดตามจำนวนตัวอักษร / คำได้ x ก่อนที่พวกเขาจะหลุด ฉันคิดว่า 80 มีบางที่ ฉันไม่มีที่มาสำรอง
— จนถึง
ใช่ฉันคิดว่าจริงๆมันไม่ได้เกี่ยวกับการรักษาเส้นสั้น ๆ มากพอ ๆ กับการทำให้เส้นสะอาด / กระชับ / อ่าน / เข้าใจได้
— KOGI
หากคุณมี (การโทรที่ต้องการพารามิเตอร์จำนวนมาก) คุณต้องทำการรีแฟคเตอร์ใหม่
— Zarremgregarrok
@Zarremgregarrok ฉันเห็นรายการพารามิเตอร์ที่ยาวมากใน Microsoft APIs
— Loren Pechtel
@ LorenPechtel มันเขียนได้ดีไหม?
— Zarremgregarrok
8

สิ่งเดียวที่ฉันบังคับให้อยู่ภายใน 80 ตัวอักษรคือความคิดเห็นของฉัน

โดยส่วนตัว ... ฉันทุ่มเทพลังสมองทั้งหมดของฉัน (มีน้อย) ในการเขียนโปรแกรมให้ถูกต้องมันเป็นความเจ็บปวดที่ต้องย้อนกลับไปและทำลายทุกอย่างด้วยขีด จำกัด 80 ถ่านเมื่อฉันสามารถใช้เวลากับฟังก์ชั่นถัดไป . ใช่ Resharper สามารถทำเพื่อฉันได้ แต่หลังจากนั้นมันก็ทำให้ฉันประหลาดใจเล็กน้อยว่าผลิตภัณฑ์บุคคลที่สามกำลังตัดสินใจเกี่ยวกับรูปแบบรหัสของฉันและเปลี่ยนแปลงมัน ("โปรดอย่าแบ่งรหัสของฉันออกเป็นสองบรรทัด HAL HAL?" )

ที่กล่าวว่าฉันทำงานกับทีมที่ค่อนข้างเล็กและจอภาพทั้งหมดของเรามีขนาดใหญ่พอสมควรดังนั้นจึงต้องกังวลกับสิ่งที่รบกวนเพื่อนโปรแกรมเมอร์ของฉันไม่ได้เป็นกังวลมากเท่าที่จะไป

ดูเหมือนว่าบางภาษาจะส่งเสริมให้ใช้โค้ดที่ยาวกว่าเพื่อให้เห็นถึงการกระทบกระเทือนต่อบั๊ก

— domusvita
แหล่งที่มา
7

ฉันมีจอภาพ 20 "1600x1200 สองตัวและฉันติดกับคอลัมน์ 80 คอลัมน์เพราะมันช่วยให้ฉันแสดงหน้าต่างแก้ไขข้อความหลายรายการแบบเคียงข้างกันใช้ตัวอักษร '6x13' (ตัวอักษรตราด. xterm) 80 คอลัมน์ใช้เวลา 480 พิกเซลพร้อมแถบเลื่อน และขอบหน้าต่างสิ่งนี้อนุญาตให้หนึ่งมีสามหน้าต่างประเภทนี้บนจอภาพ 1600x1200 บน windows ฟอนต์ Lucida Console จะไม่ทำเช่นนี้ (ขนาดที่เล็กที่สุดที่ใช้งานได้คือ 7 พิกเซลกว้าง) แต่จอภาพ 1280x1024 จะแสดงสองคอลัมน์และ จอภาพ 1920x1200 เช่นHP LP2465จะแสดงขึ้นมา 3 จอนอกจากนี้ยังมีพื้นที่ด้านข้างเล็กน้อยสำหรับนักสำรวจคุณสมบัติและหน้าต่างอื่น ๆ จาก Visual Studio

นอกจากนี้บรรทัดข้อความที่ยาวมากยังอ่านยาก สำหรับข้อความที่เหมาะสมคือ 66 ตัวอักษร มีจุดที่ตัวระบุที่ยาวเกินไปเริ่มที่จะต่อต้านเพราะมันทำให้มันยากที่จะวางโค้ดอย่างสอดคล้องกัน เค้าโครงที่ดีและการเยื้องให้ตัวชี้นำที่มองเห็นได้เกี่ยวกับโครงสร้างรหัสและบางภาษา (Python มาถึงใจ) ใช้การเยื้องอย่างชัดเจนสำหรับสิ่งนี้

อย่างไรก็ตามไลบรารีคลาสมาตรฐานสำหรับ Java และ. Net มีแนวโน้มที่จะมีตัวระบุที่ยาวมากดังนั้นจึงไม่สามารถรับประกันได้ว่าจะสามารถทำสิ่งนี้ได้ ในกรณีนี้การวางโค้ดที่มีตัวแบ่งบรรทัดจะช่วยทำให้โครงสร้างชัดเจน

โปรดทราบว่าคุณจะได้รับหน้าต่างรุ่น '6x13' แบบอักษรที่นี่

— ConcernedOfTunbridgeWells
แหล่งที่มา
ขอบคุณที่พูดสิ่งนี้! จอภาพขนาดใหญ่ล้วนเป็นเหตุผลเพิ่มเติมสำหรับขีด จำกัด 80 บรรทัดดังนั้นคุณจึงสามารถติดตั้งหน้าต่างแบบคู่ขนานได้มากขึ้น ไม่ต้องพูดถึงว่ามันดีที่จะสามารถพิมพ์ซอร์สโค้ด (บนกระดาษ) บางครั้ง หรือวางตัวอย่างในเอกสารอื่น ๆ
— 3 #reeree
7

ผู้คนพูดว่าโค้ดที่มีความยาวมักจะซับซ้อน พิจารณาคลาส Java อย่างง่าย:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

นี่คือความยาว 94 อักขระและชื่อคลาสค่อนข้างสั้น (ตามมาตรฐาน GWT) มันยากที่จะอ่านใน 2 บรรทัดและสามารถอ่านได้มากในหนึ่งบรรทัด ในทางปฏิบัติเกี่ยวกับเรื่องนี้และอนุญาตให้ "เข้ากันได้ย้อนหลัง" ฉันจะบอกว่า 100 ตัวอักษรเป็นความกว้างที่เหมาะสม

— Matyas
แหล่งที่มา
5
ฉันไม่ใช่แฟนของแถบเลื่อนแนวนอน
— bryc
9
ฉันแปลกใจที่ไม่มีใครพูดถึงเรื่องนี้เนื่องจากฉันมาสายหลายปีแล้ว แต่ฉันคิดว่าบรรทัดใหม่ (อาจมีการเยื้องเพื่อความชัดเจน) ก่อนที่จะ "ขยาย" และ / หรือ "ใช้" คำหลักจะยังคงสร้างขึ้นอย่างมาก รหัสที่อ่านได้
— mtraceur
2
ฉันชอบความจริงที่ว่า "มันสามารถอ่านได้มากในบรรทัดเดียว" ในขณะเดียวกันฉันไม่สามารถอ่านข้อมูลโค้ดทั้งหมดได้เพราะมันล้นพื้นที่แนวนอนในเบราว์เซอร์ จุดหักเห
— oligofren
6

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

นั่นเป็นเวลาที่การมี "ความกว้างสูงสุด" นั้นมีประโยชน์

— user14038
แหล่งที่มา
6

คุณไม่ใช่คนเดียวที่จะรักษารหัสของคุณ

บุคคลต่อไปที่อาจมีหน้าจอ 17 "หรืออาจต้องใช้แบบอักษรขนาดใหญ่เพื่ออ่านข้อความขีด จำกัด ต้องอยู่ที่ใดที่หนึ่งและ 80 ตัวอักษรเป็นแบบแผนเนื่องจากข้อ จำกัด ของหน้าจอก่อนหน้าคุณสามารถคิดถึงมาตรฐานใหม่ (120) และ เหตุใดจึงเป็นความคิดที่ดีที่จะใช้สิ่งอื่นในตอนนั้น

โปรดจำไว้ว่ามีข้อยกเว้นสำหรับทุกกฎอยู่เสมอเพื่อให้คุณมีบรรทัดหรือบล็อกของรหัสเฉพาะที่เหมาะสมกว่า 80 ตัวอักษรจากนั้นเป็นกบฏ

แต่ใช้เวลาก่อนที่จะคิดว่า "เป็นรหัสนี้จริง ๆ ที่ไม่ดีที่มันไม่สามารถอยู่ภายใน 80 ตัวอักษร?"

— pappes
แหล่งที่มา
1
ฉันจะอยู่กับ 80 ตัวอักษรเมื่อฉันสามารถมีแท็บหยุด 2spc ยังดีกว่าที่จริงแล้วใช้แท็บสำหรับการเยื้องความต้องการคือเมื่อ tabsize = 2 พอดีใน 80 คอลัมน์ใช้เวลาส่วนใหญ่ 4 เพื่อการอ่านที่ดีขึ้น ด้วยวิธีนี้เมื่อคุณต้องทำให้หายใจไม่ออกถึง 80 คอลัมน์คุณสามารถทำได้ แต่ในราคา
— Joshua
5

ในมาตรฐานการเข้ารหัส Linux ไม่เพียง แต่จะจำกัดความยาวของอักขระไว้ 80 ตัวเท่านั้น แต่ยังใช้การเว้นวรรค 8 ช่องอีกด้วย

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

สิ่งนี้จะทำให้รหัสชัดเจนขึ้นเนื่องจากไม่ว่าจะมีความยาวการเยื้องเท่าใดจึงเป็นการยากที่จะอ่านรหัสที่มีโครงสร้างการควบคุมหลายระดับซ้อนกัน

— อาลี
แหล่งที่มา
3
วิธีการเกี่ยวกับการอ่านรหัสด้วยการเรียกใช้ฟังก์ชันมากมาย? แน่นอนมีการประนีประนอมระหว่างสองวิธีนี้ ...
— Zsolt Török
5

ฉันเพิ่มโค้ดของฉันออกเป็น 100 ตัวอักษรซึ่งเหมาะกับหน้าจอน้อยกว่าครึ่งบน Macbook ของฉัน อักขระ 120 ตัวอาจเป็นขีด จำกัด ก่อนที่บรรทัดจะเริ่มยาวเกินไปและซับซ้อน คุณไม่ต้องการให้กว้างเกินไปมิฉะนั้นคุณควรส่งเสริมให้มีการรวมคำสั่งและโครงสร้างการควบคุมที่ซ้อนกันอย่างลึกซึ้ง

อัตรากำไรที่เหมาะสมเป็นวิธีธรรมชาติของการบอกให้คุณดำเนินการวิธีการ refactoring

— Schwern
แหล่งที่มา
5

ฉันสงสัยว่าสิ่งนี้อาจทำให้เกิดปัญหามากขึ้นในวันนี้และอายุ โปรดจำไว้ว่าใน C (และภาษาอื่น ๆ ) อาจมีกฎสำหรับระยะเวลาที่ชื่อฟังก์ชันสามารถใช้งานได้ ดังนั้นคุณมักจะเห็นชื่อที่เข้าใจยากมากในรหัส C สิ่งที่ดีคือพวกเขาไม่ได้ใช้พื้นที่มาก แต่ทุกครั้งที่ฉันดูรหัสในภาษาบางภาษาเช่น C # หรือ Java ชื่อวิธีมักจะยาวมากซึ่งทำให้เป็นไปไม่ได้ที่จะรักษารหัสของคุณด้วยความยาว 80 ตัวอักษร ฉันไม่คิดว่าวันนี้จะมี 80 ตัวอักษรยกเว้นว่าคุณจำเป็นต้องพิมพ์รหัส ฯลฯ

— โจนัส
แหล่งที่มา
5

ในฐานะผู้เขียนแนวทางการเข้ารหัสสำหรับนายจ้างของฉันฉันได้เพิ่มความยาวบรรทัดจาก 80 เป็น 132 ทำไมค่านี้ เช่นเดียวกับที่คนอื่น ๆ ชี้ให้เห็น80 คือความยาวของเทอร์มินัลฮาร์ดแวร์เก่า ๆ และก็ 132 เช่นกัน! เป็นความกว้างของเส้นเมื่อเทอร์มินัลอยู่ในโหมดไวด์ เครื่องพิมพ์ใด ๆ ก็สามารถทำสำเนาในโหมดไวด์ด้วยแบบอักษรย่อ

เหตุผลที่ไม่ได้อยู่ที่ 80 ก็เพราะฉันค่อนข้าง

  • ต้องการชื่ออีกต่อไปที่มีความหมายสำหรับตัวระบุ
  • ไม่รำคาญกับ typedefs สำหรับ structs และ enums ใน C (เป็น BAD พวกเขาซ่อนข้อมูลที่เป็นประโยชน์! ถาม Peter van der Linden ใน "Deep C Secrets" หากคุณไม่เชื่อ) ดังนั้นโค้ดจึงมีstruct FOO func(struct BAR *aWhatever, ...)มากกว่า fanatics ของ typedef .

และภายใต้กฎเหล่านี้เพียง 80 ตัวอักษร / บรรทัดทำให้เกิดเส้นที่น่าเกลียดที่ห่อหุ้มบ่อยกว่าที่ตาของฉันเห็นว่ายอมรับได้ (ส่วนใหญ่อยู่ในต้นแบบและคำจำกัดความของฟังก์ชั่น)

— Jens
แหล่งที่มา
4

อย่างที่คนอื่นพูดฉันคิดว่ามันดีที่สุดสำหรับ (1) การพิมพ์และ (2) แสดงไฟล์หลายไฟล์เคียงข้างกันในแนวตั้ง

— โทมัสโอเวนส์
แหล่งที่มา
4

ฉันชอบที่จะ จำกัด ความกว้างของฉันไว้ที่ 100 ตัวอักษรหรือมากกว่านั้นเพื่ออนุญาตให้ตัวแก้ไข SxS สองตัวบนหน้าจอไวด์สกรีน ฉันไม่คิดว่ามีเหตุผลที่ดีสำหรับการ จำกัด 80 ตัวอักษรอีกต่อไป

— Jamie Eisenhart
แหล่งที่มา
4

ใช้แบบอักษรตามสัดส่วน

ฉันจริงจัง ฉันมักจะได้รับเทียบเท่า 100-120 ตัวอักษรในบรรทัดโดยไม่ต้องเสียสละอ่านหรือพิมพ์ ในความเป็นจริงมันง่ายกว่าที่จะอ่านด้วยตัวอักษรที่ดี (เช่น Verdana) และการระบายสีไวยากรณ์ มันดูแปลก ๆ สักสองสามวัน แต่คุณชินแล้ว

— bgiles
แหล่งที่มา
ความคิดที่ไม่ดีจริง ๆ เมื่อคุณต้องการใช้ 'เยื้อง' และแบบอักษร monospaced
— Bersaelor
2
@Bersaelor ไม่มันทำงานได้ดีเมื่อคุณเยื้องการใช้แท็บเท่านั้นและตั้งค่าความกว้างของแท็บอย่างถูกต้อง (ความกว้าง 4 monospaced นั้นอาจจะเป็น 7 สัดส่วน) การเยื้องใช้งานได้คุณไม่สามารถทำงานศิลปะ ASCII ได้ แต่ฉันไม่คิดว่าศิลปะ ASCII เป็นของโค้ด
— maaartinus
โดยส่วนตัวฉันค่อนข้างตรงข้ามเมื่อเขียนโปรแกรม ฉันพบว่าโค้ดที่อ่านยาก บางครั้งฉันก็กำหนดค่า IDE ให้ใช้แบบอักษร monospace (ใช่รวมถึงเมนู)
— Sebastian Mach
2

ฉันพยายามทำให้สิ่งต่างๆใกล้เคียง 80 ตัวอักษรด้วยเหตุผลง่ายๆ: มากไปกว่านั้นหมายความว่ารหัสของฉันซับซ้อนเกินไป ชื่อคุณสมบัติ / เมธอดที่มากเกินไปชื่อคลาส ฯลฯ ทำให้เกิดอันตรายได้มากเท่ากับตัวอักษรย่อ

ฉันเป็นตัวเขียนแบบ Python เป็นหลักดังนั้นสิ่งนี้จึงสร้างข้อ จำกัด สองชุด:

  1. อย่าเขียนโค้ดที่มีความยาว
  2. อย่าเยื้องมากเกินไป

เมื่อคุณเริ่มเข้าถึงการเยื้องสองหรือสามระดับตรรกะของคุณจะสับสน หากคุณไม่สามารถเก็บบล็อกเดียวไว้ในหน้าเดียวกันได้รหัสของคุณซับซ้อนเกินไปและไม่สามารถจดจำได้ หากคุณไม่สามารถรักษาบรรทัดเดียวได้ภายใน 80 ตัวอักษรแสดงว่าบรรทัดของคุณซับซ้อนเกินไป

เป็นเรื่องง่ายใน Python ที่จะเขียนโค้ดที่ค่อนข้างรัดกุม (ดู codegolf) โดยมีค่าใช้จ่ายในการอ่าน แต่มันง่ายยิ่งกว่าที่จะเขียนโค้ด verbose ด้วยค่าใช้จ่ายในการอ่าน วิธีการช่วยเหลือไม่ได้เป็นสิ่งที่ไม่ดีหรือเป็นชั้นเรียนผู้ช่วย นามธรรมที่มากเกินไปอาจเป็นปัญหา แต่นั่นเป็นความท้าทายอีกประการหนึ่งของการเขียนโปรแกรม

เมื่อมีข้อสงสัยในภาษาเช่น C เขียนฟังก์ชั่นตัวช่วยและอินไลน์ถ้าคุณไม่ต้องการให้ค่าใช้จ่ายในการโทรออกไปยังฟังก์ชั่นอื่นและกระโดดกลับ ในกรณีส่วนใหญ่คอมไพเลอร์จะจัดการกับสิ่งต่าง ๆ อย่างชาญฉลาดสำหรับคุณ

— แดน Udey
แหล่งที่มา
2

มีคำตอบที่ดีมากมายเกี่ยวกับเรื่องนี้ แต่ก็มีค่าที่ควรกล่าวถึงใน IDE ของคุณคุณอาจมีรายการไฟล์ทางด้านซ้ายและรายการฟังก์ชันทางด้านขวา (หรือการกำหนดค่าอื่น ๆ )

รหัสของคุณเป็นเพียงส่วนหนึ่งของสภาพแวดล้อม

— ค่อนข้างดีน
แหล่งที่มา
2

ฉันไม่บังคับ 80 ตัวอักษรหมายถึงการตัดคำ
IMO ความยาวใด ๆ ที่เลือกสำหรับบรรทัดความกว้างสูงสุดไม่เหมาะสมเสมอไปและการตัดคำควรเป็นคำตอบที่เป็นไปได้
และนั่นไม่ง่ายอย่างที่คิด

มันถูกนำมาใช้ใน jedit (แหล่งที่มา: jedit.org ) ซึ่งมีการห่อคำข้อความแสดงแทน

แต่มันพลาดไปอย่างขมขื่นในสุริยุปราคาตั้งแต่เวลา looong ! (ตั้งแต่ปี 2003 ในความเป็นจริง) ส่วนใหญ่เป็นเพราะการห่อคำสำหรับโปรแกรมแก้ไขข้อความเกี่ยวข้องกับ:

  • ข้อมูลเส้นที่ถูกห่อไว้ใช้สำหรับโปรแกรมดูข้อความ, การนำทางด้วยรหัส, ไม้บรรทัดแนวตั้ง
  • จำเป็นต้องใช้ข้อมูลเส้นที่ไม่ห่อหุ้มสำหรับฟังก์ชันการทำงานเช่นสาย goto, คอลัมน์ไม้บรรทัดหมายเลขบรรทัด, การเน้นบรรทัดปัจจุบัน, การบันทึกไฟล์
— VonC
แหล่งที่มา
1

ที่จริงฉันทำตามกฎที่คล้ายกันสำหรับรหัสของตัวเอง แต่เพียงเพราะการพิมพ์รหัสไปยังหน้า A4 - 80 คอลัมน์เป็นเรื่องเกี่ยวกับความกว้างที่เหมาะสมสำหรับขนาดตัวอักษรที่ฉันต้องการ

แต่นั่นเป็นการตั้งค่าส่วนตัวและอาจไม่ใช่สิ่งที่คุณเป็นหลังจากนั้น (เนื่องจากคุณต้องการให้กระสุนไปทางอื่น)

สิ่งที่คุณไม่ถามเหตุผลที่อยู่เบื้องหลังการ จำกัด - อย่างจริงจังถ้าไม่มีใครสามารถเกิดขึ้นด้วยเหตุผลที่ดีว่าทำไมมันเป็นเช่นนั้นคุณมีกรณีที่ดีสำหรับการลบออกจากมาตรฐานการเข้ารหัสของคุณ

— paxdiablo
แหล่งที่มา
ฉันค่อนข้างแน่ใจว่ามันมาจากสมัยที่หน้าจอโหมดข้อความมีความกว้าง 80 ตัวอักษร
— TraumaPony
1

ฉันกระจายตัวตลอดทั้งวันและฉันไม่มีจอภาพ 22 นิ้วที่แปลกตา ฉันไม่รู้ว่าฉันจะ แน่นอนว่าสิ่งนี้มีความสนใจเพียงเล็กน้อยสำหรับโปรแกรมเมอร์ผู้เขียนเท่านั้นที่เพลิดเพลินกับการเข้ารหัสลูกศรและสาย 300-char

— คอนสแตนติ
แหล่งที่มา
1

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

— CobolGuy
แหล่งที่มา
0

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

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

— อูเน็ซิสต์
แหล่งที่มา
0

การทำลายที่ 80 ตัวอักษรเป็นสิ่งที่คุณทำในขณะที่การเข้ารหัสไม่ใช่หลังจากนั้น เหมือนกันกับความเห็นของหลักสูตร บรรณาธิการส่วนใหญ่สามารถช่วยคุณในการดูว่ามีขีด จำกัด 80 ตัวอักษรอยู่ที่ใด

(นี่อาจเป็น OT เล็กน้อย แต่ใน Eclipse มีตัวเลือกที่จัดรูปแบบรหัสเมื่อคุณบันทึก (ตามกฎใด ๆ ที่คุณต้องการ) นี่เป็นเรื่องประหลาดเล็กน้อยในตอนแรก แต่หลังจากนั้นไม่นานคุณก็เริ่มยอมรับว่า การจัดรูปแบบไม่อยู่ในมือของคุณเกินกว่ารหัสที่สร้างขึ้น)

— JesperE
แหล่งที่มา
0

ถ้าเรามีหนึ่งในนั้นเราจะไม่มีการสนทนานี้! ;-)

แต่ปัญหาที่ผู้คนยกมาในคำตอบของพวกเขาอย่างจริงจังนั้นค่อนข้างถูกกฎหมาย อย่างไรก็ตามโปสเตอร์ดั้งเดิมไม่ได้โต้แย้งกับข้อ จำกัด เพียงว่า 80 คอลัมน์มีน้อยเกินไป

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

ในฐานะที่เป็นสำหรับการพิมพ์ฉันมักจะพบว่าสาย 100 ตัวอักษรจะมากสะดวกสบายพอดีกับหน้าพิมพ์

— Andrew Edgecombe
แหล่งที่มา
0

ฉันพยายามเก็บบรรทัดต่ำกว่า 80 คอลัมน์ เหตุผลที่แข็งแกร่งที่สุดคือฉันมักพบว่าตัวเองกำลังใช้grepและlessเรียกดูรหัสของฉันเมื่อทำงานที่บรรทัดคำสั่ง ฉันไม่ชอบวิธีที่เทอร์มินัลทำลายเส้นซอร์สยาว ๆ อีกเหตุผลหนึ่งที่ฉันคิดว่ามันดูดีกว่านี้หากทุกอย่างเข้ากันได้ดีกับตัวแก้ไข ตัวอย่างเช่นการมีพารามิเตอร์ของฟังก์ชันที่มีการเรียกใช้แบบยาวนั้นอยู่ในแนวเดียวกันซึ่งคล้ายกัน

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