|
Actually your example is quite interesting, as it isn't really a String but rather Uri.
The correct way to declare it would have been
using System;
...
Uri url = new Uri("http://www.contoso.com/");
WebRequest wr = WebRequest.Create(siteUri);
But as you might have figured, you could have just used this instead
var url = new Uri("http://www.contoso.com/");
var wr = WebRequest.Create(siteUri);
or just
var url = "http:// www. contoso.com/";
var request = WebRequest.Create (url);
|
|
|
|
|
Member 2896020 wrote: var url = "http:// www. contoso.com/";
var request = WebRequest.Create (url);
Which is essentially what it was. But url is a string. I don't see the value in typing var instead of 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.
|
|
|
|
|
The problem is that it sometimes becomes a style guideline in teams. I have seen that happening before, which is just stupid to me.
"Oh, but you can just hover over it and you will see". This mindset can be a real nightmare on code reviews.
I hate the laziness that motivated most var uses I have seen. People don't even know why var was created (to support anonymous types).
There are though, as some people have already mentioned, some situations where var makes the code cleaner. But I actually never seen that kind of diligence, so wherever I could I abolished the used of var for non anonymous types.
To make matters worse, stupid resharper (that some people like to use) has the default setting that everything should be var. So it pretty much converts the new-comers to the var mindset from the start.
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
|
|
|
|
|
For primitive types I like to say what they're BUT var should be used for most other types.
For example
var myGeneric = new List<List<Dicinary<string, string>>>();
VS
List<List<Dicinary<string, string>>> myGeneric = new List<List<Dicinary<string, string>>>();
Both are the same but one much easier to read.
|
|
|
|
|
In my experience, the need to use var arises from wanting to hide the sometimes lengthy names of collection iterators in foreach declarations. Especially when Linq is used to get the collection, the declaration can become messy.
But you now how it goes: first it's to shorten lengthy iterator names, then lengthy class names, then pretty much everywhere because it looks more consistent for some people.
I can support the use in foreach declarations, but everywhere else it's more of an annoyance.
I never understood the desire to hide stuff like this. It's like an unspoken commitment to never refactor whatever is hidden.
On a related note: Regions. Why?
|
|
|
|
|
I really like the short notation.
When I need to know what type the variable is, I hover the mouse cursor over it and it will show the actual type.
And so long as I am not paid by the character, I will use the shortest notation I can use.
|
|
|
|
|
Resharper encourages var use for whatever reason. However, it does show what the actual type is.
|
|
|
|
|
There is no advantage. If you just write a scribble, then always using var is Ok. But if you write production-level code, var is sloppy style and thus an absolute no-go. Before IntelliSense was able to automatically convert the var's in your source code to the correct type, var was even an evidence of a programmer not knowing what type they're using.
Only exception: Use var to avoid writing the same type twice in the same line.
Bad
List<string> list = new List<string>();
Good
var list = new List<string>();
Because then, when you want to change the type, let's say from List to HashSet, you only have to change it once. IntelliSense also suggests this, at least in VS 2017.
|
|
|
|
|
|
centre of all is the letter l. As to the rest, a bit obscure.
|
|
|
|
|
|
Randor wrote: Deal with it.
Already done. 
|
|
|
|
|
Hi all,
After finishing my time tracker application, I've done a small page that shows the amount of hours worked in function of the filters selected.
I would like to plot that data to make it easier to understand...
I have:
office hours
remote hours
telephone time
travel hours
...
And I want to have it represented through time...
Line, bars, stacked bars... what do you think would be the best to represent this?
As always thank you in advance!
|
|
|
|
|
I like stacked bars for this - it really does depend on why you're comparing the data
|
|
|
|
|
If there is only one user being displayed then I would say a pie or column chart (or maybe both), if you have multiple users being displayed then probably a stacked column would be best.
I am curious though, what is "telephone time" that isn't a subset of office/remote time?
|
|
|
|
|
I bill for several different concepts:
- office programming time.
- customer office/workshop programming time.
- consulting.
- phone support. <= phone time... (which usually I don't bill).
- travel hours.
- training hours.
- km.
- restaurant tiquets.
- tolls.
- ...
Those are quantified in my summary/report view and I want to have them depicted into that graph.
|
|
|
|
|
Employees in office bathrooms is where the telephone time kicks in.
| 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 seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
A Pie chart.
I like pie ... 
And if you are looking for proportion-of-time-spent, it really is the best iype.
Otherwise, I prefer line charts if there is a lot of data, preferably with 10-day and 30-day moving average lines shown as well.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: I like pie
I bet you do.
|
|
|
|
|
OriginalGriff wrote: with 10-day and 30-day moving average lines shown as well
Bullish if the 10-day crosses above the 30-day!
I don't think I've ever seen moving averages outside of technical analysis charts. I must have led a sheltered life.
|
|
|
|
|
They are handy for spotting short-time-frame trends, so you can do something about it before it becomes a problem.
For example, if you monitored read errors on an HDD, then a moving average can show clearly that there is a problem, and you should be backing up today ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
What do you mean, "backing up"? I have an SSD, and everyone knows they are infallible!
|
|
|
|
|
<zombie voice>PIEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!</zombie voice>
|
|
|
|
|
I was taught that line graphs should only be used for continuously varying data, whereas bars should be used for discrete values. In this instance the time spent per day is a discrete measure (unless maybe you're working a 24-hour day) so bar is "correct". Whether pie or bar depends on whether it's the ratios of the different types or their absolute sizes you want to illustrate; though it's possible to show both in a pie chart by having different sized pies, of course.
|
|
|
|
|
Everybody wants to view a graph differently, so instead of picking one, I'd give the user an option to select from several different flavors, no pun intended.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
