แนะนำตัวแปรท้องถิ่นเพิ่มเติมเป็นการแทนที่ความคิดเห็น

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

ตัวอย่างเช่น:

bool easyUnderstandableIsTrue = (/* rather cryptic boolean expessions */);

if(easyUnderstandableIsTrue)
{
    // ...
}

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

ค่าใช้จ่ายในการมีตัวแปรเพิ่มเติมคืออะไร ในภาษาส่วนใหญ่ไม่มีทั้งในภาษาที่แปลและแปล

ประโยชน์ของสิ่งนี้คืออะไร?

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

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

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

    // Find if the user is an actual author in order to allow her to edit the message.
    if (currentUser.isAdministrator || (message.author == currentUser && !message.locked))

นิพจน์อาจเริ่มต้นif (message.author == currentUser)จากนั้นพัฒนาเพื่อจัดการกรณีของข้อความที่ถูกล็อกและผู้ดูแลระบบที่ไม่จำเป็นต้องเป็นผู้เขียนและไม่สนใจเกี่ยวกับสิ่งที่ถูกล็อค อย่างไรก็ตามความคิดเห็นไม่ได้สะท้อนการเปลี่ยนแปลงเหล่านั้น

ผลประโยชน์ทั้งสองนั้นไม่ได้มีความสำคัญเป็นพิเศษ แต่ด้วยค่าใช้จ่ายเพิ่มเติมของตัวแปรที่ต่ำคุณอาจพิจารณาใช้มันอย่างแน่นอน

โปรดทราบว่าหากนิพจน์บูลีนของคุณซับซ้อนเกินไป: ²

• แตกออกเป็นวิธีแยกจากกันและ:
• ใส่เข้าไปใหม่ในนิพจน์บูลีนแบบง่าย ๆ

ตัวอย่างข้างต้นกลายเป็น:

class Message
{
    ...
    public boolean canBeEditedBy(User user)
    {
        ...
        if (user.isAdministrator) {
            return true;
        }

        return this.author == user && !this.locked;
    }
}

...
if (message.canBeEditedBy(currentUser)) // See? Much more readable now!
{
    ...
}

^{¹ที่มา: การสังเกตของฉันเองเกี่ยวกับเพื่อนร่วมงานของฉันในการพัฒนาซอฟต์แวร์ธุรกิจส่วนใหญ่ YMMV การวิจัยจริงอาจแสดงผลลัพธ์ที่แตกต่าง โดยส่วนตัวฉันคิดว่าเมื่อนักพัฒนาอ่านรหัสพวกเขากำลังมุ่งเน้นไปที่รหัสและความคิดเห็นเป็นเอกสารไม่ใช่รหัส; ดังนั้นพวกเขามักจะไม่อ่านความคิดเห็นดังนั้นจึงเป็นการยากที่จะคาดหวังให้พวกเขาอัปเดต}

^{²เกณฑ์ที่ซับซ้อนมากเกินไปถูกกำหนดด้วยสูตรง่ายๆ: หากครึ่งหนึ่งของผู้พัฒนาที่ตรวจสอบรหัสของคุณแสดงเจตนาที่จะสังหารคุณจะถึงขีด จำกัด ดังกล่าว นิพจน์บูลีนด้านบนนั้นง่ายพอที่จะต้องทำการเปลี่ยนใหม่ แม้กระนั้นสี่ส่วนในแถวif ((a && b) || (c && d))จะทำให้มันอาจ refactorable โปรดทราบว่าหากการแสดงออกแบนจำนวนชิ้นส่วนที่ไม่เกี่ยวข้อง: if (a || b || c || d || ... || z)สามารถอ่านได้เพียงพอ}