4 ms·

In Python, the only way to access members of the current object is by explicitly using self (which should really have been called this in line with other langua

In Python, the only way to access members of the current object is by explicitly using self (which should really have been called this in line with other languages, but that's another matter). [0] This means there's never any confusion at all as to what is a member and what is a local. In C#, this confusion is possible, if you name your private members the same way as your locals. Microsoft recommends and uses a convention which does exactly this. [1][2] edit The point being that this.myThing will cause a compilation error unless myThing really is a member, giving an ironclad guarantee to the reader that it is indeed a member. Unlike in Python, in C# it's not possible to give the reader an ironclad guarantee that a local really is a local, as the implicit this cannot be disabled. [0] https://stackoverflow.com/a/1984121/ https://stackoverflow.com/a/1984121/ [1] https://web.archive.org/web/20100316191542/http://blogs.msdn.com/brada/articles/361363.aspx https://web.archive.org/web/20100316191542/http://blogs.msdn... [2] https://github.com/microsoftgraph/msgraph-sdk-dotnet-core/blob/bc4c8874637/src/Microsoft.Graph.Core/Requests/Upload/UploadSliceRequest.cs#L20 https://github.com/microsoftgraph/msgraph-sdk-dotnet-core/bl...

masklinn 6y ago
> In C#, this confusion is possible, if you name your private members the same way as your locals. This is also an issue with own methods versus static imports. > Microsoft recommends and uses a convention which does exactly this. [1][2] The article mentions this: > I know, capitalization conventions change over time, and I could have sworn there was a time when camel casing was the recommended approach for fields (specifically private fields) It looks like "private fields" (along with private everything) have been completely dropped from the conventions: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions https://docs.microsoft.com/en-us/dotnet/standard/design-guid... Only parameters remain conventionally camelCased, and it makes sense that they remain specified as C# allows for named parameters (so parameter names are part of the public interface).
- jayd16 6y ago
  Naming of fields and other members is described here https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members https://docs.microsoft.com/en-us/dotnet/standard/design-guid... Pascal case, same as Properties so they can be seamlessly refactored.
  - masklinn 6y ago
    > Naming of fields and other members is described here https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members https://docs.microsoft.com/en-us/dotnet/standard/design-guid... Your link explicitly states that it does not cover private fields: > Internal and private fields are not covered by guidelines Which is specifically what I noted was dropped from the document linked by TFA. > Pascal case, same as Properties so they can be seamlessly refactored. Your link also explicitly states that it only applies to static public or protected fields, and that public instance fields are forbidden by the member design guidelines*: > The field-naming guidelines apply to static public and protected fields […] public or protected instance fields are not allowed by the member design guidelines. So the only "seamless refactoring" which is allowed is essentially irrelevant (it's switching between static fields and static properties).
    - jayd16 6y ago
      My comment was meant to be additive and not in conflict with any of your statements.
c22 6y ago
You don't have to call it self. You can name the reference whatever you want, this works just as well. Though perhaps it's not as pythonic?
- freedomben 6y ago
  I think you are right, but the python guy in me from 10+ years ago has vague memories of people being burned at the stake for such heresy.
- MaxBarraclough 6y ago
  I hadn't wanted to get into the weeds of Python, but yes. You could use any identifier you want, but breaking with convention in this way is not a wise move. I consider it a mistake on the part of Python to go with self rather than this, but it's a really bad idea to write code that surprises other programmers in that way.
  - masklinn 6y ago
    > I consider it a mistake on the part of Python to go with self rather than this self makes more sense though. And smalltalk used self. And so did (obviously) Self. The most important part is to not use both (which of course is what PHP does).
    - m_t 6y ago
      Yeah but to quote stackoverflow: > Use $this to refer to the current object. Use self to refer to the current class. In other words, use $this->member for non-static members, use self::$member for static members. This is a different way of doing things, yes, but it makes sense.
lostmsu 6y ago
Technically you can disable implicit this: just raise the level of corresponding diagnostic to Error.
- MaxBarraclough 6y ago
  What diagnostic? It's not generally considered a mistake to access a member without making explicit use of this. There doesn't seem to be an easy way to detect it using external tooling, either: https://stackoverflow.com/q/957766/ https://stackoverflow.com/q/957766/
  - lostmsu 6y ago
    IDE0009: https://imgur.com/VowVqPI https://imgur.com/VowVqPI
    - MaxBarraclough 6y ago
      Thanks, you're right, I was going by some very old StackOverflow answers. I've posted a new answer there on how to configure the check in VS2019.
m4r35n357 6y ago
Yep, my Python code is littered with "self" noise. The PEP "limit" of 80 characters per line on top of that is just taking the piss!

masklinn 6y ago

> In C#, this confusion is possible, if you name your private members the same way as your locals. This is also an issue with own methods versus static imports. > Microsoft recommends and uses a convention which does exactly this. [1][2] The article mentions this: > I know, capitalization conventions change over time, and I could have sworn there was a time when camel casing was the recommended approach for fields (specifically private fields) It looks like "private fields" (along with private everything) have been completely dropped from the conventions: https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions https://docs.microsoft.com/en-us/dotnet/standard/design-guid... Only parameters remain conventionally camelCased, and it makes sense that they remain specified as C# allows for named parameters (so parameter names are part of the public interface).

jayd16 6y ago
Naming of fields and other members is described here https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members https://docs.microsoft.com/en-us/dotnet/standard/design-guid... Pascal case, same as Properties so they can be seamlessly refactored.
- masklinn 6y ago
  > Naming of fields and other members is described here https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members https://docs.microsoft.com/en-us/dotnet/standard/design-guid... Your link explicitly states that it does not cover private fields: > Internal and private fields are not covered by guidelines Which is specifically what I noted was dropped from the document linked by TFA. > Pascal case, same as Properties so they can be seamlessly refactored. Your link also explicitly states that it only applies to static public or protected fields, and that public instance fields are forbidden by the member design guidelines*: > The field-naming guidelines apply to static public and protected fields […] public or protected instance fields are not allowed by the member design guidelines. So the only "seamless refactoring" which is allowed is essentially irrelevant (it's switching between static fields and static properties).
  - jayd16 6y ago
    My comment was meant to be additive and not in conflict with any of your statements.

c22 6y ago

You don't have to call it self. You can name the reference whatever you want, this works just as well. Though perhaps it's not as pythonic?

freedomben 6y ago
I think you are right, but the python guy in me from 10+ years ago has vague memories of people being burned at the stake for such heresy.
MaxBarraclough 6y ago
I hadn't wanted to get into the weeds of Python, but yes. You could use any identifier you want, but breaking with convention in this way is not a wise move. I consider it a mistake on the part of Python to go with self rather than this, but it's a really bad idea to write code that surprises other programmers in that way.
- masklinn 6y ago
  > I consider it a mistake on the part of Python to go with self rather than this self makes more sense though. And smalltalk used self. And so did (obviously) Self. The most important part is to not use both (which of course is what PHP does).
  - m_t 6y ago
    Yeah but to quote stackoverflow: > Use $this to refer to the current object. Use self to refer to the current class. In other words, use $this->member for non-static members, use self::$member for static members. This is a different way of doing things, yes, but it makes sense.

lostmsu 6y ago

Technically you can disable implicit this: just raise the level of corresponding diagnostic to Error.

MaxBarraclough 6y ago
What diagnostic? It's not generally considered a mistake to access a member without making explicit use of this. There doesn't seem to be an easy way to detect it using external tooling, either: https://stackoverflow.com/q/957766/ https://stackoverflow.com/q/957766/
- lostmsu 6y ago
  IDE0009: https://imgur.com/VowVqPI https://imgur.com/VowVqPI
  - MaxBarraclough 6y ago
    Thanks, you're right, I was going by some very old StackOverflow answers. I've posted a new answer there on how to configure the check in VS2019.

m4r35n357 6y ago

Yep, my Python code is littered with "self" noise. The PEP "limit" of 80 characters per line on top of that is just taking the piss!