我认为最好在允许的情况下编写@override。它有助于编码。然而，需要注意的是，对于ecipse Helios，无论是sdk 5还是6，都允许为实现的接口方法使用@override注释。对于Galileo，无论是5还是6，@override注释都不允许。

我每次都用。它提供了更多的信息，当我在一年后重新访问代码时，我可以快速弄清楚发生了什么，而我已经忘记了我第一次想的是什么。

最佳实践是始终使用它(或让IDE为您填充它们)

@Override有用性是检测父类中没有向下报告的变化。 如果没有@Override，你可以改变方法签名而忘记改变它的覆盖，使用@Override，编译器将为你捕获它。

有这样的安全网总是好的。

最好将它用于打算重写的每个方法，以及Java 6+，用于打算作为接口实现的每个方法。

首先，它会在编译时捕获像“hashcode()”而不是“hashcode()”这样的拼写错误。当真正的原因是您的代码从未被调用时，调试为什么您的方法的结果似乎与您的代码不匹配可能会令人困惑。

同样，如果一个超类改变了一个方法签名，旧签名的重写就会被“孤立”，留下令人困惑的死代码。@Override注释将帮助您识别这些孤儿，以便对它们进行修改以匹配新签名。

It seems that the wisdom here is changing. Today I installed IntelliJ IDEA 9 and noticed that its "missing @Override inspection" now catches not just implemented abstract methods, but implemented interface methods as well. In my employer's code base and in my own projects, I've long had the habit to only use @Override for the former -- implemented abstract methods. However, rethinking the habit, the merit of using the annotations in both cases becomes clear. Despite being more verbose, it does protect against the fragile base class problem (not as grave as C++-related examples) where the interface method name changes, orphaning the would-be implementing method in a derived class.

当然，这种情况多半是夸张的;派生类将不再编译，现在缺少重命名接口方法的实现，今天可能会使用重命名方法重构操作来处理整个代码库。

鉴于IDEA的检查无法配置为忽略已实现的接口方法，今天我将改变我的习惯和我的团队的代码审查标准。

我总是使用标签。它是一个简单的编译时标志，用于捕捉我可能犯的小错误。

它会捕获tostring()而不是tostring()

小事情有助于大项目。