4

When the @Override annotation was introduced in Java 1.5, which feels like back in the days when the dinosaurs roamed the Earth, it was a good idea at the time because, amongst other advantages, it made your code self-documenting and it ensured you've spelt the method correctly.

Now it's 2018 and almost everyone writes Java using an IDE that already tells you whether a method is an override, typically using a little icon next to the method name or in the left margin of the same line. If I misspell the method, Java won't compile my class because there will be an unimplemented interface method, and I won't see the expected little icon so I'll know it's not an overriding method. It seems to me that the @Override annotation more often clutters the code rather than documenting it or making it clearer. Yet I still use it for the sake of consistency with the existing codebase. But for a new project, do you really think that we still should be using the @Override annotation? If so, why?

Perkone
  • 13
  • 2
DodgyCodeException
  • 163
  • 6
  • 2
    see [On discussions and why they don't make good questions](https://softwareengineering.meta.stackexchange.com/q/6742/31260) – gnat Jul 02 '18 at 15:42
  • 4
    `@Override` tells you, and the compiler for enforcement, it should be an override. The IDE only tells you the bare fact, not whether it's by design. – Deduplicator Jul 02 '18 at 15:44
  • @gnat thanks, that's a useful link. I was already aware that stackoverflow.com was not for discussions, which is why I asked in Software Engineering instead, but now I see that nowhere on StackExchange is for discussions. – DodgyCodeException Jul 02 '18 at 15:44
  • Well, here's one data point. Swift has `override` as a keyword, built right into the langauge. It's a fairly new language (public release in 2014), and it's still *required*. – Alexander Feb 09 '22 at 20:54

3 Answers3

15

People have been using IDEs to write Java code almost as long as Java has been a mainstream language. NetBeans, Eclipse, and IntelliJ IDEA all existed long before Java 1.5. People made mistakes then, and they continue to make mistakes now.

The bottom line is that anything you can do to minimize those mistakes, particularly when they are relatively low cost, you owe it to yourself to do.

A more common mistake than simply misspelling a method name is removing a method from a base class without thinking of the consequences.

Example (before change):

class Vehicle {
    public void drive() {}
}

class Car {
    @Override
    public void drive() {}
}

After a time, the folks who were maintaining the Vehicle class decide that driving shouldn't be something that a vehicle does, but something a driver does. So they take the logic out of Vehicle.drive() and move it to Driver.drive(Vehicle vehicle).

Now, you start to see the value of the @Override method. As soon as that team did that and recompiled, they would find out all of the places that need to be modified, or at least need to be accounted for in the Driver class. Without the @Override attribute, all of the sub-classes would silently compile and you would find subtle bugs that you now had to work through. In this example Cars would not drive like a car, but like a generic driver would.

Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
3

If you annotate a method with @Override and it doesn't actually override a method, the compiler will generate an exception. This could be useful for example to spot a typo in the method name.

class Vehicle
{
  public drive()
  {
    //Drive Logic for vehicle
  }
}

class Car extends Vehicle
{
  @Override
  public driev()
  {
    //Drive logic for car
  }
}

This will throw a compilation error which could be useful to spot the mistake earlier.

DobromirM
  • 232
  • 2
  • 8
0

The more I can tell the compiler about my intent, the better. And if the compiler notices when my declared intent and my code don’t match, and the compiler tells me, even better.

gnasher729
  • 42,090
  • 4
  • 59
  • 119