|
Slacker007 wrote: it's main purpose is code readability.
Its main purpose is actually anonymous types.
|
|
|
|
|
|
var is ok as long as I can have a look to the code in VS with the help of intelisense.
But in case I study a code snippet on www it becomes simply horrible because the real type is something hidden
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
As far as I can tell most uses of "var" are sheer laziness. The only time I var useful is when I need to store the results of a LINQ expression for later processing.
|
|
|
|
|
I rarely use var but I do use it when returning a tuple from a method to avoid out parameters. For example
void MainMethod() {
...
var methodCall = SomeMethod();
if (!methodCall.Success) {
return;
}
...
}
(bool Success, int? ReturnValue) SomeMethod() {
int? retValue;
...
if (...) {
return (Success: false, ReturnValue: null);
}
...
return (Success: true, ReturnValue: retValue):
}
|
|
|
|
|
Or better yet:
var (Success, ReturnValue) = SomeMethod();
if (!Success) {
return;
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Ah, the use of var. I know that some people use var to do code alignment on variable names; the idea being that it's easier to scan the name if it lines up.
private void DoSomething()
{
var apiEndpoint = new Uri("http://someapi");
var retryCount = 10;
var longClassName = new ThisIsAReallyLongNameThatWouldReallyScrewUpTheClassNameDeclaration();
}
|
|
|
|
|
Pete O'Hanlon wrote: the idea being that it's easier to scan the name if it lines up. That's my main argument (readability) and why I like it.
On the other hand, incoming Option #3[^] is good too.
It is a bit less readable, but still "forces" you to by type strong but combined with the lazyness / don't break the lines with long names too.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
is it lazy. Sure is.
Does it work. Unfortunately yes and Fortunately yes.
AS mentioned already when refactoring code and say a variable changes from int to long or even to a string it makes sure the code continues to work.
I don't like it. but that does not mean I have never used it. I have and I hate myself for it. But I remember one time I had to write a bit of code. The co-workers insisted that the variable would always be an integer. ALWAYS they said. having some experience I knew probably gonna change. About a year later system requirements changed. I had used var and the code still worked. sooooooo
tldr; lazy yes, flexible yes, hate myself yes.
To err is human to really mess up you need a computer
|
|
|
|
|
The problem with that is that you are working to what should have been a breaking change. And that's important, because if you were assuming int division as a result of the original type spec for example, then a breaking change means you know it's just failed and can adapt to it.
var in that case means you don't know, and output can be subtly wrong and unnoticed until it's a real problem.
I'd say var should be there for temporary storage of Linq results, and nowhere else ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
That's just pure laziness.
|
|
|
|
|
ZurdoDev wrote:
var url = "<a href="http: Is there some benefit to declaring most things var instead of what they actually are? In the case above, a string. Is it a string? Could it be a URI[^]
Uri siteUri = new Uri("<a href="http:
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
Yes, it was a string.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
But what if you meant it as a URI?
I think SQL would call this ambiguous
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
MadMyche wrote: But what if you meant it as a URI? Then you do new Uri(string);
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
When I moved from VB (where purists dump on var from a great height) to c# where explicit types were mandatory I lost all faith in var , it became the one thing in VB that I loathed. Now that it has phoenixed in c# I refuse to use it.
As for var content changing type and not having to refactor, what a croc of sh*t, you should HAVE to refactor if you change type or at least check your usage of the variable.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
VB doesn't have var ?
The equivalent would be:
Dim something = "my string" Which looks fine to me and is still strongly typed, unless Options Strict is Off.
Mycroft Holmes wrote: As for var content changing type and not having to refactor Using var is strongly typed so I don't really get what you're saying.
Are you thinking of dynamic or Option Strict Off (which luckily DOESN'T have an equivalent in C# )?
|
|
|
|
|
I use c# and almost never use var, and the content changing comment was a response to some of the previous posts.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I use var almost exclusively these days.
I started out using it sometimes, but then I started using it more and more.
To me, it just seems nice to have all my vars lined up nicely
Some people thing the var keyword isn't strongly typed, but it is (we have dynamic for that).
It's not like JavaScript's var keyword.
It's only absolutely necessary to use var when working with anonymous types (still strongly typed!).
|
|
|
|
|
The C# "var" construct and other such constructs in both C# and VB.NET are merely short-cuts or the usage of system defaults.
This makes for very ambiguous code over the length of an application's development.
This is why I don't even use the generic list-type and still use array-lists instead. Despite the slight performance decreases (which most will not notice since such constructs often do not contain thousands of objects or items in general), having easy to read strongly typed code makes my applications much more easily maintainable.
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
The last place I worked would fail you in code reviews if you did not use var. Their (ill) logic was something to do with a design pattern, and when Entity Framework would cough on var, they added lines of code to get it to pass instead of just using the correct type.
|
|
|
|
|
I (almost) only use var for non-production code, when I'm writing from whole cloth and doing initial diagnostics. As the code matures, I replace (almost) all instances of var with the actual types. Great way to force you to review and refactor before release.
For very long types, I'll use var , but only when the type is already included in the same location, like a declaration and instantiation.
|
|
|
|
|
Apart from the obvious (it saves typing and you have a set maximum number of keystrokes you can make in your life), it also allows for alignment which makes things easier to read (we're better with vertical scanning than horizontal scanning - for more see: https://www.youtube.com/watch?v=ZsHMHukIlJY and also there's just plain less to read!) but also because consuming code is more likely to survive a refactor intact: changing return type to something with similar shape means no consumer changes, renames of classes don't have to alter as many lines of code.
Since it's syntactic sugar, it costs nothing at runtime and it's normally one of the first automated fixes I do in a file when I enter legacy code.
------------------------------------------------
If you say that getting the money
is the most important thing
You will spend your life
completely wasting your time
You will be doing things
you don't like doing
In order to go on living
That is, to go on doing things
you don't like doing
Which is stupid.
|
|
|
|
|
I've read that convention is to use "var" when the type of variable is apparent by reading the code. If you printed out this code it would still be pretty obvious that "url" is a string. If you can't tell the type by reading the code then the actual type should be used. It is lazy but if it eliminates some redundancy and makes coding a little quicker than it's a good thing. I personally follow the convention above but I know some people use var for everything.
|
|
|
|