Czy metody cyklu życia Unity powinny być opatrzone adnotacjami za pomocą atrybutu UsedImplicitly?

Czy opisywanie metod cyklu życia Unity UsedImplicitlyatrybutem poprawia czytelność kodu?

Na przykład:

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

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

Ten post na blogu „Strukturyzowanie Twojej jedności MonoBehaviours” sugeruje takie podejście jako przydatną konwencję.

8. Adnotuj wszelkie metody cyklu życia Unity (Start, Awake, Update, OnDestroy itp.), Metody zdarzeń i inne funkcje, które są domyślnie (lub automatycznie) wywoływane w kodzie za pomocą atrybutu [UsedImplicitly]. Ten atrybut, mimo że jest zawarty w UnityEngine.dll, jest wykorzystywany przez ReSharper do wyłączania sugestii dotyczących czyszczenia kodu dla metod, które są pozornie niepowiązane. Pomaga także ułatwić odczytanie kodu osobom, które są nowsze w Unity i twojej bazie kodu, szczególnie w przypadku zdarzeń, do których odwołuje się inspektor.

(Uwaga: nie sądzę, aby ReSharper wyświetlał sugestie dotyczące czyszczenia kodu dla pozornie niepowiązanych metod cyklu życia Unity, więc mogą to być nieaktualne porady.)

Zgadzam się z powyższym postem, że może być pomocny dla osób nowszych w Unity. Myślę też może być przydatna do oznaczania tych funkcji Unity cyklu życia , które nie są używane tak często, jak Awake, Starti Update. Zastanawiam się jednak, czy tak naprawdę jest to dobra konwencja dla „czystego kodu”, czy tylko szum ogranicza czytelność.

To zależy od docelowej grupy demograficznej.

W powyższym przykładzie docelową grupą demograficzną jest narzędzie ReSharper, które korzysta z tych atrybutów, ponieważ tłumi wiadomości, które nie są dla ciebie pomocne. Ale jeśli nie czujesz potrzeby używania ReSharpera lub podobnego narzędzia (chociaż może powinieneś mieć od czasu do czasu jakąś ważną krytykę), to nie musisz przejmować się tą demografią.

Każdy, kto kiedykolwiek wykonał podstawowy samouczek Unity, wie o tym bardzo dobrze Starti Updatejest niejawnie wykorzystywany przez silnik Unity, więc nie dostarczy żadnych nowych informacji. To może dezorientować ich, jeśli raz o tym zapomnisz. Co chcesz z tym powiedzieć? Czy to może tak naprawdę nie jest MonoBehaviour? A może jest jakiś niejasny powód, dla którego musisz nazwać to jawnie, czego nie jestem świadomy?

Może to jednak pomóc, jeśli pracujesz z niedoświadczonymi programistami, którzy mogą nie być zaznajomieni z bardziej ezoterycznymi zdarzeniami Unity, takimi jak Reset(niebezpieczne, ponieważ jawne wywołanie tego może nie zrobić tego, co myślisz). [UsedImplicitly]Atrybut może potem powiedzieć im, że nie muszą szukać dla klasy, która wywołuje tę metodę, ponieważ silnik ma. Ale znowu, ma to wartość tylko wtedy, gdy masz dyscyplinę, aby robić to konsekwentnie. A jeśli masz taką samodyscyplinę, równie dobrze możesz zgodzić się na dodanie komentarza.

Twierdzę, że nie, nie powinieneś go używać.

Atrybut UsedImplicitly pochodzi z przestrzeni nazw Jetbrain. Adnotacje, więc jedynym przypadkiem, w którym może być zastosowany, jest to, że wszyscy używający kodu będą używać ReSharper.

ReSharper ma wtyczkę do Unity, która już to obsługuje, upewniając się, że nie tylko usuwa ostrzeżenia, że ​​nie są one używane, ale także zaznacza je małym symbolem Unity, aby każdy, kto czyta kod, mógł zobaczyć, że są wywoływani przez samą Unity.

Chciałbym również dodać przykład, gdy ich użycie może się nie powieść. Załóżmy, że masz klasę dziedziczącą po MonoBehaviour, ale po refaktorze nie ma już żadnego dziedzictwa. Jeśli oznaczysz metody prywatne za pomocą [Używane niejawnie], nie otrzymasz poprawnych ostrzeżeń. Jeśli użyjesz wtyczki Unity do resharpera, zauważysz, że nie dziedziczysz już od MonoBehaviour i rzuci ostrzeżenia, ponieważ metody rzeczywiście nie są już wywoływane.

Argumentowałbym, że tak naprawdę nie może boleć.

Dla kogoś bardzo obeznanego z działaniami Unity prawdopodobnie nic nie dodaje. Ci ludzie już będą bardzo dobrze zaznajomieni z tym, co środowisko wykonawcze Unity wywołuje w twoim imieniu.

Ale dla kogoś, kto nie jest taki jak ja, może być pomocny. Nawet gdybym nie wiedział, co to znaczy odręcznie, sprawdziłbym to, a to prawdopodobnie wystarczałoby, aby lepiej zrozumieć, co się dzieje w kodzie.

Ponadto, jeśli ktoś użyje narzędzi do analizy statycznej, które niepoprawnie ostrzegają o metodach, to należy w jakiś sposób wyciszyć te ostrzeżenia, ponieważ „ignorowalny” hałas ostrzegawczy utrudnia dostrzeżenie prawdziwych ostrzeżeń w takich danych wyjściowych. Zazwyczaj lepiej jest zignorować takie ostrzeżenia w sposób chirurgiczny, zlokalizowany (w tym przypadku poprzez dekorowanie szkodliwych metod atrybutami) niż za pomocą szerszych środków, takich jak wyłączenie tego konkretnego ostrzeżenia dla całego projektu.

Problem z tym podejściem polega na tym, że jest niezwykle podatny na błędy.

Jeśli nie będzie wiarygodny, tagi nie przekażą użytecznych informacji, a ich obecność lub nieobecność będzie czasem udawana, że ​​będą przekazywać fałszywe informacje, co jest szkodliwe.

Jeśli zdecydujesz się na to, musisz usunąć ludzki błąd, co nie jest trudne, ale zajmuje dobre 2 godziny pracy, jeśli wcześniej nie zrobiłeś czegoś takiego. Istnieją 2 podejścia - każde z nich ma swoje zalety - możesz użyć jednego z nich:

1. Weryfikuj i odrzucaj niezgodny kod podczas odprawy lub kompilacji automatycznej.
2. Zautomatyzowana edycja kodu w celu naprawy tagów przy zameldowaniu lub automatycznej kompilacji.

Czy warto to mieć? Tak. Czy warto 2 godziny twojego czasu? Twoja decyzja.