Các phương thức vòng đời của Unity có nên được chú thích với thuộc tính OLX không?

Việc chú thích các phương thức vòng đời Unity với UsedImplicitlythuộc tính có cải thiện khả năng đọc mã của bạn không?

Ví dụ:

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

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

Bài đăng trên blog này về "Cấu trúc sự thống nhất của bạn MonoBehaviours" gợi ý cách tiếp cận này như một quy ước hữu ích.

8. Chú thích bất kỳ phương thức vòng đời Unity nào (Bắt đầu, Thức tỉnh, Cập nhật, OnDestroy, v.v.), phương thức sự kiện và các hàm khác được ngầm định (hoặc tự động) được gọi trong mã của bạn với thuộc tính [Được sử dụng rõ ràng]. Thuộc tính này, mặc dù được bao gồm trong UnityEngine.dll, được ReSharper sử dụng để vô hiệu hóa các đề xuất dọn mã cho các phương thức dường như không được ước tính. Nó cũng giúp làm cho mã dễ đọc hơn đối với những người mới sử dụng Unity và cơ sở mã của bạn, đặc biệt đối với các sự kiện được tham chiếu qua thanh tra.

(Lưu ý: Tôi không nghĩ ReSharper hiển thị các đề xuất dọn mã cho các phương thức vòng đời Unity dường như không được kiểm soát, do đó có thể là lời khuyên lỗi thời.)

Tôi đồng ý với bài viết trên rằng nó có thể hữu ích cho những người mới hơn với Unity. Tôi cũng nghĩ rằng nó có thể hữu ích để dán nhãn những chức năng vòng đời Unity không được sử dụng thường xuyên như Awake, Start, và Update. Nhưng tôi tự hỏi liệu đây có thực sự là một quy ước tốt cho "mã sạch" hay không, nếu đó chỉ là tiếng ồn làm giảm khả năng đọc.

Nó phụ thuộc vào nhân khẩu học mục tiêu.

Trong ví dụ trên, nhân khẩu học mục tiêu là công cụ ReSharper, được hưởng lợi từ các thuộc tính này vì nó ngăn chặn các thông báo không hữu ích cho bạn. Nhưng nếu bạn không cảm thấy cần phải sử dụng ReSharper hoặc một công cụ tương tự (mặc dù có lẽ bạn nên có một số phê bình hợp lệ theo thời gian), thì bạn không cần quan tâm đến nhân khẩu học đó.

Bất cứ ai đã từng làm một hướng dẫn Unity cơ bản đều biết rất rõ điều đó Startvà Updateđược sử dụng ngầm bởi công cụ Unity, vì vậy nó sẽ không cung cấp cho họ bất kỳ thông tin mới nào. Thực tế nó có thể gây nhầm lẫn cho họ nếu bạn quên điều này một lần. Bạn muốn nói gì với điều đó? Đây có phải không thực sự là một MonoBehaviour? Hoặc có một số lý do mơ hồ tại sao bạn phải gọi nó một cách rõ ràng mà tôi không biết?

Tuy nhiên, nó có thể giúp ích nếu bạn đang làm việc với các nhà phát triển thiếu kinh nghiệm, những người có thể không quen thuộc với các sự kiện Unity bí truyền hơn như Reset(nguy hiểm, vì gọi nó rõ ràng có thể không làm những gì bạn nghĩ). Sau đó, [UsedImplicitly]thuộc tính có thể nói với họ rằng họ không cần tìm lớp gọi phương thức đó bởi vì công cụ thực hiện. Nhưng một lần nữa, điều này chỉ có giá trị nếu bạn có kỷ luật để làm điều này một cách nhất quán. Và nếu bạn có số lượng kỷ luật tự giác đó, bạn cũng có thể đồng ý về việc thêm một bình luận.

Tôi lập luận rằng không có bạn không nên sử dụng nó.

Thuộc tính OLX được sử dụng là từ không gian tên Jetbrains. Chú ý vì vậy trường hợp duy nhất có thể áp dụng là nếu mọi người sử dụng mã sẽ sử dụng ReSharper.

ReSharper có một plugin cho Unity đã xử lý việc này cho bạn, đảm bảo không chỉ xóa các cảnh báo rằng chúng không được sử dụng mà còn đánh dấu chúng bằng một biểu tượng Unity nhỏ để bất kỳ ai đọc mã đều có thể thấy rằng chúng được gọi bởi chính Unity.

Tôi cũng muốn thêm một ví dụ khi sử dụng chúng có thể sai. Giả sử bạn có một lớp kế thừa từ MonoBehaviour, nhưng sau khi tái cấu trúc, nó không còn bất kỳ sự kế thừa nào nữa. Nếu bạn đã đánh dấu các phương thức riêng tư bằng [Được sử dụng rõ ràng] thì bạn sẽ không nhận được cảnh báo chính xác. Nếu bạn sử dụng plugin Unity để chia sẻ lại, nó sẽ nhận thấy rằng bạn không còn thừa hưởng từ MonoBehaviour và sẽ đưa ra các cảnh báo vì các phương thức thực sự không còn được gọi.

Tôi sẽ đưa ra lập luận rằng nó không thể thực sự bị tổn thương.

Đối với ai đó rất quen thuộc với hoạt động của Unity, có lẽ nó không thêm bất cứ điều gì. Những người đó đã khá quen thuộc với những gì thời gian chạy của Unity thay mặt bạn.

Nhưng đối với một người không như tôi, nó có thể hữu ích. Ngay cả khi tôi không biết ý nghĩa của nó là gì, tôi sẽ tìm kiếm nó và điều đó có thể đủ để cho tôi hiểu rõ hơn về những gì đang diễn ra trong mã.

Ngoài ra, nếu người ta sử dụng các công cụ phân tích tĩnh cảnh báo không chính xác về các phương thức, thì bạn sẽ muốn làm im lặng những cảnh báo đó bằng cách nào đó, bởi vì tiếng ồn cảnh báo "không thể biết được" khiến cho việc nhìn thấy cảnh báo thực sự trong bất kỳ đầu ra nào như vậy trở nên khó khăn hơn . Thông thường tốt hơn là bỏ qua các cảnh báo như vậy theo kiểu phẫu thuật, cục bộ (trong trường hợp này bằng cách trang trí các phương pháp vi phạm bằng các thuộc tính) hơn là thông qua các biện pháp rộng hơn như vô hiệu hóa toàn bộ dự án cảnh báo cụ thể đó.

Vấn đề với phương pháp này là nó rất dễ bị lỗi.

Nếu nó không đáng tin cậy, các thẻ sẽ không truyền được thông tin hữu ích và sự hiện diện hay vắng mặt của chúng đôi khi sẽ thành công trong việc truyền tải thông tin sai lệch, có hại.

Nếu bạn quyết định đi theo nó, bạn phải loại bỏ lỗi của con người, điều này không khó thực hiện, nhưng mất 2 giờ làm việc nếu bạn chưa từng làm điều gì đó như thế này trước đây. Có 2 cách tiếp cận - mỗi cách đều có ưu điểm riêng - bạn có thể sử dụng một trong hai cách:

1. Xác minh và từ chối mã không tuân thủ khi đăng ký hoặc xây dựng tự động.
2. Tự động chỉnh sửa mã để sửa các thẻ khi đăng ký hoặc xây dựng tự động.

Có đáng để có nó không? Đúng. Có đáng giá 2 giờ thời gian của bạn? Cuộc gọi của bạn.