การลดจำนวนบรรทัดในโค้ดมีความสำคัญอย่างไร

ฉันเป็นนักพัฒนาซอฟต์แวร์ที่ทำงานกับ J2SE (core java)
บ่อยครั้งในระหว่างการตรวจสอบรหัสของเราเราถูกขอให้ลดจำนวนบรรทัดในรหัสของเรา

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

คุณคิดว่าเป็นวิธีที่ถูกต้องในการทำสิ่งต่าง ๆ ?
หาก LOC (บรรทัดของรหัส) มีจำนวนน้อยจะมีผลกับรหัสอย่างไร หาก LOC เป็นจำนวนที่มากกว่าจะมีผลกับรหัสอย่างไร

ตัวอย่างจากเว็บไซต์: "javaranch" -

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

VS

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

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

การวัด SLOC (ซึ่งรีวิวของคุณกำลังทำอย่างมีประสิทธิภาพ) ทำให้ SLOC สำคัญ ... SLOC สำคัญหรือไม่ - ไม่อย่างที่ไม่เคยมีมาก่อน (นอกการแข่งขันการเขียนโปรแกรม Obfuscated ) จะไม่อยู่ในองค์กรเชิงพาณิชย์

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

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

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

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

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

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

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

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

เช่นเดียวกับเคน ธ อมป์สันเคยกล่าวไว้ว่าวันหนึ่งมีประสิทธิผลมากที่สุดของฉันถูกทิ้ง 1000 สายรหัส

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

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

ฉันจะยืนยันว่าสิ่งที่ดีกว่าสำหรับการตั้งเป้าหมายคือวิธีการสั้น ๆ ไม่สั้นเพื่อประโยชน์ของรหัสไม่กี่บรรทัด แต่สั้นเพราะพวกเขาทำสิ่งเดียว

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

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

จะไม่เป็นที่ยอมรับอย่างสมบูรณ์สำหรับฉันอย่างไรก็ตามฉันพบว่าการเปลี่ยนรหัส บริษัท ที่มีอยู่ทั้งหมดจาก:

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

ไปที่:

value.prop =  boolean ? option1 : option2;

เป็นตัวเลือกการย่อส่วนที่ยอดเยี่ยมที่ไม่ทำให้เสียการอ่าน

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

IMO เป็นความคิดที่ดีที่จะวัดประสิทธิผลของโค้ดด้วยการนับ LOC เล็กน้อย มีอะไรอีกมากมายที่ทำให้โค้ดถูกออกแบบและมีประสิทธิภาพ

จากประสบการณ์ของฉันรหัสที่มีประสิทธิภาพ:

• ไม่ทำลายหลักการ SOLIDใด ๆ
• สามารถอ่านได้และอธิบายตนเอง
• ผ่านการทดสอบความเรียบง่ายของ Albert Einstein: "ทุกสิ่งควรทำง่ายที่สุดเท่าที่จะทำได้ แต่ไม่ง่ายกว่านี้"

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

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

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

มีข้อดีที่ชัดเจนในการนับ LOC ต่ำ (วิธีการเล็ก ๆ ที่พอดีกับหัวของคุณง่ายกว่าวิธีที่ใหญ่กว่าสิ่งที่น้อยกว่าในรหัสหมายถึงสิ่งที่ผิดพลาดน้อยลง ฯลฯ ) แต่ก็เป็นไปตามกฎหมายว่าด้วยการลดผลตอบแทนด้วย การปรับเปลี่ยนวิธีการ 150 บรรทัดเป็นจำนวน 20 วิธีการนั้นเป็นการชนะที่ยิ่งใหญ่กว่าการทำการเปลี่ยนวิธี 10 บรรทัดเป็นวิธี 7 บรรทัด

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

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

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

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

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

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

ฉันคิดว่าคุณควรมุ่งมั่นที่จะมีฟังก์ชั่นที่มี SLOC จำนวนเล็กน้อย

หาก LOC (บรรทัดของรหัส) มีจำนวนน้อยจะมีผลกับรหัสอย่างไรและถ้า LOC เป็นจำนวนที่มากกว่าจะมีผลกับรหัสอย่างไร

เป็นการง่ายที่จะเข้าใจโค้ด 8 บรรทัดได้ง่ายกว่าที่ควรเข้าใจ 30

นั่นไม่ได้หมายความว่าการบีบอัด 30 LOC ใน 8 บรรทัดจะเข้าใจได้ง่ายขึ้น

คุณคิดว่าอะไรคือวิธีการทำสิ่งที่ถูกต้อง

โดยปกติในฟังก์ชั่นฉันพยายามจัดกลุ่มตามระดับของ abstraction ("รหัส IO ที่นี่", "การตรวจสอบที่นี่", "การคำนวณที่นี่" และอื่น ๆ )

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

ที่กล่าวว่าฉันมีฟังก์ชั่นที่มีการสกัดนี้แล้วและหลังจากนั้นฟังก์ชั่นนี้มีความยาว ~ 40 บรรทัด (รหัส C) หากรหัสถูกจัดกลุ่มมากที่สุดฉันไม่เห็นปัญหาเกี่ยวกับฟังก์ชั่นอีกต่อไป

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

บูลีน sweet_sixteen = (อายุ == 16);

ซ้ำซ้อนสวย ทุกคนที่อ่าน "อายุ == 16" รู้ว่า ฉันอยากจะเขียนโค้ดแบบนี้:

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

ตรรกะเกี่ยวกับการตัดสินใจว่าจะโยนปาร์ตี้เมื่อใดจะแยกจาก System.out สามารถทดสอบได้และง่ายต่อการเข้าใจ ที่สำคัญกว่านั้นบางคนที่อ่านรหัสสามารถเข้าใจเหตุผลที่เขียนขึ้นมาได้ ("บริษัท ต้องการจัดงานเลี้ยงใหญ่สำหรับบางคน")

ฉันคิดว่าบรรทัดของโค้ดน้อยลง = อ่านได้มากขึ้น

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

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

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

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

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

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

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

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

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

นอกจากนี้ยังสามารถมีอิทธิพลต่อการออกแบบและการเลือกภาษา: การลดคะแนนฟังก์ชั่นหรือเปลี่ยนเป็นภาษาที่มี LOC / FP ต่ำกว่าควรลดความพยายามของโครงการ

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

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

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

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

ปัญหาที่ยอดเยี่ยมกับการประเมินโค้ดทุกวิธีอย่างเป็นทางการคือมันจะล้มเหลวในบางโค้ด เนื่องจากการเขียนโปรแกรมเป็นงานศิลปะชนิดหนึ่งดังนั้นจึงไม่มีมาตรฐานที่ชัดเจนสำหรับการประเมินผล แน่นอนว่ามีศิลปะหลายประเภท - การผลิตภาพเขียนจำนวนมากก็มีอยู่และบางทีในธุรกิจนี้ก็มีความสำคัญว่ามีการใช้สีจำนวนเท่าใดในการวาดภาพหนึ่งภาพ :)

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

ฉันยอมรับว่าการลด LOC เสมอจะทำให้รหัสอ่านยาก

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

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

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

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

แก้ไข

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

พิจารณาต่อไปนี้:

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

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

• การตรวจสอบข้อผิดพลาด, การทำความสะอาด ฯลฯ ทั้งหมดเพิ่มบรรทัดของรหัสและผมค่อนข้างแน่ใจว่าแม้แต่แฟนกระตือรือร้นมากที่สุดของสายน้อยลงรหัสจะไม่เถียงกับผู้

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

ดังนั้นการรับประกันรหัสน้อยลง มีรหัสน้อยลงนั่นคือทั้งหมด

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

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

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

1. ทำผังปัญหาของคุณ
2. พยายามใช้จำนวนลูปน้อยลงเท่าที่จะทำได้
3. ฟังก์ชั่นการโทรไม่ควรมาก
4. โครงสร้างข้อมูลใหม่เช่น TRIE ควรใช้ในกรณีที่สแต็กหรือคิวใช้สำหรับจัดเก็บข้อมูลที่เกี่ยวข้อง
5. และพยายามแก้ปัญหาด้วยวิธีที่เป็นจริงมากกว่าที่จะจินตนาการซึ่งคุณกำลังเก็บตัวเลขจำนวนมากไว้ในอาเรย์ที่มีขนาดใหญ่มากจากนั้นลองเข้าถึงมันผ่านอาเรย์]
6. ใช้มาโครให้ได้มากที่สุดวิธีการใช้งานยังขึ้นอยู่กับปัญหาด้วยถ้ามันซับซ้อนจริง ๆ แล้วบางครั้งการใช้วิธีง่าย ๆ ก็เทียบเท่ากับคอมเพล็ก