== Why is this an issue?

While not mandatory, using the `@Override` annotation on compliant methods improves readability by making it explicit that methods are overridden.

A compliant method either overrides a parent method or implements an interface or abstract method.


=== Noncompliant code example

[source,java,diff-id=1,diff-type=noncompliant]
----
class ParentClass {
  public boolean doSomething(){/*...*/}
}
class FirstChildClass extends ParentClass {
  public boolean doSomething(){/*...*/}  // Noncompliant
}
----


=== Compliant solution

[source,java,diff-id=1,diff-type=compliant]
----
class ParentClass {
  public boolean doSomething(){/*...*/}
}
class FirstChildClass extends ParentClass {
  @Override
  public boolean doSomething(){/*...*/}  // Compliant
}
----


=== Exceptions

This rule does not raise issues when overriding methods from `Object` (eg: `equals()`, `hashCode()`, `toString()`, ...).


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Add the "@Override" annotation above this method signature


'''
== Comments And Links
(visible only on this page)

include::../comments-and-links.adoc[]

endif::env-github,rspecator-view[]