ไฟล์โค้ดมีขนาดใหญ่เกินไป?

36

ฉันกำลังค้นหาไฟล์บรรทัด 2-3k มากมายและมันก็ไม่ได้รู้สึกว่ามันควรจะใหญ่ขนาดนั้น

อะไรคือเกณฑ์ที่ดีในการโทรหาไฟล์ซอร์สโค้ดอย่างออบเจ็กต์ "ใหญ่เกินไป"?

code-quality code-smell

เพียร์ของคุณบอกคุณหลังจากตรวจสอบรหัส "คุณไม่สามารถตัดสินได้ด้วยตัวเองเพราะคุณรู้มากกว่าที่ผู้เขียนบอกไว้ในโค้ดคอมพิวเตอร์คอมพิวเตอร์ไม่สามารถบอกคุณได้ด้วยเหตุผลเดียวกับที่มันไม่สามารถบอกได้ว่าภาพวาดนั้นเป็นศิลปะหรือไม่ดังนั้นคุณต้องมีมนุษย์คนอื่น ของการบำรุงรักษาซอฟต์แวร์ - เพื่อดูสิ่งที่คุณเขียนและแสดงความคิดเห็นของเขาหรือเธอ ... "

— gnat

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

— mouviciel

2

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

— Ambroz Bizjak

โปรดทราบว่าความซับซ้อนไม่ได้เป็นเพียงแค่ตัวเลข แต่รวมถึงโครงสร้างด้วย ตัวอย่างเช่นฉันต้องการระบุ python zen "flat is better than nested": รายการแบบเรียบ 100 กรณีนั้นง่ายกว่าลำดับชั้น (คุณจำไม่ได้ทั้ง 100 กรณี แต่คุณจำได้ง่ายว่ามี 100 ทางเลือก) . และลำดับชั้น "ปกติ" ที่สาขามีโครงสร้างเดียวกันกว่าพี่น้องของพวกเขาจะง่ายกว่าลำดับชั้นที่มีโครงสร้างย่อยที่ผิดปกติ

— Juh_

"นั่นคือรหัสที่มาหรือไม่" "ไม่นั่นคือ makefile ซอร์สโค้ดอยู่ในรถบรรทุกตามหลัง"

— mckenzm

26

ในฐานะที่เป็นแบบอย่างที่ดีฉันใช้เกณฑ์ต่อไปนี้ (ด้วยเหตุผลที่คล้ายคลึงกับสิ่งที่ Martin Beckett แนะนำคือให้คิดในแง่ของโครงสร้างเชิงตรรกะและไม่ได้อยู่ในรูปของบรรทัดของโค้ด):

กฎข้อที่ 1

หนึ่งคลาสต่อไฟล์ (ใน C ++: หนึ่งคลาส -> หนึ่งส่วนหัวและหนึ่งไฟล์สำหรับการนำไปใช้)

กฎ 2

เซเว่นถือเป็นจำนวนรายการที่สมองของเราสามารถสังเกตได้ในเวลาเดียวกันโดยไม่สับสน ด้านบน 7 เราพบว่ามันยากที่จะเก็บภาพรวมของสิ่งที่เราเห็น ดังนั้น: แต่ละคลาสไม่ควรมีมากกว่า 7-10 วิธี คลาสที่มีมากกว่า 10 วิธีอาจซับซ้อนเกินไปและคุณควรพยายามแบ่งมัน การแยกเป็นวิธีที่มีประสิทธิภาพมากเพราะทุกครั้งที่คุณแบ่งชั้นเรียนคุณจะลดความซับซ้อนของแต่ละชั้นอย่างน้อยที่สุดด้วยปัจจัย 2

กฎข้อ 3

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

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

รวบรวมการประมาณคร่าวๆเหล่านี้เข้าด้วยกัน:

มากที่สุดหนึ่งคลาสต่อไฟล์ต้นฉบับ
สูงสุด 10 วิธีสาธารณะต่อชั้นเรียน
สูงสุด 10 วิธีส่วนตัวต่อชั้นเรียน
สูงสุด 100 บรรทัดต่อวิธี

ดังนั้นไฟล์ต้นฉบับที่มีมากกว่า 2000 บรรทัดอาจใหญ่เกินไปและเริ่มยุ่งเกินไป

นี่เป็นค่าประมาณคร่าวๆและฉันไม่ปฏิบัติตามเกณฑ์เหล่านี้อย่างเป็นระบบ (โดยเฉพาะอย่างยิ่งเนื่องจากมีเวลาไม่เพียงพอที่จะทำการปรับโครงสร้างที่เหมาะสม) นอกจากนี้ตามที่ Martin Beckett แนะนำไว้มีสถานการณ์ที่ชั้นเรียนเป็นชุดของวิธีการที่หลากหลายและมันก็ไม่สมเหตุสมผลที่จะแยกพวกมันออกเป็นบางส่วนด้วยวิธีประดิษฐ์เพื่อทำให้ชั้นเรียนเล็กลง

อย่างไรก็ตามในประสบการณ์ของฉันไฟล์จะเริ่มอ่านไม่ได้เมื่อไม่มีพารามิเตอร์ใดพารามิเตอร์หนึ่งข้างต้น (เช่นตัวเมธอด 300 บรรทัดที่ครอบคลุมหกหน้าจอหรือไฟล์ต้นฉบับที่มีรหัส 5000 บรรทัด)

— Giorgio
แหล่งที่มา

1

ฉันจะพยายามหาวิธีไม่เกิน 10 บรรทัด ... ช่วยด้วยความสามารถในการอ่าน / ทำความเข้าใจในสิ่งที่วิธีการทำและลดความซับซ้อนที่สามารถเกิดขึ้นได้อย่างง่ายดายในวิธีการขนาดใหญ่ ...

— Zack Macomber

4

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

— hasen

1

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

— JacquesB

1

@JacquesB 7 รายการมักจะบ่งบอกถึงข้อมูลที่ไม่เกี่ยวข้อง 7 ชิ้น หากสมองของคุณสามารถเชื่อมโยงหรือจัดกลุ่มข้อมูลในความเป็นจริงมันเป็นข้อมูล 1 ชิ้นที่สามารถนำไปสู่การมากขึ้นถ้าคุณพยายามเรียกคืน (ในความเป็นจริง "ตัวอักษร" เป็นสัญลักษณ์ไม่ใช่ทั้งหมด 26 ตัวอักษร) ตัวอย่างที่ดีกว่าคือพยายามจำหมายเลข 7 หลักที่บอกคุณทางโทรศัพท์โดยไม่ต้องใช้ปากกาและกระดาษ วิธีการที่ชัดเจนไม่ใช่ตัวเลขที่กำหนดเอง แต่ถ้าวิธีการเหล่านั้นเกี่ยวข้องกับสิ่งที่คุณเข้ารหัสคุณสามารถคาดหวังได้หลังจาก 7 คุณจะต้องค้นหาก่อนจึงจะสามารถเรียกคืนได้อย่างถูกต้อง

— Neil

3

@Neil: หากวิธีการในชั้นเรียนเป็นชิ้นส่วนของข้อมูลที่ไม่เกี่ยวข้องแบบสุ่มคุณจะมีปัญหาในการออกแบบชั้นเรียนมากกว่าจำนวนวิธี

— JacquesB

33

ไม่ - ไม่ได้อยู่ในบรรทัดของรหัส ไดรเวอร์ควรเป็นการจัดกลุ่มแบบลอจิคัล ไม่ควรมีหลายคลาสในไฟล์ขนาดใหญ่เพียงไฟล์เดียว

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

— Martin Beckett
แหล่งที่มา

2

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

— Tulains Córdova

2

@ user1598390: ปกติ แต่ไม่เสมอไป

— whatsisname

4

@ user1598390 - ทั่วไปในการสร้างแบบจำลองพูด gis / 3d มีจำนวนมากของการดำเนินการที่คุณสามารถดำเนินการแล้วมีพวกเขามากเกินไปสำหรับ 2d, 3d, 4d, 3d + สัญญาณแล้วลอย / สอง / จำนวนเต็ม ฯลฯ - แม่แบบช่วยเล็กน้อย แต่เพื่อประสิทธิภาพ การดำเนินการจำนวนมากมักจะดีกว่าการสืบทอดคลาสที่ดีงาม

— Martin Beckett

2

@ tp1 - และคุณใช้ฟอนต์เล็ก ๆ เพื่อไม่ให้ใช้พื้นที่มากพอ?

— Martin Beckett

2

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

— dukeofgaming

8

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

ตัวเลือกและฟีเจอร์ของ IDE / Editor ของคุณจะมีผลต่อปริมาณที่แท้จริงของขีด จำกัด บนนี้ การพับโค้ด , ฟังก์ชั่น / วิธีการรายชื่อและการค้นหาจะเลื่อนออกไปขณะที่การพัฒนานี้นำเสนอสถานการณ์

แต่เมื่อมันถึงเวลาที่จะแบ่งมัน

— ZJR
แหล่งที่มา

2

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

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

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

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

— วิลล์ไลลา
แหล่งที่มา

-1

Metaphorพิจารณานี้ เมื่อพูดถึงความยาวของรหัสฉันคิดว่าเราควรพิจารณาสิ่งต่อไปนี้:

The Cat in The Hat (50 pp.)

และ

Lord of The Rings (1,178 pp.)

Lord of the Ringsมีอะไรผิดปกติกับการเป็น มันเป็นหนังสือที่ยอดเยี่ยม The Cat in the Hatยังเป็นหนังสือที่ดี ทั้งคู่สามารถเข้าใจได้โดยเด็กอายุ 5 ปี แต่มีเพียงคนเดียวที่เหมาะสมกว่าเนื่องจากเนื้อหา

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

ส่วนใหญ่เราจะไม่ได้เขียนรหัสการชุมนุม แต่รากของรหัสของเราคือการชุมนุม การค้นหาแอสเซมบลี 10,000 บรรทัดนั้นยากกว่างูหลาม 10,000 บรรทัดหากทำอย่างถูกต้อง

แต่งานบางอย่างต้องเขียน 500 ถึง 1,000 บรรทัด เป้าหมายของเราด้วยรหัสควรเขียนโค้ดสะอาด 300 บรรทัด

ในฐานะนักพัฒนาเราต้องการเขียน "ลอร์ดออฟเดอะริงส์" จนกว่าเราจะได้รับข้อผิดพลาดและหวังว่าเราจะเขียน "Cat in the Hat" อย่าทำการเขียนโค้ดของอีโก้ เพียงแค่ทำให้สิ่งต่าง ๆ ทำงานในแบบง่าย ๆ

นักพัฒนาไม่ต้องการรหัสเอกสาร (ฉันชอบรหัสที่เป็นเอกสารส่วนตัวฉันไม่ใช่คนเห็นแก่ตัว) ดังนั้นอย่าเขียนโค้ดที่มีเพียงคุณเท่านั้นที่สามารถเข้าใจ / อ่านได้ เขียนCat in the Hatรหัส

เราทุกคนรู้ว่าคุณคือJRR Tolken (ในหัวของคุณ) จำไว้ว่าคุณจะไม่มีอะไรจะพิสูจน์ด้วยรหัสข้อผิดพลาดฟรี

อีกเหตุผลที่อุปมา

อย่า overkill ผู้อ่านกระจายความมั่งคั่ง หากคุณทำงานกับกลุ่มคนและพวกเขาทั้งหมดต้องเปลี่ยนไฟล์ขนาดใหญ่แบบเดียวกันคุณอาจจะทำให้ตัวเองตกอยู่ในgitนรก

ทุกคนรักการลดราคา

-> ไม่มีใครพูดเลย!

TL; DR เน้นที่ความสามารถในการอ่าน กระจายรหัสและผู้ช่วยเหลือของคุณผ่านหลายบรรทัดและไฟล์มากที่สุดเท่าที่จะทำได้ อย่าโยน 8 หรือ 9 คลาสในไฟล์เดียวมันทำให้โค้ดอ่านยากและยากต่อการบำรุงรักษา หากคุณมีรหัสเงื่อนไขหรือลูปขนาดใหญ่ให้ลองเปลี่ยนเป็น Lambdas หากภาษานั้นรองรับ ฟังก์ชั่นยูทิลิตี้ควรได้รับการพิจารณาว่าเป็นแนวทางที่ดีในการเพิ่มความสามารถในการอ่านโค้ด หลีกเลี่ยงการทำรังหนัก

— GetBackerZ
แหล่งที่มา

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

— อาหารสัตว์

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

— GetBackerZ

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

— อาหารสัตว์

ฉันใช้สคริปต์สำหรับ Jackie Brown เป็นปทัฏฐานสำหรับโปรแกรม COBOL z / OS แบบแยกส่วน คุณจะรู้ว่าสำหรับงานเลี้ยงค็อกเทล ...

— mckenzm

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

— whatsisname