Not true. Both have static imports. Which means in e.g.

    PI * Pow(Radius, 2);

Also

> it's either a member of the current object, or it's a local variable in the current function.

So they do have non-member variables, in local variables. Making it clear that something is not a local variable is valuable as it means the variable has a much larger scope than you might expect.

> So they do have non-member variables, in local variables. Making it clear that something is not a local variable is valuable as it means the variable has a much larger scope than you might expect.

Yes, local variables are non-member variables. I'm just pointing out that people's habits may have been built in JavaScript or the like, where a non-member variable could be:

- a global

- from a closure, anywhere up the tree

- an import from another file

Whether or not the explicitness is still important in C# code, it's at least much more important in JavaScript and Python code (in fact I'm pretty sure both languages require it)

> - a global

> - from a closure, anywhere up the tree

> - an import from another file

C# has "from a closure, anywhere up the tree" and "an import from an other file" though, the only thing it arguably doesn't have is "a global".

> Whether or not the explicitness is still important in C# code, it's at least much more important in JavaScript and Python code (in fact I'm pretty sure both languages require it)

Technically you can use the `with` statement to make it implicit in javascript.

You should not, but you can.

It could also be a field in the parent class. Protected fields are a bad idea but I’m sure some people use them.

Having said that, C# also permits you to have fields with the same name in both the parent class and the current object.

This will give you a compiler warning suggesting you use the new keyword, though.