Eshoponcontainers: Code style - Why using underscore in variable names?

[vpereira01]

(Hi o/ )

I noticed that private variables are using underscores naming which seems very out of place.
Are reason for this?

I know that underscores were a "pattern" in beginnings of C# because of VB. Few years have gone and the Microsoft code style guidelines, and other probably, go against it so I was wondering why this was a still a thing here.

Thanks

[Uriil]

@vpereira01 what do you mean by "private variables"? Private fields, or variables, which are defined inside methods?

[mvelosop]

Hi @vpereira01,

Well, AFAIK, the _ prefix really comes from C/C++ but it's really just a matter of personal preferences.

For example, I do use them for private members just because I like them to look different and don't like writing this. as some other people like. But that's just fine as well.

So, as long as the team goes with a convention it's just fine. IMHO I prefer to focus on other issues.

Hope this helps.

[CESARDELATORRE]

_variable is usually used for variables defined under the scope of a class. As @vpereira01 mentions it was used in the early years of C#.
In C++ it was similar, coming from the Hungarian nomenclature, where a member variable (class scope) was always defined like "m_variable" with "m_".

Since most of the code in current C# samples don't use this nomenclature ("_var"), we might want to be aligned to it and not use it. We can change it progressively while evolving the code, but I don't think this is a critical issue but a matter of preferences.

[CESARDELATORRE]

Closing the issue. Let's just update the code when evolving it.
For member variables (class scope) just lowercase is nowadays the standard, like here:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/fields

For properties, uppercase, like here:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties

In general and for other code, here's a Code Style doc:
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions

[vpereira01]

Thanks for feedback 👍

[eiximenis]

Hi, one of the maintaners / main coders here :)

@vpereira01 You asked "Why" we are using underscore, so let me answer you: this is our personal preference. Nothing less, nothing more. Me (and other peers in the project) started to use .NET from the beginning, where using underscore was the facto-standard. So it is natural for us to use it :)
If you ask me to defend "why using underscore is good/better/needed" I don't have any valid answer. Just use it because we like/feel comfortable with it.

About the code guidelines that @CESARDELATORRE linked before, I want to raise a warning here...
Yes, in https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/fields the recommendation is not use underscore, but if you go to almost any Microsoft public github you'll see how they are effectively using it. Some examples:

• https://github.com/aspnet/EntityFrameworkCore/blob/release/2.2/src/EFCore/DbContext.cs
• https://github.com/aspnet/Mvc/blob/release/2.2/src/Microsoft.AspNetCore.Mvc.Core/ControllerBase.cs
• https://github.com/aspnet/SignalR/blob/release/2.2/src/Microsoft.AspNetCore.SignalR/HubRouteBuilder.cs

Those are all repos from Microsoft, and you can see that they are not only using underscore but also are not following some other guidelines. For example published guildelines say "Do not use var when the type is not apparent from the right side of the assignment." but again if you look the source code of almost all public Microsoft repos you will see that var is used everywhere. Always. Also some tools (like R#) promote the use of var always (and there are a lot of good reasons for using var always).

My opinion about the published guidelines: take it as a starting point, but nothing more. Be critical aboyt them, and always, always, always look other people code :)

I agree that the using of underscore is only a matter of personal preferences (same as using always this to access current object members). What is important is to keep a consistent coding style in one project, do not matter if you use underscore or not, or use this. or not if you are consistent.

Personally I don't see any value to remove the use of underscore at the current stage of project, and I am against to do it progressively when updating the code because this would break consistency. But, of course, this is just my personal preference.

:)

[vpereira01]

Again, thanks for feedback. I agree that a progressive change is worse, is better to just keep one standard at a time.

My only struggle with _field/variable/Property (vs this.field/variable/this.Property) has been that I find it harder to identify what's a class field/property due to the lack of this but that's probably habit.

[CESARDELATORRE]

Agree with Edu in most of it. Then, about my point about progressive changes, I mean within a whole microservice. It wouldn't be consistent to have part of one microservice following one way and part of the same microservice with a different style, of course.
In any case, to me is not an important issue unless identified areas/boundaries such as a microservice or a single web app has different style approaches. At least it should be consistent within the boundaries in the code/projects.