== Why is this an issue?

Unnecessary keywords simply clutter the code and should be removed. Specifically:

* ``++partial++`` on type declarations that are completely defined in one place
* ``++sealed++`` on members of ``++sealed++`` classes
* ``++unsafe++`` method or block inside construct already marked with ``++unsafe++``, or when there are no ``++unsafe++`` constructs in the block
* ``++checked++`` and ``++unchecked++`` blocks with no integral-type arithmetic operations 

=== Noncompliant code example

[source,csharp]
----
public partial class MyClass // Noncompliant
{
  public virtual void Method()
  {
  }
}

public sealed class MyOtherClass : MyClass
{
  public sealed override void Method() // Noncompliant
  {
  }
}
----

=== Compliant solution

[source,csharp]
----
public class MyClass
{
  public virtual void Method()
  {
  }
}

public sealed class MyOtherClass : MyClass
{
  public override void Method()
  {
  }
}
----

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

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

=== Message

* "xxx" is [redundant|gratuitous] in this context.


=== Highlighting

Primary: redundant keyword 

Secondary: block delimiters if relevant (e.g. ``++unsafe++``)


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

=== on 9 Jul 2015, 12:30:41 Ann Campbell wrote:
\[~tamas.vajk] as discussed in the comments of SONARCSANA-197, I've edited this to raise issues on both ``++partial++`` and ``++virtual++``.


Also, I've moved this under an older RSpec as a subtask. There is a mild difference in scope (redundant vs gratuitous keywords) and that's what kept me from making the association the first time around, but on second thought, they're not different enough to sustain the distinction.

=== on 9 Jul 2015, 12:51:04 Tamas Vajk wrote:
\[~ann.campbell.2] Thanks, it looks good. I've added the ``++sealed++`` option as well, which directly comes from the parent task (``++final++`` in Java).

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