ควรทำหมายเหตุประกอบวิธีวงจรชีวิตของ Unity ด้วยแอตทริบิวต์ UsedImplicitly หรือไม่

การทำหมายเหตุประกอบวิธีการ Unity lifecycle ด้วยแอUsedImplicitlyททริบิวนี้จะช่วยปรับปรุงความสามารถในการอ่านโค้ดของคุณหรือไม่?

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

public class Example : MonoBehaviour
{
    [UsedImplicitly]
    private void Awake()
    {
        DoSomething();
    }

    private void DoSomething()
    {
        // ...
    }
}

โพสต์บล็อกนี้ใน "โครงสร้างของคุณ Unity MonoBehaviours"แนะนำวิธีนี้เป็นแบบแผนที่มีประโยชน์

8. อธิบายวิธีการวงจรชีวิต Unity ใด ๆ (เริ่ม, ตื่น, อัพเดท, OnDestroy ฯลฯ ) วิธีการเหตุการณ์และฟังก์ชั่นอื่น ๆ ที่มีการเรียกใช้โดยนัย (หรือโดยอัตโนมัติ) ในรหัสของคุณด้วยแอตทริบิวต์ [UsedImplicitly] คุณลักษณะนี้แม้ว่าจะรวมอยู่ใน UnityEngine.dll แต่ถูกใช้โดย ReSharper เพื่อปิดใช้งานคำแนะนำในการล้างรหัสสำหรับวิธีการที่ดูเหมือนไม่ได้รับการอ้างอิง นอกจากนี้ยังช่วยให้การอ่านรหัสง่ายขึ้นสำหรับผู้ที่ยังใหม่กับ Unity และ codebase ของคุณโดยเฉพาะอย่างยิ่งสำหรับกิจกรรมที่อ้างอิงผ่านทางผู้ตรวจสอบ

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

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

ขึ้นอยู่กับกลุ่มประชากรเป้าหมาย

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

ทุกคนที่เคยทำแบบฝึกหัด Unity ขั้นพื้นฐานรู้ดีมากStartและUpdateใช้เอ็นจิ้น Unity โดยปริยายดังนั้นมันจะไม่ให้ข้อมูลใหม่แก่พวกเขา ในความเป็นจริงมันอาจทำให้สับสนได้หากคุณลืมสิ่งนี้ไป คุณต้องการพูดอะไรกับสิ่งนั้น นี่อาจจะไม่ใช่ MonoBehaviour จริงเหรอ? หรือมีเหตุผลบางอย่างที่คลุมเครือว่าทำไมคุณต้องเรียกมันอย่างชัดเจนซึ่งฉันไม่ทราบ?

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

ฉันยืนยันว่าไม่ควรใช้

แอตทริบิวต์ UsedImplicitly มาจาก Jetbrains.Annotations namespace ดังนั้นกรณีเดียวที่อาจใช้คือถ้าทุกคนที่ใช้รหัสจะใช้ ReSharper

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

ฉันต้องการเพิ่มตัวอย่างเมื่อใช้งานอาจผิดพลาด สมมติว่าคุณมีคลาสที่สืบทอดมาจาก MonoBehaviour แต่หลังจากผู้ปรับโครงสร้างแล้วจะไม่มีการสืบทอดอีกต่อไป หากคุณทำเครื่องหมายวิธีการส่วนตัวด้วย [UsedImplicitly] คุณจะไม่ได้รับคำเตือนที่ถูกต้อง หากคุณใช้ปลั๊กอิน Unity สำหรับผู้ตรวจสอบซ้ำมันจะสังเกตเห็นว่าคุณไม่ได้รับมรดกจาก MonoBehaviour อีกต่อไปและจะแจ้งเตือนเนื่องจากไม่มีการเรียกวิธีการใด ๆ อีกต่อไป

ฉันจะโต้แย้งว่ามันไม่สามารถทำร้ายได้จริงๆ

สำหรับบางคนที่คุ้นเคยกับการทำงานของ Unity มากอาจไม่เพิ่มอะไรเลย คนเหล่านั้นคุ้นเคยกับสิ่งที่ Unity เรียกใช้ในนามของคุณ

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

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

ปัญหาของวิธีนี้คือมันผิดพลาดได้ง่ายมาก

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

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

1. ตรวจสอบและปฏิเสธรหัสที่ไม่สอดคล้องกับการเช็คอินหรือการสร้างอัตโนมัติ
2. การแก้ไขรหัสโดยอัตโนมัติเพื่อแก้ไขแท็กในการเช็คอินหรือสร้างอัตโนมัติ

มันคุ้มไหมที่จะมีมัน? ใช่. คุณใช้เวลา 2 ชั่วโมงหรือไม่? การโทรของคุณ