มันสมเหตุสมผลที่จะป้องกัน null ทุกตัวชี้ dereferenced หรือไม่

ในงานใหม่ฉันได้รับการตั้งค่าสถานะในการตรวจสอบรหัสสำหรับรหัสเช่นนี้:

PowerManager::PowerManager(IMsgSender* msgSender)
  : msgSender_(msgSender) { }

void PowerManager::SignalShutdown()
{
    msgSender_->sendMsg("shutdown()");
}

ฉันบอกว่าวิธีสุดท้ายควรอ่าน:

void PowerManager::SignalShutdown()
{
    if (msgSender_) {
        msgSender_->sendMsg("shutdown()");
    }
}

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

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

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

แก้ไข : ในตัวอย่างข้างต้นผู้msgSender_ทำงานร่วมกันไม่จำเป็น หากเป็นNULLไปได้แสดงว่ามีข้อผิดพลาด เหตุผลเดียวที่ส่งผ่านไปยัง Constructor นั้นPowerManagerสามารถทดสอบได้ด้วยIMsgSenderคลาสย่อยจำลอง

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

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

มันขึ้นอยู่กับ 'สัญญา':

หากPowerManager ต้องมีข้อมูลที่ถูกต้องIMsgSenderอย่าตรวจสอบ null ให้ปล่อยให้มันตายเร็วขึ้น

หากในอีกทางหนึ่งมันอาจมีIMsgSenderแล้วคุณต้องตรวจสอบทุกครั้งที่คุณใช้ง่ายเหมือนที่

ความคิดเห็นสุดท้ายเกี่ยวกับเรื่องราวของโปรแกรมเมอร์รุ่นจูเนียร์ปัญหาคือการขาดขั้นตอนการทดสอบ

ฉันรู้สึกว่ารหัสควรอ่าน:

PowerManager::PowerManager(IMsgSender* msgSender)
  : msgSender_(msgSender)
{
    assert(msgSender);
}

void PowerManager::SignalShutdown()
{
    assert(msgSender_);
    msgSender_->sendMsg("shutdown()");
}

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

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

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

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

หาก msgSender ไม่เคยเป็นnullคุณควรใส่nullเช็คในคอนสตรัคเตอร์เท่านั้น สิ่งนี้ก็เป็นจริงเช่นกันสำหรับอินพุตอื่น ๆ ในคลาส - ใส่การตรวจสอบความสมบูรณ์ ณ จุดที่เข้าสู่ 'โมดูล' - คลาส, ฟังก์ชั่น ฯลฯ

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

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

ไม่มีก็ไม่สมเหตุสมผลที่จะตรวจสอบแต่ละคนและทุกตัวชี้ dereference NULLสำหรับเป็นตัวชี้

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

หากฉันเผชิญกับสถานการณ์เช่นคุณฉันจะถามคำถามสองข้อ:

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

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

ในสถานการณ์เช่นนี้ฉันต้องการเปลี่ยนอินเทอร์เฟซเพื่อให้ความต้องการของผู้โทรถูกบังคับใช้โดยภาษา:

PowerManager::PowerManager(const IMsgSender& msgSender)
  : msgSender_(msgSender) {}

void PowerManager::SignalShutdown() {
    msgSender_->sendMsg("shutdown()");
}

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

นอกจากนี้คุณยังสามารถเขียนสิ่งเดียวกันโดยใช้ตัวชี้อัจฉริยะ (ผ่านการเพิ่มหรือ c ++ 11) เพื่อบังคับIMsgSenderให้ใช้งานได้นานกว่าPowerManager:

PowerManager::PowerManager(std::shared_ptr<IMsgSender> msgSender) 
  : msgSender_(msgSender) {}

void PowerManager::SignalShutdown() {
    // Here, we own a smart pointer to IMsgSender, so even if the caller
    // destroys the original pointer, we still have a valid copy
    msgSender_->sendMsg("shutdown()");
}

วิธีนี้เป็นที่ต้องการหากเป็นไปได้ที่IMsgSenderจะไม่สามารถรับประกันได้ว่าอายุการใช้งานจะนานกว่าPowerManager(เช่นx = new IMsgSender(); p = new PowerManager(*x);)

†ในเรื่องเกี่ยวกับพอยน์เตอร์: การตรวจสอบโมฆะอาละวาดทำให้การอ่านโค้ดยากขึ้นและไม่ปรับปรุงเสถียรภาพ (มันช่วยปรับปรุงลักษณะที่ปรากฏของความเสถียร

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

เนื่องจาก the PowerManagerไม่ได้เป็นเจ้าของIMsgSender(มันแค่ยืมมาระยะหนึ่ง) มันจะไม่รับผิดชอบในการจัดสรรหรือทำลายหน่วยความจำนั้น นี่คืออีกเหตุผลหนึ่งที่ฉันชอบการอ้างอิง

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

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

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

เมื่อใดก็ตามที่มีการเรียกใช้ฟังก์ชั่นและไม่ใช่พฤติกรรมที่เป็นตัวเลือกมันควรล้มเหลวอย่างมาก

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

กับคนอื่น ๆ ได้ตั้งข้อสังเกตนี้ขึ้นอยู่กับว่าหรือไม่msgSenderสามารถที่จะถูกต้องตามกฎหมาย NULLต่อไปนี้จะถือว่าไม่ควรเป็น NULL

void PowerManager::SignalShutdown()
{
    if (!msgSender_)
    {
       throw SignalException("Shut down failed because message sender is not set.");
    }

    msgSender_->sendMsg("shutdown()");
}

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

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

วิธีใดวิธีหนึ่งเหล่านี้จะหลีกเลี่ยงความล้มเหลวที่เงียบ:

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

2. โยนข้อยกเว้นถ้ามันเป็นโมฆะ

ฉันเห็นด้วยกับดักโมฆะในตัวสร้าง เพิ่มเติมหากสมาชิกถูกประกาศในส่วนหัวเป็น:

IMsgSender* const msgSender_;

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

นี่เป็นอันตรายจริงๆ!

ฉันทำงานภายใต้นักพัฒนาอาวุโสใน C codebase ด้วย "มาตรฐาน" shoddiest ที่ผลักดันให้ทำสิ่งเดียวกันเพื่อตรวจสอบตัวชี้ทั้งหมดว่าไม่มีค่า นักพัฒนาจะต้องทำสิ่งต่าง ๆ เช่นนี้:

// Pre: vertex should never be null.
void transform_vertex(Vertex* vertex, ...)
{
    // Inserted by my "wise" co-worker.
    if (!vertex)
        return;
    ...
}

ฉันเคยลองลบการตรวจสอบเงื่อนไขเบื้องต้นหนึ่งครั้งในฟังก์ชั่นดังกล่าวและแทนที่ด้วยการassertดูว่าจะเกิดอะไรขึ้น

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

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

มันใช้เวลาเพียงสองบรรทัดของโค้ดที่ดูเหมือนไร้เดียงสาเช่นนี้ + เวลาและทีมจะจบลงด้วยการปิดบังข้อบกพร่องที่สะสมไว้นับพัน

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

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

มันเป็นเหตุผลที่มาตรฐานการเข้ารหัสที่จะต้องตรวจสอบทุกตัวชี้ dereferenced ในฟังก์ชั่นสำหรับ NULL แรก - แม้แต่สมาชิกข้อมูลส่วนตัว?

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

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

ยกตัวอย่างเช่นObjective-Cใช้การเรียกใช้เมธอดบนnilอ็อบเจ็กต์เป็น no-op ที่ประเมินค่าเป็นศูนย์ มีข้อดีบางประการในการตัดสินใจออกแบบใน Objective-C เนื่องจากเหตุผลที่แนะนำในคำถามของคุณ แนวคิดเชิงทฤษฎีของการป้องกันค่าว่างทุกการเรียกใช้เมธอดมีข้อดีอยู่บ้างหากมีการเผยแพร่และนำไปใช้อย่างต่อเนื่อง

ที่กล่าวว่ารหัสชีวิตในระบบนิเวศไม่ใช่สุญญากาศ พฤติกรรมที่มีการป้องกันแบบ null จะไม่เป็นไปในทางที่ผิดและน่าประหลาดใจใน C ++ ดังนั้นจึงควรถือว่าเป็นอันตราย โดยสรุปแล้วไม่มีใครเขียนรหัส C ++ ด้วยวิธีนี้ดังนั้นอย่าทำ! อย่างไรก็ตามตามตัวอย่างเคาน์เตอร์โปรดทราบว่าการโทรfree()หรือdeleteบนNULLใน C และ C ++ รับประกันว่าจะไม่ใช้งาน

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

ยิ่งไปกว่านั้นสร้างควรยอมรับการอ้างอิงที่ไม่อาจจะconst IMsgSender&NULL

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

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

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

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

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

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

เมื่อเลือกระหว่างตัวชี้และการอ้างอิงฉันชั่งน้ำหนักตัวเลือกทั้งสองอย่างละเอียด ถ้าฉันต้องใช้พอยน์เตอร์สำหรับสมาชิก (แม้แต่สมาชิกส่วนตัว) ฉันต้องยอมรับif (x)โพรซีเดอร์ทุกครั้งที่ฉันลงทะเบียน

ขึ้นอยู่กับสิ่งที่คุณต้องการจะเกิดขึ้น

คุณเขียนว่าคุณกำลังทำงานกับ "อุปกรณ์อิเล็กทรอนิกส์สำหรับผู้บริโภค" ถ้าอย่างใดข้อผิดพลาดจะถูกนำเสนอโดยการตั้งค่าmsgSender_เป็นNULLคุณต้องการ

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

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

แน่นอนถ้าคุณเลือกตัวเลือก 1 ข้อassert(ตามที่คนอื่นแนะนำ) มีความสำคัญต่อการลดโอกาสในการเกิดข้อผิดพลาดที่ไม่คืบหน้าในระหว่างการพัฒนา ifป้องกัน null มีไว้เพื่อลดความล้มเหลวในการใช้งานจริง

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