This rule is deprecated, and will eventually be removed.

## Why is this an issue?

Having a variable with the same name in two unrelated classes is fine, but do the same thing within a class hierarchy and you’ll get confusion at best, chaos at worst.

### Noncompliant code example

    Public Class Fruit

        Protected Ripe As Season
        Protected Flesh As Color

        ' ...

    End Class

    Public Class Raspberry
        Inherits Fruit

        Private Ripe As Boolean         ' Noncompliant
        Private Shared FLESH As Color   ' Noncompliant

        ' ...

    End Class

### Compliant solution

    Public Class Fruit

        Protected Ripe As Season
        Protected Flesh As Color

        ' ...

    End Class

    Public Class Raspberry
        Inherits Fruit

        Private Riped As Boolean
        Private Shared FLESH_COLOR As Color   ' Noncompliant

        ' ...

    End Class

### Exceptions

This rule ignores same-name fields that are `Shared` in both the parent and child classes. It also ignores `Private` parent class fields and fields explicitly declared as `Shadows`, but in all other such cases, the child class field should be renamed.

    Public Class Fruit

        Private Ripe As Season
        Protected Flesh As Color

        ' ...

    End Class

    Public Class Raspberry
        Inherits Fruit

        Private Ripe As Season      ' Compliant as parent field 'Ripe' is not visible from Raspberry anyway
        Protected Shadows Flesh As Color    ' Compliant as the intention is explicitly declared

        ' ...

    End Class