== Why is this an issue?

Adding an access specifier that matches the class' current access level needlessly clutters the code.


=== Noncompliant code example

[source,cpp]
----
struct B {
};

struct S : public B { // Noncompliant; "struct" has public access for its base classes by default
};

class C : private B { // Noncompliant; "class" has private access for its base classes by default
};
----


=== Compliant solution

[source,cpp]
----
struct B {
};

struct S : B {
};

class C : B {
};
----

== Resources

=== Related rules

* S5965 and S5966 are other rules that favor different coding style for base classes. They should not be activated at the same time as this rule.


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

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

=== Message

Remove this redundant access specifier; it is already "XXX".


=== Highlighting

specifier


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

=== on 29 Feb 2016, 14:08:01 Alban Auzeill wrote:
I intentionally didn't add an exception about multi-inheritance with different visibilities:

https://github.com/SonarSource/it-sources/blob/master/cpp/ruling/cpp/cmake-2.8.12.2/Source/cmGeneratedFileStream.h#L79

It's the following case:

----
class C : public A, B { }
----
Where some developers add redundant specifier to make a clear distinction between public and private:

----
class C : public A, private B { }
----
An exception for the above case could be useful for a minority of junior developer that confuse inheritance. But will be seen as non homogeneous by the remaining majority.

=== on 29 Feb 2016, 19:15:33 Ann Campbell wrote:
\[~alban.auzeill] why highlight the base class name and not the specifier?

=== on 2 Mar 2016, 09:32:47 Alban Auzeill wrote:
\[~ann.campbell.2] of course we should highlight the specifier and not the base class.

=== on 2 Mar 2016, 11:32:28 Alban Auzeill wrote:
\[~ann.campbell.2] Could you set yourself as Reporter ?

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