ขีด จำกัด 80 อักขระยังคงมีความเกี่ยวข้องในช่วงเวลาของจอภาพแบบจอกว้างหรือไม่ [ปิด]


56

บนหน้าจอไวด์สกรีนสามารถดูได้ครั้งละ 80 ตัวอักษรโดยไม่ต้องใช้แถบเลื่อน แม้ Linus Torvalds เห็นขีด จำกัด 80 ตัวอักษรเป็นล้าสมัย

ดังนั้นขีด จำกัด 80 อักขระยังคงเกี่ยวข้องในช่วงเวลาของจอภาพแบบจอกว้างหรือไม่


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

ในบริบทใด หากคุณถามในบริบทการเขียนโปรแกรมเฉพาะฉันจะลงคะแนนเพื่อเปิดใหม่
นิโคล


การตัดคำของ Visual Studio ใช้งานไม่ได้ดังนั้นผู้ใช้ส่วนใหญ่จึงไม่ใช้งาน พวกเขาวางสายด้วยมือแทน สิ่งนี้ดูน่ากลัวสำหรับทุกคนที่มีหน้าจอกว้างแตกต่างกัน visualstudio.uservoice.com/forums/121579-visual-studio/…
Colonel Panic

คำตอบ:


28

มีเหตุผลหลายประการที่จะยังคงปฏิบัติตามขีด จำกัด ของอักขระ 80 ตัว (หรือจำกัดความยาวของอักขระ 74 ตัวได้ดียิ่งขึ้นทำให้โค้ดยังคงอยู่น้อยกว่า 80 คอลัมน์แม้ว่าจะมีการเพิ่มตัวบ่งชี้ที่แตกต่างกันและการอ้างอิงอีเมล รายชื่อผู้รับจดหมาย)

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

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

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

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

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


3
ตกลง อย่างไรก็ตามบางครั้งตัวบ่งชี้ที่ยาวได้รับการสนับสนุน (โดยแนวทางการเข้ารหัสเช่น "ใช้ชื่อที่มีความหมาย" หรือ "หลีกเลี่ยงตัวย่อแบบเข้ารหัสลับ") หรือจำเป็น (เช่นstd::vector<...>::const_iterator) แม้ว่าในกรณีหลังสิ่งต่าง ๆ สามารถบรรเทาได้โดย typedefs
musiphil

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

1
@musiphil ใช่นั่นคือเหตุผลที่ฉันรวมวรรคสุดท้าย ฉันพบบรรทัดใน C ++ โดยที่ฉันไม่สามารถใส่ชื่อคลาสชื่อเมธอดและชนิดส่งคืนในบรรทัด 80 คอลัมน์เดียวเมื่อประกาศวิธีนั้น แทนที่จะทำตัวแบ่งบรรทัดแปลกจริง ๆ จะเป็นการดีกว่าที่จะแบ่งกฎ 80 คอลัมน์ (หรือ 100 คอลัมน์) สำหรับหนึ่งบรรทัด
Brian Campbell

46

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

80 ตัวอักษรอาจล้าสมัย แต่มีข้อดีบางประการในการรักษาสิ่งต่าง ๆ ด้วยเหตุผล


1
+1, ฉันเปิดไฟล์ต้นฉบับหลายไฟล์แบบเคียงข้างกันใน Vim หรือโปรแกรมแก้ไขอื่น ๆ ด้วยตัวอักษรที่มีขนาดเล็กเพียงพอและมีระยะขอบที่แคบพอสมควรฉันสามารถดูภาพรวมของโครงการได้อย่างรวดเร็วและเปิดเอกสารจำนวนมาก
greyfade

4
80 ตัวอักษรยังคงมีความเกี่ยวข้องเพราะหลายคนเริ่มต้นที่จะมีเทอร์มินัลและบรรณาธิการที่กว้าง; ดังนั้นหากคุณ จำกัด ตัวคุณไว้ที่ 80 คุณจะเป็นมิตรกับคนเหล่านั้นซึ่งต่างจากการกำหนดให้พวกเขาจัดเรียงหน้าต่างทั้งหมดใหม่หรือจัดการกับการตัดบรรทัดหรือเลื่อนแนวนอน
Brian Campbell

1
80 ตัวอักษรยังคงมีเหตุผล; การใช้เวลานานกว่านั้นจะเป็นการสนับสนุนโค้ดที่ซ้อนกัน (แทนที่จะทำการปรับโครงสร้างใหม่!) และการมีหลาย ๆ หน้าต่างเคียงข้างกันนั้นมีประโยชน์เป็นพิเศษ การเพิ่มจอภาพอื่นเพียงเพิ่มจำนวนหน้าต่างที่คุณเห็นในครั้งเดียว!
Donal Fellows

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

29

ฉันไม่คิดว่าจอภาพมีส่วนเกี่ยวข้องกับมัน - อย่างน้อยก็ไม่มีอีกต่อไป

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

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

ฉันเกลียดสิ่งนี้โดยส่วนตัว:

ret = my_function(parameter1, \
                  parameter2, \
                  parameter3, parameter4);

แทนที่จะเป็นเพียง:

ret = my_function(parameter1, parameter2, parameter3, parameter4);

5
แน่นอนถ้าบรรทัดที่ 3 ในตัวอย่างแรกไม่ยาวเกินไปบรรทัดที่ 2 สามารถรวมกันเป็นบรรทัดที่ 1 ซึ่งทำให้อ่านง่ายขึ้น (ภาษาใดต้องมีการขึ้นบรรทัดใหม่ภายในวงเล็บ)

1
อ่านั่นเป็นเพียงรหัสหลอกที่ฉันเขียน แต่ฉันคิดว่า C ต้องการมัน
Cesar Canassa

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

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

20

เพื่อเข้ารหัส?

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


3
ในขณะที่ฉันรู้สึกว่ารหัสนั้นแตกต่างจากร้อยแก้วมาก แต่ก็เหนื่อยที่จะอ่านโค้ดที่เป็นระยะ ๆ

6

ใช่มีเหตุผลที่จะจำกัดความยาวของรหัสบรรทัด:

  1. แม้ว่าหน้าจอของเราจะกว้าง แต่บางครั้งคุณจำเป็นต้องพิมพ์รหัสของคุณ ถ้าเพียงเพราะเหตุนี้
  2. ผู้ดู Diff มักจะแสดงเส้นที่มีการแบ่งตามแนวตั้ง - มันจะยากขึ้นหากบรรทัดนั้นยาวเท่าที่หน้าจอกว้างจะอนุญาต

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

ฉันจะบอกว่าสายยาวเป็นพิเศษไม่ควรถูกห้ามเพราะบางครั้งพวกเขาก็มีความจำเป็น แต่ถ้าฟังก์ชั่นส่วนใหญ่สามารถดูได้บนหน้าจอ 30 นิ้วเท่านั้นรหัสก็มีปัญหาบางอย่าง


5

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


3

อาจไม่เกี่ยวข้องกับการเลือกความยาวสูงสุด 80 อักขระ สิ่งที่จะเปลี่ยนแปลงหากขีด จำกัด คือ 85 เช่น?

เป็นความจริงที่ว่าจอภาพที่ใช้ในปัจจุบันมีความละเอียดสูงกว่า แต่ใน text editor / IDE ไม่ใช่ว่าพื้นที่ทั้งหมดมาจากมุมมองข้อความ ในโปรแกรมแก้ไขฉันใช้การแสดงทางด้านซ้ายรายการไฟล์ที่รวมอยู่ในโครงการ

ความละเอียดที่ใช้ในเน็ตบุ๊กหรือโน้ตบุ๊กไม่เหมือนกับที่ใช้ในจอภาพ มันอาจสมเหตุสมผลที่จะใช้การ จำกัด อักขระที่ไม่สร้าง "ปัญหา" ให้กับทุกคน


5
80 ตัวอักษรเป็นจำนวน จำกัด ของจำนวนคอลัมน์ในบัตรเจาะ!
ChrisF

5
ไม่สำคัญว่ามาตรฐานคืออะไร แต่ถ้าทุกคนทำงานได้มาตรฐานเดียวกันมันจะทำให้ชีวิตง่ายขึ้น
Skilldrick

2

มันขึ้นอยู่กับสภาพแวดล้อมการพัฒนา

ตัวอย่างเช่นใน บริษัท ขนาดใหญ่ที่มีนักพัฒนาหลายพันคนอาจจะมีหลายร้อยคนที่จะต้องดูรหัสบางส่วนในช่วงชีวิตของผลิตภัณฑ์ กับคนจำนวนมากนั้นมีบางคนที่มีเหตุผลไม่ว่าจะเป็นฮาร์ดแวร์ (เน็ตบุ๊กรุ่นเก่าเน็ตบุ๊ค ฯลฯ ) ทำงานที่ 800x600 หรือเล็กกว่า มีคุณค่าในการรองรับพวกเขา

อย่างไรก็ตามที่ บริษัท 25 คนของฉันฉันพูดว่ากรู เราทุกคนใช้จอภาพคู่ที่ทันสมัยที่ความละเอียดสูงสุด 120-140 หรือเป็นแนวทางที่ไม่เป็นทางการ


2

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

ฉันเชื่อว่าการอ่านโค้ดง่ายกว่าความกังวลอื่น ๆ ทั้งหมด และด้วย 96 ตัวอักษรต่อรหัสบรรทัดสามารถทำให้อ่านได้มากกว่า 80

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


1

ไม่มันไม่มีความเกี่ยวข้องอีกต่อไป:

  • แบบอักษรส่วนใหญ่ที่ใช้ในแอปพลิเคชันและบนเว็บนั้นไม่ได้มีความกว้างคงที่ กล่าวอีกนัยหนึ่งคือ 80 ตัวอักษร! = 80 ตัวอักษร
  • อย่างที่คุณพูดความกว้างของหน้าจอเปลี่ยนไป - 80 ตัวอักษรไม่ใช่ขอบเขตที่สมเหตุสมผล

80 ตัวอักษรเป็นแนวทางสำหรับฟอนต์ที่มีความกว้างคงที่ในสภาพแวดล้อมคอนโซล

แน่นอนถ้าคุณยังคงใช้ฟอนต์ที่มีความกว้างคงที่ในระบบคอนโซล ... แน่นอนว่า 80 ตัวอักษรเหมาะสมแล้ว :)


3
ฉันค่อนข้างแน่ใจว่าเขาอ้างถึงการใช้ขีด จำกัด 80 อักขระในซอร์สโค้ดซึ่งเกือบจะถูกแสดงแบบสากลในแบบอักษรที่มีช่องว่าง
Fishtoaster

1
อืม ... ในกรณีที่ว่า ... ยังคงไม่ แต่สำหรับเหตุผลอื่น ๆ :)
Damovisa

1
80 ตัวอักษรเป็นจำนวน จำกัด ของจำนวนคอลัมน์ในบัตรเจาะ!
ChrisF

0

หากคุณใช้โปรแกรมแก้ไขใน GUI ดังนั้น 80 ตัวอักษรต่อบรรทัดจะไม่เกี่ยวข้องเนื่องจากบรรณาธิการที่ดีที่สุดเช่น Notepad ++ มีปุ่มเพื่อสลับการตัดบรรทัด ด้วยสิ่งนี้จึงไม่น่ามีปัญหาแม้เมื่อดูรหัสในหน้าต่างที่บาง

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