24 lines
1.4 KiB
Plaintext
24 lines
1.4 KiB
Plaintext
=== relates to: S2950
|
|
|
|
=== on 16 Oct 2014, 11:36:50 Ann Campbell wrote:
|
|
Not appropriate for PHP
|
|
|
|
=== on 22 May 2019, 10:55:33 Tibor Blenessy wrote:
|
|
I believe this rule is not appropriate for Java also and we should deprecate it. In Java, no modifier means package visibility, which is a specific kind of visibility, one of the four available "private", "protected", "public" and "package". It is just an unfortunate feature of Java that this access modifier cannot be specified with a specific keyword, but it can't be replaced. We have better rules related to access specification like RSPEC-2386
|
|
|
|
|
|
cc [~nicolas.harraudeau]
|
|
|
|
=== on 22 May 2019, 11:04:18 Nicolas Harraudeau wrote:
|
|
I agree with your reasoning as package visibility is also quite restrictive. I would however first like to check where this rule comes from. In my experience it is rare to use package visibility. It might be a forgotten "private" field, which would then be a code-smell.
|
|
|
|
=== on 1 Jul 2019, 10:35:49 Tibor Blenessy wrote:
|
|
\[~nicolas.harraudeau], OK to deprecate this rule?
|
|
|
|
=== on 29 Jul 2019, 09:38:35 Tibor Blenessy wrote:
|
|
\[~nicolas.harraudeau] I would like to make a decision and deprecate this rule, unless you tell me otherwise, I will do it by the end of the week
|
|
|
|
=== on 29 Jul 2020, 14:47:24 Alexandre Gigleux wrote:
|
|
I change the type from Vulnerability to Code Smell after discussing with AppSec bubble and the fact the same decision was taken for RSPEC-1104.
|
|
|