|
|
Hah! I just spent half an hour trying to persuade Google to let me know how you make suggestions for the C# spec ...
That language change I will use!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I kind of find it easier to read with var first.
But this is more secure, since you have to know what you are going to need and the you create the new instance in the lazy mode.
Best of both options, I guess
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.
|
|
|
|
|
OriginalGriff wrote: that would be a more natural way of showing what the type
Yup. And as I replied on the Insider News, what I really want is:
var foo = new();
In most cases, the compiler should be able to figure out what foo is by inspecting its usage in the code!
|
|
|
|
|
Marc Clifton wrote: In most cases, the compiler should be able to figure out what foo is by inspecting its usage in the code! If you turn the compiler into a psychic, be prepared for bad news
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Yes I agree
"We can't stop here - this is bat country" - Hunter S Thompson - RIP
|
|
|
|
|
C# 9.0 will have it: Welcome to C# 9.0 | .NET Blog
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Dictionary<SomeKey, List<KeyValue>> complicatedDictionary = new ();
Is on the planned list for C# 9.0.
|
|
|
|
|
+1
For native types, I don't see the point in using var. I also subscribe to the idea of using:
var x = new SomeMoreComplexType();
I don't mind:
var x = SomeFunction();
...if I don't particularly case about the type returned, for example, if I only use it to forward to some other function and I'm not looking at any of its members myself.
|
|
|
|
|
it is good for a lot of applications but can be missused very easily.
it's main purpose is code readability.
MyMostExcellentBaseClassOfAllClassesInTheWholeWorld myClass = new MyMostExcellentBaseClassOfAllClassesInTheWholeWorld();
or
var myClass = new MyMostExcellentBaseClassOfAllClassesInTheWholeWorld();
It is really good when working with Linq, etc. as well.
|
|
|
|
|
I'd rather see it as:
MyMostExcellentBaseClassOfAllClassesInTheWholeWorld myClass = new *(); If that was possible.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I think you can find instructions on how to create your own programming language here on CP, actually...
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
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
|
|
|
|