We're talking about coding standards and someone on our team wants us to avoid the protected keyword because it allows for variable shadowing.

The lead architect wants to avoid levels of inheritance whenever possible; trying to keep only Interfaces and Implementations (and he names all of the Implementations with the same class name plus "Impl").

Rule number one, all coding standard rules should come with a motivation for why.

Inheritance can be very good BUT used with caution since it often is used wrong where an interface had been better.

But never just setup rules without motivation.

Not only will the respect be lower but sometimes you can get workarounds that cause the same problem the rule was there to prevent while still obeying the rule.

With a good explanation you can often catch variations AND identify situations where an exception to the rule is in the best interest of the code base.

This seems borderline insane.

Like: let's destroy completely valid tools for certain jobs. (There are even cases were goto is valid!)

I understand were they are comming from, and I am very careful before using inheritance, and I prefer private (and immutable) over protected any day, yet there are use cases for these constructs.

They mean well, yet it follows the magic thinking that some approaches are inherently bad, and therefore your code base magically becomes super plus good by not using them.

And here is an article you may want to forward to your lead architect: https://octoperf.com/blog/2016/...

@k0pernikus why doing private and immutable? Wouldn't immutable allow to make it public?

@korrat The only things that should be public are the methods that should be called from the outside.

Even if a class has an immutable dependency, it doesn't mean you want to provide external access to it.

@k0pernikus correct, any exposure of values or references that are strictly not required locks down the class so those things cannot change later which makes reuse or refactoring much more difficult.