176 lines
4.4 KiB
Plaintext
176 lines
4.4 KiB
Plaintext
== Why is this an issue?
|
|
|
|
Redundant access specifiers should be removed because they needlessly clutter the code.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,cpp,diff-id=1,diff-type=noncompliant]
|
|
----
|
|
struct S {
|
|
public: // Noncompliant; does not affect any declaration
|
|
private:
|
|
void method();
|
|
private: // Noncompliant; does not change accessibility level
|
|
int member;
|
|
private: // Noncompliant; does not affect any declaration
|
|
};
|
|
class C {
|
|
int member;
|
|
private: // Noncompliant; does not change accessibility level
|
|
void method();
|
|
};
|
|
----
|
|
|
|
|
|
=== Compliant solution
|
|
|
|
[source,cpp,diff-id=1,diff-type=compliant]
|
|
----
|
|
struct S {
|
|
private:
|
|
void method();
|
|
int member;
|
|
};
|
|
class C {
|
|
int member;
|
|
void method();
|
|
};
|
|
----
|
|
|
|
|
|
=== Exceptions
|
|
|
|
An access specifier at the very beginning of a ``++class++`` or ``++struct++`` that matches the default access level is ignored even when it doesn't change any accessibility levels.
|
|
|
|
[source,cpp]
|
|
----
|
|
class C {
|
|
private: // redundant but accepted
|
|
// ...
|
|
};
|
|
struct S {
|
|
public: // redundant but accepted
|
|
// ...
|
|
};
|
|
----
|
|
Such a specifier is redundant but ignored to allow ``++class++``es and ``++struct++``s to be described uniformly.
|
|
|
|
[source,cpp]
|
|
----
|
|
class C {
|
|
public:
|
|
void call();
|
|
|
|
protected:
|
|
int delete();
|
|
|
|
private:
|
|
int code;
|
|
};
|
|
struct S {
|
|
public: // redundant but accepted
|
|
int sum();
|
|
|
|
protected:
|
|
int min();
|
|
|
|
private:
|
|
int count;
|
|
};
|
|
----
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
* Remove this redundant access specifier; it does not change the accessibility level.
|
|
* Remove this access specifier; it does not affect any declaration.
|
|
|
|
|
|
=== Highlighting
|
|
|
|
access specifier
|
|
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== on 29 Feb 2016, 11:45:02 Alban Auzeill wrote:
|
|
I doubt that there's a consensus on this rules. This is an example of discussion:
|
|
|
|
http://stackoverflow.com/questions/4962942/is-it-confusing-to-omit-the-private-keyword-from-a-class-definition
|
|
|
|
|
|
And bellow the use cases that could lead into exception on this rule:
|
|
|
|
|
|
*Use case 1:*
|
|
|
|
Some developers like to always write the first access specifier, even if it is redundant with the default access. So the code is easier to read for multi-language developers that don't master {cpp}.
|
|
|
|
https://github.com/SonarSource/it-sources/blob/master/cpp/ruling/cpp/clang-3.4/include/clang/ASTMatchers/Dynamic/Diagnostics.h#L102
|
|
|
|
----
|
|
class A {
|
|
private:
|
|
void reset();
|
|
// ...
|
|
};
|
|
struct B {
|
|
public:
|
|
void run();
|
|
// ...
|
|
};
|
|
----
|
|
|
|
*Use case 2:*
|
|
|
|
Developers that separate methods and attributes with always the same pattern: a redundant access specifier + a comment.
|
|
|
|
----
|
|
class A {
|
|
public: // methods
|
|
void run();
|
|
private: // methods
|
|
void reset();
|
|
// ... 50 more lines of declarations ....
|
|
private: // attributes
|
|
int speed;
|
|
};
|
|
----
|
|
|
|
*My current view*
|
|
|
|
* "Use case 1", I don't have a strong opinion, I prefer to not add an exception and see the findings on real code to decide if there is too much noise.
|
|
* "Use case 2", I disagree and would not accept an exception about this use case.
|
|
|
|
=== on 1 Mar 2016, 14:01:14 Alban Auzeill wrote:
|
|
The bellow "Use Case 1" generate too many issues, so Massimo and I decided to accept a redundant access specifier before the first member of a class declaration. I'm adding an Exception to the RSPEC.
|
|
|
|
|
|
Now I'm confident with the findings of this rule, so I changed "Default Quality Profiles" from "None" to "Sonar Way".
|
|
|
|
|
|
But concerning "Default Severity" I have no idea.
|
|
|
|
=== on 1 Mar 2016, 14:59:25 Ann Campbell wrote:
|
|
\[~alban.auzeill] I almost updated the Noncompliant example; ``++struct S++`` starts with a "Noncompliant" declaration that will be ignored according to this new exception...? On the other hand, it's ``++public++``, and ``++private++`` is the default...
|
|
|
|
=== on 2 Mar 2016, 06:35:19 Alban Auzeill wrote:
|
|
\[~ann.campbell.2] I have updated the exception paragraph to separate what is accepted ( ``++class++`` starting by ``++private:++`` and ``++struct++`` starting by ``++public:++`` ) from an example with the ``++public/protected/private++`` template.
|
|
|
|
=== on 2 Mar 2016, 08:56:19 Alban Auzeill wrote:
|
|
I've replaced "to be described with uniform templates." by "to be described uniformly " to avoid confusion with {cpp} templates
|
|
|
|
=== on 2 Mar 2016, 17:37:57 Ann Campbell wrote:
|
|
\[~alban.auzeill] I've updated the exception description slightly
|
|
|
|
endif::env-github,rspecator-view[]
|