Unityライフサイクルメソッドは、UsedImplicitly属性で注釈を付ける必要がありますか？

UsedImplicitly属性を使用してUnityライフサイクルメソッドに注釈を付けると、コードが読みやすくなりますか？

例えば：

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

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

「Unity MonoBehavioursの構造化」に関するこのブログ投稿は、このアプローチを有用な慣例として示唆しています。

8. Unityライフサイクルメソッド（Start、Awake、Update、OnDestroyなど）、イベントメソッド、および[UsedImplicitly]属性を使用してコード内で暗黙的（または自動的）に呼び出されるその他の関数に注釈を付けます。この属性はUnityEngine.dllに含まれていますが、参照されていないように見えるメソッドのコードクリーンアップの提案を無効にするためにReSharperによって使用されます。また、Unityやコードベースの初心者がコードを読みやすくするのにも役立ちます。特に、インスペクターを介して参照されるイベントの場合に役立ちます。

（注：ReSharperが一見参照されていないように見えるUnityライフサイクルメソッドのコードクリーンアップの提案を示しているとは思わないので、古くなったアドバイスかもしれません。）

Unityの初心者には役立つかもしれないという上記の投稿に同意します。私はまた、これらのラベル付けすることが有用であると思うユニティライフサイクル機能頻繁にとして使用されていないAwake、StartとUpdate。しかし、これが実際に「クリーンなコード」のための良い慣習なのか、それとも読みやすさを低下させるのは単なるノイズなのかと思います。

対象となるユーザー層によって異なります。

上記の例では、対象となる人口統計はReSharperツールです。ReSharperツールは、役に立たないメッセージを抑制するため、これらの属性のメリットがあります。ただし、ReSharperまたは類似のツールを使用する必要性を感じない場合（必要な場合もありますが、有効な批評がある場合もあります）、その人口統計について気にする必要はありません。

基本的なUnityチュートリアルをやったことのある人なら誰でもそれをよく知ってStartおりUpdate、Unityエンジンによって暗黙的に使用されているので、新しい情報は提供されません。これを一度忘れてしまうと、実際に混乱するかもしれません。それで何を言いたいの？これは実際にはMonoBehaviourではないのでしょうか？それとも、私が知らない理由を明示的に呼び出さなければならないあいまいな理由はありますか？

ただし、より難解なUnityイベントに精通していない可能性のある経験の浅い開発者と協力している場合は役立ちますReset（危険です。明示的に呼び出すと、意図したとおりに動作しない可能性があるため）。次に、[UsedImplicitly]属性は、エンジンが行うため、そのメソッドを呼び出すクラスを探す必要がないことをユーザーに伝えます。しかし、繰り返しますが、これは、これを一貫して行う規律がある場合にのみ価値があります。そして、あなたがその程度の自己規律を持っているなら、コメントを追加することに同意することもできます。

私はあなたがそれを使うべきではないと主張します。

UsedImplicitly属性はJetbrains.Annotations名前空間からのものであるため、コードを使用するすべてのユーザーがReSharperを使用する場合にのみ適用される可能性があります。

ReSharperにはUnity用のプラグインがあり、これがすでに処理されています。使用されていないという警告を削除するだけでなく、小さなUnityシンボルでマークを付けて、コードを読んだ人がUnity自体によって呼び出されていることを確認できるようにします。

それらを使用するとうまくいかない場合の例も追加したいと思います。MonoBehaviourから継承するクラスがあると仮定しますが、リファクタリング後は、継承はなくなります。プライベートメソッドを[UsedImplicitly]でマークすると、正しい警告を受け取れなくなります。Unityプラグインをリシャープに使用すると、MonoBehaviourから継承されなくなったことに気づき、メソッドが実際に呼び出されなくなったときに警告をスローします。

私はそれが本当に害を及ぼすことはできないと主張します。

Unityの仕組みに詳しい人にとっては、おそらく何も追加されません。それらの人々は、Unityのランタイムがあなたに代わって呼び出すものにかなり精通しているでしょう。

しかし、私のようにそうでない人にとっては、それが役立つかもしれません。それがオフハンドで何を意味するのかわからなかったとしても、私はそれを調べに行きます、そしてそれはおそらく私にコードで何が起こっているかについてのより良い理解を与えるのに十分でしょう。

また、メソッドについて誤って警告している静的分析ツールを使用する場合は、「無視できる」警告ノイズにより、そのような出力で実際の警告を表示することが難しくなるため、それらの警告を静める必要があります。通常、プロジェクト全体で特定の警告を無効にするなどのより広い方法を使用するよりも、外科的で局所的な方法で（この場合は問題のあるメソッドを属性で装飾することによって）このような警告を無視する方が適切です。

このアプローチの問題は、非常にエラーが発生しやすいことです。

信頼できない場合、タグは有用な情報を伝えることができず、タグの存在または不在は時々、誤った情報を伝えることに成功し、これは有害です。

それを採用する場合は、人的エラーを取り除く必要があります。これは難しいことではありませんが、これまでにこのようなことを行ったことがない場合は、2時間程度の作業が必要です。2つのアプローチがあり、それぞれに独自の利点があります。どちらかを使用できます。

1. チェックインまたは自動ビルド時に、準拠していないコードを確認して拒否します。
2. チェックインまたは自動ビルドでタグを修正するためのコードの自動編集。

持つ価値はありますか？はい。それはあなたの時間の2時間の価値がありますか？あなたの電話。