ใน การเขียน โปรแกรมคอมพิวเตอร์ โค้ดที่ใหญ่เกินไป ( code bloat ) คือการสร้างโค้ดที่สามารถเรียกใช้งานได้ ( โค้ดต้นฉบับหรือโค้ดเครื่อง ) ที่ยาว ช้า หรือสิ้นเปลืองทรัพยากรโดยไม่จำเป็น โค้ดที่ใหญ่เกินไปอาจเกิดจากข้อบกพร่องในภาษาโปรแกรมที่ใช้เขียนโค้ด คอมไพเลอร์ที่ใช้ในการคอมไพล์ หรือโปรแกรมเมอร์ที่เขียนโค้ดนั้น ดังนั้น แม้ว่าโดยทั่วไปแล้วโค้ดที่ใหญ่เกินไปจะหมายถึงขนาดของโค้ดต้นฉบับ (ตามที่โปรแกรมเมอร์สร้างขึ้น) แต่ก็สามารถใช้เพื่ออ้างถึงขนาดของ โค้ด ที่สร้างขึ้นหรือแม้แต่ขนาดของไฟล์ไบนารีได้ เช่นกัน ^{[ 1 ] [ 2 ]}

อัลกอริทึมต่อไปนี้เขียนด้วยJavaScriptและสามารถสร้าง แท็ก HTML <img> ตามข้อมูลที่ผู้ใช้ป้อนได้ แต่มี โค้ดที่ซ้ำซ้อนจำนวนมากเช่น ตรรกะและตัวแปร ที่ไม่จำเป็น รวมถึงการต่อสตริง ที่ ไม่ ประสิทธิภาพ

// ฟังก์ชันที่ซับซ้อนTK2getImageHTML ( size , zoom , sensor , markers ) { const strHTMLStart = '<img src="' ; const strHTMLEnd = '" alt="The map"/>' ; var strFinalImage = "" ; var strURL = "https://example.com/staticmap?center=" ; var strSize = '&size=' + size ; var strZoom = '&zoom=' + zoom ; var strSensor = '&sensor=' + sensor ; strURL += markers [ 0 ]. latitude ; strURL += "," ; strURL += markers [ 0 ]. longitude ; strURL += strSize ; strURL += strZoom ; strURL += strSensor ; สำหรับ( var i = 0 ; i < markers .length ; i ++ ) { strURL + = markers [ i ] เพิ่มเครื่องหมาย(); } strFinalImage = strHTMLStart + strURL + strHTMLEnd ; กลับstrFinalImage ; }

อัลกอริทึมเดียวกันข้างต้นสามารถเขียนใหม่ให้มีความซ้ำซ้อนน้อยลงและมีประสิทธิภาพมากขึ้นได้ดังนี้ (แม้ว่าจะอ่านยากกว่าก็ตาม):

// ฟังก์ชันTK2getImageHTML ที่เรียบง่าย ( sz , zm , sens , mks ){ let url = "" mks . forEach ( mk => url += mk . addMarker ()) return `<img src="https://example.com/staticmap?center= ${ mks [ 0 ]. latitude } , ${ mks [ 0 ]. longitude } &size= ${ sz } &zoom= ${ zm } &sensor= ${ sens }${ url } " alt="แผนที่">` }

การนำ กลไก การเขียนโปรแกรมทั่วไปมาใช้มีอิทธิพลอย่างมากต่อขนาดไบนารีที่ได้ ภาษาโปรแกรมเช่นC++ใช้แนวทาง "stenciling" หรือ monomorphization สำหรับเทมเพลต โดยที่คอมไพเลอร์จะสร้างสำเนาโค้ดแยกต่างหากสำหรับแต่ละประเภทข้อมูลที่แตกต่างกันที่ใช้ แม้ว่าวิธีนี้จะช่วยลดภาระการทำงานและอนุญาตให้มีการเพิ่มประสิทธิภาพเฉพาะ แต่ก็มักจะนำไปสู่โค้ดที่บวมเมื่อมีการสร้างอินสแตนซ์ของประเภทต่างๆ จำนวนมาก ในทางกลับกัน ภาษาเช่นJavaมักใช้การลบประเภท โดยใช้สำเนาโค้ดที่คอมไพล์แล้วเพียงชุดเดียวสำหรับทุกประเภทข้อมูลโดยการถือว่าพวกมันเป็นวัตถุทั่วไป (เช่น ผ่านการ boxing) แนวทางนี้ช่วยลดขนาดโค้ด แต่สามารถทำให้เกิดภาระประสิทธิภาพการทำงานเนื่องจากความจำเป็นในการส่งแบบไดนามิกหรือการ unboxing ^{[ 1 ]}

ความแตกต่างของความหนาแน่นของโค้ดระหว่างภาษาคอมพิวเตอร์ ต่างๆ นั้น มีมาก จนบ่อยครั้งที่หน่วยความจำที่จำเป็นในการจัดเก็บโปรแกรมที่เขียนด้วยภาษา "ขนาดกะทัดรัด" (เช่นภาษาโปรแกรมเฉพาะโดเมน , Microsoft P-Codeหรือโค้ดแบบมัลติเธรด ) รวมกับตัวแปลภาษาสำหรับภาษาขนาดกะทัดรัดนั้น (ที่เขียนด้วยโค้ดเนทีฟ) น้อยกว่าการจัดเก็บโปรแกรมที่เขียนด้วยโค้ดเนทีฟ โดยตรงเสีย อีก

เทคนิคบางอย่างสำหรับการลดขนาดโค้ด ได้แก่: ^{[ 3 ]}

• การปรับโครงสร้างโค้ด (Refactoring)ลำดับโค้ดที่ใช้บ่อยให้เป็นซับรูทีนและเรียกใช้ซับรูทีนนั้นจากหลายตำแหน่ง แทนที่จะคัดลอกและวางโค้ดในแต่ละตำแหน่งเหล่านั้น ( การเขียนโปรแกรมแบบคัดลอกและวาง )
• การนำซับรูทีนที่เขียนไว้แล้วมาใช้ซ้ำ (อาจมีการเพิ่มพารามิเตอร์เพิ่มเติม) แทนที่จะเขียนใหม่ทั้งหมดตั้งแต่ต้นในฐานะรูทีนใหม่
• การผสมผสานการวิเคราะห์โปรแกรมเพื่อตรวจจับโค้ดที่เกินความจำเป็น เข้ากับการแปลงโปรแกรมเพื่อลบโค้ดที่เกินความจำเป็นเหล่านั้น
• ปิดใช้งาน/ลบการปรับแต่งโปรแกรมบางอย่าง เนื่องจากอาจส่งผลเสียต่อประสิทธิภาพการทำงานได้
• การใช้โปรแกรมย่อ/เข้ารหัสโค้ดที่ตัดช่องว่าง/การเยื้องที่ไม่จำเป็น และสิ่งอื่นๆ ที่ไม่สำคัญต่อการทำงานของโปรแกรมออกไป

คอมไพเลอร์ใช้เทคนิคต่างๆ เพื่อลดปัญหาโค้ดบวม เช่นการกำจัดโค้ดที่ ไม่ใช้งาน (DCE) ซึ่งตรวจจับและลบคำสั่งที่ไม่มีผลต่อผลลัพธ์ของโปรแกรม อย่างไรก็ตาม เป้าหมายในการลดขนาดโค้ดมักขัดแย้งกับความเร็วในการประมวลผล กลยุทธ์การเพิ่มประสิทธิภาพ เช่นการคลายลูปและการแทรกฟังก์ชันสามารถปรับปรุงประสิทธิภาพการทำงานได้อย่างมาก แต่จะทำให้ขนาดของไบนารีเพิ่มขึ้นอย่างหลีกเลี่ยงไม่ได้เนื่องจากลำดับคำสั่งซ้ำกัน^{[ 4 ]}

ในระบบนิเวศซอฟต์แวร์สมัยใหม่ที่พึ่งพาตัวจัดการแพ็กเกจของบุคคลที่สามอย่างมาก (เช่นMavenหรือnpm ) "การเพิ่มขนาดของส่วนประกอบที่พึ่งพา" ได้กลายเป็นปัญหาที่แพร่หลาย ปัญหานี้เกิดขึ้นเมื่อแอปพลิเคชันรวมไลบรารีทั้งหมด แต่ใช้เพียงส่วนเล็ก ๆ ของฟังก์ชันการทำงานเท่านั้น การศึกษาเชิงประจักษ์แสดงให้เห็นว่าเทคนิค "การลดขนาด" แบบอัตโนมัติ ซึ่งวิเคราะห์กราฟการเรียกของแอปพลิเคชันเพื่อลบไบต์โค้ดหรือคลาสที่ไม่ได้ใช้จากการสร้างขั้นสุดท้าย สามารถลดขนาดของแพ็กเกจซอฟต์แวร์ได้อย่างมากโดยไม่เปลี่ยนแปลงพฤติกรรม^{[ 2 ]}การพึ่งพาส่วนประกอบที่พึ่งพาอย่างมากอาจก่อให้เกิดปัญหาอื่น ๆ นอกเหนือจากการเพิ่มขนาด ดังที่แสดงให้เห็นจากเหตุการณ์ left-pad ของ NPM

• การกำจัดโค้ดที่ไม่ได้ใช้งาน
• ความเรียบง่าย (ด้านคอมพิวเตอร์)
• มุนท์ซิง
• โพลีมอร์ฟิซึม (วิทยาการคอมพิวเตอร์)
• การเพิ่มประสิทธิภาพซอฟต์แวร์
• ซอฟต์แวร์ที่ใหญ่เกินไป
• ซอฟต์แวร์น้ำหนักเบา