是否应该使用UsedImplicitly属性注释Unity生命周期方法？

使用UsedImplicitly属性注释Unity生命周期方法是否可以提高代码的可读性？

例如：

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

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

这篇关于“构建Unity MonoBehaviours”的博客文章建议将此方法作为有用的约定。

8. 使用[UsedImplicitly]属性注释代码中隐式（或自动）调用的所有Unity生命周期方法（开始，唤醒，更新，OnDestroy等），事件方法和其他函数。尽管此属性包含在UnityEngine.dll中，但ReSharper使用它来为似乎未引用的方法禁用代码清除建议。它还有助于使刚接触Unity和您的代码库的人更容易阅读代码，尤其是对于通过检查器引用的事件。

（注意：我不认为ReSharper会为看似未引用的Unity生命周期方法显示代码清理建议，因此这可能已过时。）

我同意上面的帖子，这对于那些对Unity较新的人可能会有帮助。我还认为这可能是标记那些有用的统一生命周期的功能不被使用的频繁程度Awake，Start以及Update。但是我想知道这是否真的是“干净代码”的良好约定，还是仅仅是噪音降低了可读性。

这取决于目标人群。

在上面的示例中，目标人群是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个小时的时间吗？您的来电。