24 lines
1.4 KiB
Plaintext
24 lines
1.4 KiB
Plaintext
|
=== Related: RSPEC-2950
|
||
|
|
|
||
|
|
=== On 2014-10-16T11:36:50Z Ann Campbell Wrote:
|
||
|
|
Not appropriate for PHP
|
||
|
|
|
||
|
|
=== On 2019-05-22T10:55:33Z 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 2019-05-22T11:04:18Z 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 2019-07-01T10:35:49Z Tibor Blenessy Wrote:
|
||
|
|
\[~nicolas.harraudeau], OK to deprecate this rule?
|
||
|
|
|
||
|
|
=== On 2019-07-29T09:38:35Z 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 2020-07-29T14:47:24.154Z 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.
|
||
|
|
|