Use 'class' keyword to shorten static member references

[sjb-sjb]

OK I agree this is a small one --

We should be able to use the 'class' keyword to shorten references to static members:

 class EntityIdIndexes<TDbContext,TEntity,SortType,FilterType,IncludeType,AnotherType>: ... {
         static int StaticCount;
         static int StaticIncrement; 

         public void Method() {
              // Should be able to write this: 
              class.StaticCount = class.StaticCount + class.StaticIncrement;
              // Instead of this: 
              EntityIdIndexes<TDbContext,TEntity,SortType,FilterType,IncludeType,AnotherType>.StaticCount = EntityIdIndexes<TDbContext,TEntity,SortType,FilterType,IncludeType,AnotherType>.StaticCount + EntityIdIndexes<TDbContext,TEntity,SortType,FilterType,IncludeType,AnotherType>.StaticIncrement;

         }
 }

[Joe4evr]

You shouldn't need the type name when accessing from within the type itself.

[sjb-sjb]

I agree you don't have to put it there, but it is useful in the same way as specifying "this" is useful. Even using naming conventions I consider it better to specify.

[jnm2]

public struct WhatAboutMe
{
    private static int StaticCount;
    private static int StaticIncrement; 

    public void Method()
    {
        // Should be able to write this? ... 👀
        class.StaticCount = class.StaticCount + class.StaticIncrement;
    }
}

[jnm2]

One day when we (finally!) get #297:

public enum AndMe
{
    Foo = 1,
    Bar = 2

    public AndMe Method()
    {
        // Should be able to write this? ... 👀
        return this == class.Foo ? class.Bar : class.Foo;
    }
}

[vladd]

@Joe4evr Unless there is a local variable having the same name in scope.

[MkazemAkhgary]

@sjb-sjb what is the difference between this and class?

Also you should know that static field inside generic class is not one for all generic types. its actually one per each generic type. for example Foo<int>.StaticCount will be completely different from Foo<double>.StaticCount, incrementing the former does not affect the latter.

that maybe expected behavior though, I'm just noting it.

[Joe4evr]

@vladd That's why I always prefix field names with _; makes it quite obvious when you're accessing state from outside of the local method.

Everyone is free to choose their own rules, but having good naming conventions would pre-empt the need for this request. If you insist to qualify access with this. (for instances) and the type name (for statics), then you can set those Code Style rules in VS and use the Lightbulb to fill them in as needed.

(I say that, but looking at the options right now, there doesn't seem to be such a rule for accessing static members from its declaring type.)

[DavidArno]

@jnm2,

When does Oracle's dodgy patent on enums expire? Java itself is 22 years old, but I don't know when they took out the patent on enums. I'm assuming the patent only has a 20 year life?

[Joe4evr]

Filed in 2002.

[jnm2]

Funny to see @gafter's name as an inventor on Java's patent, but then I saw this and was less thrilled: https://www.google.com/patents/WO2011084876A3 Didn't know Microsoft was in the business of patenting syntax representations, but I'm not a fan.

[orthoxerox]

@jnm2 I think they also patented storing trivia in syntax nodes.

I wonder what Apache 2 license says about patents.

[GeirGrusom]

@orthoxerox that's a... odd patent? Sounds like a patent for taking notes in the margin of a notebook...

[vladd]

@Joe4evr You seem to be advocating the "manual" way of resolving naming conflicts. If we would take your way one step further, one could see that we don't need this.FieldName syntax as well, because field names and local names ought to different.

However the syntax for disambiguating the local name and instance field name does exist, so the syntax for disambiguating the local name and static field would be just feature parity. (Yes, one can specify the full class name, which is however error-prone and can get a really ugly look with long generic parameter lists and nested classes.)

---

PS: Microsoft's own naming convention guidelines suggest not using underscores (as well as Hungarian notation like m_).

[Joe4evr]

You seem to be advocating the "manual" way of resolving naming conflicts. If we would take your way one step further, one could see that we don't need this.FieldName syntax as well, because field names and local names ought to different.

I merely stated my preference. And then I said what every dev can do to have the compiler warn or even error when their preferred style is violated. And if I'm not mistaken in that breaking such a rule brings up a Quick Fix, it's just a matter of Ctrl+.+Enter to apply. So if you like this. so much, you can go to your Code Style settings, set everything to "Prefer 'this.'" with a Severity of Error, and you'll catch all cases in your code base in an instant.

And sure, Qualify static access from declaring type doesn't exist as a Code Style rule right now, but it's easy to propose it be added over at dotnet/roslyn, no?

PS: Microsoft's own naming convention guidelines suggest not using underscores (as well as Hungarian notation like m_).

And yet, both those styles are used throughout the BCL quite extensively. 🙃

[svick]

@vladd Those guidelines are only about names that are public, not about private implementation details:

Although adopting these naming conventions as general code development guidelines would result in more consistent naming throughout your code, you are required only to apply them to APIs that are publicly exposed (public or protected types and members, and explicitly implemented interfaces).

[GeirGrusom]

(as well as Hungarian notation like m_)

This is Hungarian notation:

bool bCompleted = true;
int iCount = 100;
float fWeight = 50f;

[HaloFour]

@GeirGrusom

This is Hungarian notation:

bool bCompleted = true;
int iCount = 100;
float fWeight = 50f;

Actually that isn't either, at least not what Hungarian notation is supposed to be. It got bastardized into this notion that it's supposed to be a prefix representing the data type of the variable, but that's redundant and unnecessary. The prefix is supposed to indicate the functional type of the variable to help distinguish it from other variables of the same data type but different functional types. You should never call a variable iCount because that conveys nothing new about the variable. You might call it cApple, representing a count of apples, which you can clearly distinguish apart from dxApple representing the delta in x-coordinates of the apple, despite the fact that the two are both integers. You should be able to glance at the names of the variables in an expression and infer whether or not that expression makes sense regardless of how legal the compiler thinks it would be. And even then the value of those prefixes is only when you would be dealing with a function where you have overlap of functional type. Otherwise you'd simply omit them.

Hungarian Notation - Charles Simonyi

But yes, the data type prefix somehow became the norm and VB5/6 helped it to spread like wildfire.

Sorry for the rant.

[vladd]

@svick Yes, following the naming conventions is not required. Nevertheless I am following the naming conventions for the private members too, is this somehow wrong? Should the language design "punish" the developers who adhere to the official naming conventions?

In any case, I see the language feature which facilitates adhering to the official naming conventions as a good thing. The idea of changing the code's naming conventions and giving up on official convention seems quite strange to me.

[sjb-sjb]

Getting back to the proposal...

About @jnm2 's questions, I would suggest struct and enum in those cases.

How do we upvote ideas by the way?

[jnm2]

How do we upvote ideas by the way?

[AustinBryan]

It would not provide the same benefit as this, which I only ever mostly in constructors to intialize private fields because, by convention, they have the same, lowercased names.

Besides, the current way of doing it is even shorter than your idea.

class EntityIdIndexes<TDbContext, TEntity, SortType, FilterType, IncludeType, AnotherType>: ... 
{
         static int StaticCount;
         static int StaticIncrement; 

         public void Method() 
         {
              // You can just do this
              StaticCount = StaticCount + StaticIncrement;
              // Instead of this: 
             class.StaticCount = class.StaticCount + class.StaticIncrement;

         }
 }

Also, having it be struct or whatever depending on where you are is also a bad idea because it's inconsistent. I better idea would be static.StaticCount or something and that will work for both.

Also, the enum one was a joke. enums can't have members.

[Joe4evr]

Also, the enum one was a joke. enums can't have members.

Never say "never".