passing parameter that has the same name of class field variable in C#

Question

With C++, I can make a code as follows.

class Terminal {
    int uid;

public:
    void SetUid(int uid) {self.uid = uid;}
};

I tried the similar thing in C#, but I got an error. I tried the following instead, but it looks ugly.

class Terminal {
    int uid;

public void SetUid(int uid_) {uid = uid_;}
}

What do you use when you want to pass a parameter that has the same name of class field variable in C#?

score 5 · Accepted Answer · answered Dec 15 '10 at 20:26

5

class Terminal {
    int uid;

    public void SetUid(int uid) { this.uid = uid; }
}

However, I would consider using a property instead:

class Terminal {
    public int Uid { get; set; }
}

Getter and setter methods usually smell of improper C# design, since properties give you the getter/setter mechanism wrapped into a nice bit of syntactic sugar.

answered Dec 15 '10 at 20:26

cdhowie

158,093
24
286
300

There is one advantage of getter/setter methods as compared to properties; they can be used as delegate references. Yes, you can wrap the property in a lambda that looks like a setter, but that starts smelling too as you're basically creating a method that adds no value. – KeithS Dec 15 '10 at 21:23
@KeithS: You can actually create a delegate directly to the getter/setter in pure IL. In C# you can do this using reflection, which isn't too bad if you reuse the delegate: `Func getter = (Func)Delegate.CreateDelegate(typeof(Func), someTerminalReference, typeof(Terminal).GetProperty("Uid").GetGetMethod());` – cdhowie Dec 15 '10 at 21:54
... I think I'd rather have the lambda, actually. All that, versus ()=>Uid. Even though it does add an extra layer to the call stack, I think it'd actually be more performant, and certainly easier to read. – KeithS Dec 15 '10 at 22:22
@KeithS: It's easier to read, yeah. As for performance, there is no way the extra method will be faster. It may not be slower, but it's simply not possible for it to be faster. (Unless you count the delegate construction.) – cdhowie Dec 15 '10 at 23:05

score 4 · Answer 2 · answered Dec 15 '10 at 20:26

4

You can do this. Just use:

public void SetUid(int uid) { this.uid = uid; }

answered Dec 15 '10 at 20:26

Matt Kellogg

1,234
8
16

score 4 · Answer 3 · answered Dec 15 '10 at 20:26

4

In C++ it's not self, but this, and it's actually the same in C#;

 public void SetUid(int uid)
 {
    this.uid = uid;
 }

answered Dec 15 '10 at 20:26

Kim Gräsman

7,438
1
28
41

Isn't `self` from Pascal or something? – Ran Dec 15 '10 at 21:01
I know Python uses `self`. It's been long enough since I last used Pascal that I don't remember what it uses :-) – Kim Gräsman Dec 16 '10 at 15:00

score 1 · Answer 4 · answered Dec 15 '10 at 20:27

1

public void SetUid(int uid) {this.uid = uid;}

answered Dec 15 '10 at 20:27

Saif al Harthi

2,948
1
21
26

score 1 · Answer 5 · answered Dec 15 '10 at 20:33

We don't name parameters the same as our fields, because it's confusing. Code gets read far more often than it gets written, so readability is paramount. Having to mentally decode which uid is the parameter, and which is the field, just isn't worth it.

We actually use an underscore prefix for our fields, to make it immediately obvious what's a field and what's a parameter / local. I know not everybody likes that convention, but we find it helpful.

In addition, for a SetXxx method like you're writing, we'll often just name the parameter value, following the convention of C# property setters. Since there's only the one parameter, and you already know what it means from the method name, "value" is just as meaningful as "uid".

So in our shop, your example would probably end up looking like this:

public class Terminal {
    private int _uid;

    public void SetUid(int value) {
        _uid = value;
    }
}

That's assuming that the uid is write-only. If it were read-write, of course we'd use a property instead of getter/setter methods.

@Phoera Unless they've changed it recently, the MSDN guidelines are only for publicly-accessible members in shared libraries. Using underscores for private fields does not conflict with MSDN guidance, and it's a common convention. (But if you've got an updated link that conflicts with what I'm saying, please add it here!) — Joe White, Jun 11 '20 at 19:56
C# is case-sensitive, so usage of underscores is not so crucial, as in VB. My opinion is that it's up to every team to agree on the covention they use, but this should not be encouraged, as C# has ways of distinguishing the parameters without using of symbols, that create clutter. You can always use "this", or auto-property, for example. There are plenty of duscussions on this topic here, on SO, I just don't want to repeat them. For example: https://stackoverflow.com/questions/3136594/naming-convention-underscore-in-c-and-c-sharp-variables — Phoera, Jul 11 '20 at 20:03

score 1 · Answer 6 · answered Dec 15 '10 at 22:52

I've started to get into the habit of prefixing parameters with "the", as in "theUID" or "the_uid" if you prefer underscores.

public void SetUID(int theUID) {
    uid = theUID;
}

This is more helpful than "value", especially if you have multiple parameters:

public Actor(String theName, String theFilm)
{
    name = theName;
    film = theFilm;
}

(and yes, I used used to use "this." but found it got cumbersome and error-prone)

passing parameter that has the same name of class field variable in C#

6 Answers6