|
Call them back tomorrow, and ask them if it is standard policy to bother people who are working with uninvited questions. Then, Google "questions", and ask more of those.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Inform them of your recent passing ?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Judy the Zootopia[^] admits like she already experienced in the sloth.
It's time to restarts and defragment.
The best way to make your dreams come true is to wake up.
Paul Valery
|
|
|
|
|
Your laptop is slower than the last 10 minutes of the last day of school?
If your laptop was going any slower, it would be going backwards?
|
|
|
|
|
1) To do
2) To do
3) To do, to do, to do, to do, to doooooooo
I'll get me coat.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Sounds more like "Scooby Doo meets the Pink Panther."
Marc
|
|
|
|
|
I'm not responsible for how the voices in your head sound! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Is it weird that I read "I'll get me coat" to the melody of the song as well? 
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill
America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde
Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
|
|
|
|
|
|
[disclaimer] OK, this is probably a totally lame post. [/disclaimer]
When you use var (or even if you just embed the rvalue as a parameter to another method), you don't need to reference the assembly containing the type.
var prop = rec.GetType().GetProperty(propName);
Doesn't require using System.Reflection;
And Intellisense works just fine. But this:
PropertyInfo prop = rec.GetType().GetProperty(propName);
Does.
Neither does this:
object val = Converter.Convert(data, rec.GetType().GetProperty(propName).PropertyType);
I find that, well, interesting.
(I'm using VS2015, lest anyone even care.)
Marc
|
|
|
|
|
|
Great points. And you can also mouse over the var to see its type.
And the readability definitely comes to full expression when you have something like this:
Dictionary<string, Tuple<int, int>> fieldIndexLengthMap = GetMap();
But I still find myself avoiding var except in specific cases - for example when I get a collection and then immediately iterate over it:
var cps = el.GetConnectionPoints().Where(cp2 => cp2.Type == c.ElementConnectionPoint.Type);
cps.ForEach(cp => c.ToElement.MoveAnchor(cp, c.ToConnectionPoint));
One argument one might use for people (like me!) who say "but I want to know what type it is!" is to ask them if they use Linq or anonymous methods. In the above example, cp2 is like a var -- it has no type definition. Or, sndr and args here:
mnuImport.Click += (sndr, args) =>
{
canvasController.DeselectCurrentSelectedElements();
mnuImport_Click(sndr, args);
};
Which, oddly, makes me question why I'm so gun shy myself about var.
Marc
|
|
|
|
|
Simple case against that reasoning; var does not just hide the type, it accepts every type - and that might change, without going noticed when using var. When you specify which interface you are using you don't run into that problem.
Then again, that is covered by the first paragraph in your post, by the "not being an idiot" bit. Combine both, and you'd get below example;
var con = (IDbConnection) Factory.GetConnectable(); If you are talking about readability, I'd recommend against stating the obvious and ommitting "this" until it is actually required.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Simple case against that reasoning; var does not just hide the type, it accepts every type - and that might change, without going noticed when using var. When you specify which interface you are using you don't run into that problem.
Yup, although much of the time when you change the type you do end up getting breakage that needs fixed to compile anyway.
Like Marc, storing the dumpster fires that linq often returns as temporary/local/ephemeral variables (if I want to persist it I force it into something non-retarded) is one of the two places I normally use var.
The other is when declaring my own dumpster fire generics because in these cases the type information is already explicitly given 10 or 30 characters to the right..
var whyGodWhy = new Dictionary<string, tuple<int, List<myType>>>();
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Dan Neely wrote: The other is when declaring my own dumpster fire generics because in these cases the type information is already explicitly given 10 or 30 characters to the right..
Yup, that's the DRY version.
Now some people might put such an example in our "Weird and Wonderful" section, but repeating the same type-information without any benefit would indeed be worse 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Dan Neely wrote: The other is when declaring my own dumpster fire generics because in these cases the type information is already explicitly given 10 or 30 characters to the right..
Yup, that's the DRY version.
Now some people might put such an example in our "Weird and Wonderful" section,
If it was undocumented or part of a public API I'd probably be one of them. For something internal to its user a paragraph unpacking what the structure is is lighter weight than a the pile of wrapper classes I'd need if it was publicly accessible.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
|
N_tro_P wrote: Actually that is why its good.
It is if you dislike strong typing, in which case you might prefer VB.NET
N_tro_P wrote: So because you casted it and now have a run time failure it is var's fault?
No, I did not state that; merely that it would be redundant to repeat the type instead of using var.
Do elaborate and please explain what in your eyes I would have blamed on var?
N_tro_P wrote: The fault is on the guy that casted it when it should have returned as the needed type for the method it is in.
You go ahead and complain with Microsoft, I'll be waiting here for the result.
N_tro_P wrote: Again, don't be an idiot and it works fine.
The not being an idiot part would IMO be that you verify that you get what you expect, and not to use "var" as a "variant" from VB.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
N_tro_P wrote: So my point was, the return differences would have been fine if you did not cast.
The cast is there to specifically say which interface is expected.
N_tro_P wrote: So my point was, the return differences would have been fine if you did not cast.
That argument is pro weak typing, isn't it?
N_tro_P wrote: That's not MS's fault. Tis the point. That is the fault of the bad programmer.
The DbProvider returns a class, but I only use the interface - so when I can be specific about which type I expect, I do.
N_tro_P wrote: But now you just used circular logic. You are saying it is bad because people that use it are bad, and people that use it are bad because it is bad.
No, again, you are reading what is not there. I merely state that not being an idiot would mean that you verify, and not generalize.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
N_tro_P wrote: By placing the cast you create a potential run time error that was not even necessary
At run-time?
N_tro_P wrote: (rhetorical question actually)
Yeah, that helps clarifying the topic 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
N_tro_P wrote: Are you seriously having issues over a hyphen
No. Just the difference with compile-time
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The only time var really hurt was when converting from IEnumerable to IQueryable.
Something like the following:
var things = context.Things.ToList();
Now what happened, someone removed the call to ToList!
IEnumerable became an IQueryable (which actually IS an IEnumerable).
Nothing broke, it's just that with every usage of the things variable a database call was made.
Things got a lot slower.
Until someone noticed the boo boo.
I'm also not a fan of using var in "generic" code.
Something like IObjectGetter.Get. At least let me know what type of object Get is going to return by not using var.
That's why I don't use var.
I often don't really care about the type that's returned, but I want to see you THOUGHT about what type you expected.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
