C# base misuse?

Question

I quite often find this kind of code in my company...

class Base
{
    public int Property
    {
        get; set;
    }
}

class Derived : Base
{
    public Derived()
    {
        base.Property = 0xAFFE;
    }
}

And, i often argue that this kind of use of base is "wrong".

I argue, that "this.Property" would be "correct" (or simply "Property = 0xAFFE;")

I argue, that one could refactor (making Property virtual, override it).

But, my arguments seem not to convince. Can you help with arguments? Or am i (completely) wrong?

Thanx.

If you want an answer based on "wrong" or "right", you may find better results on https://softwareengineering.stackexchange.com or https://codereview.stackexchange.com — CaTs, Sep 22 '21 at 08:20
Probably too opinion-based for SO, but at least you should be aware that setting virtual properties in the constructor is problematic: https://stackoverflow.com/questions/28382191/is-it-wrong-to-initialize-a-virtual-property-in-the-constructor — Jonas Høgh, Sep 22 '21 at 08:20
There's a semantic difference between using this & base, so I don't think it is an opiniated question. — Frederik Gheysels, Sep 22 '21 at 08:21
What I really find wrong is not using a base constructor to set the properties of the base class. They are probably using base.Property because you can create another property with the same name using the 'new' keyword. — Mayur Ekbote, Sep 22 '21 at 08:50
`And, i often argue that this kind of use of base is "wrong".` One thing you may learn as you get older is what things are worth arguing about. This topic fits pretty firmly in to the "doesn't matter" bucket (in my view). In this case, if you convince them - what is gained? Nothing really. So don't bother. ;) — mjwills, Sep 22 '21 at 09:24

score 2 · Answer 1 · answered Sep 22 '21 at 08:19

2

I think that, if Property in your example is not virtual, it doesn't matter if you use base or this. If it is virtual though, and overriden in an inherited class, you'll have differences in behavior.

I personally tend to never use base or this when setting properties like this (which would be the same as specifying this). Only in specific situations (like overriding a virtual method an calling the base implementation) do I use those keywords

answered Sep 22 '21 at 08:19

Frederik Gheysels

56,135
11
101
154

1

true, as long as it is not virtual (and no refactorings happen) it doesn't matter... the developer just wants to explicitly "show", that the implementation is in the base class (but why?), but e.g. in a ctor or function of a DerivedDerived class (derived from Derived) (s)he would again write base (but now s(he) actually wanted to say base.base) – Sep 22 '21 at 08:24
@AnnemarieS. _"he developer just wants to explicitly "show", that the implementation is in the base class (but why?)"_ I agree with you. What I would add here is that if there's such a need to explicitly distinguish that this is _not_ part of the current (derived) class, that this may suggest that they should've been using composition instead of inheritance, as that makes the boundaries between the two classes explicit, whereas inheritance _intentionally_ obfuscates those lines. – Flater Sep 22 '21 at 08:45
`I think that, if Property in your example is not virtual, it doesn't matter if you use base or this.` You may want to read up on shadowing. – mjwills Sep 22 '21 at 09:22

score 0 · Answer 2 · answered Sep 22 '21 at 10:56

So, we have at least 3 ways to say the same:

Property = 0xAFFE;
this.Property = 0xAFFE;
base.Property = 0xAFFE;

And as usual, there are minor aspects that can make a decision why this line is correct or wrong.

First version is most relaxed. Property can be a real property or a variable declared above or a param passed to from outer scope. Moreover, in some cases you can write Property = Property and the compiler would be smart enough to understand you (bad practice anyway).

Second version does an assumption: Property is the class belongings. Period. Despite some code analyzers would rise a hint "syntax can be simplified", this is a normal way of doing things.

Third one intends an assumption that is even more tight: Property is a blessing from ancestors. So even if you override it locally, that syntax 100% ensures you that the change is applied on the ancestor field.

To be honest, in most cases last two syntax forms are interchangeable. Do you really see a point to enforce yours?

`Second version does an assumption: Property is the class belongings. Period. Despite some code analyzers would rise a hint "syntax can be simplified", this is a normal way of doing things.` The first and second version are 100% the same. They will always have the same outcome. — mjwills, Sep 23 '21 at 02:20
After a refactoring, a var with the same name can be introduced and the property itself got renamed (add here such things like branches merging etc). Unfortunately, first version wouldn't break the compilation that case, just silently roll to another rail. — Yury Schkatula, Sep 23 '21 at 07:59

C# base misuse?

2 Answers2