|
Well, I have plenty, but my mother taught me that if I don't have anything nice to say I best don't say anything at all 
|
|
|
|
|
That's very kind 
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
OriginalGriff wrote: I can see why you need var - you can't use Linq properly without it
Why not?
I always use explicit types also with Linq, never had a problem so far.
|
|
|
|
|
IQueryable<anonymous type>? 
|
|
|
|
|
As I wrote, I always use explicit types. Never needed anonymous types.
That kind of laziness always leads to trouble further down the road.
That's like using SELECT * in SQL.
|
|
|
|
|
I use anonymous types quite a lot, they're nothing like SELECT * (which is just bad practice and may have some unexpected side effects).
Sometimes you just don't need an entire entity (when working with EF) and you just select two or three fields.
Creating a class just to be used in a single function is kind of overkill and clutters your code base.
Just use an anonymous type, get the fields you want, use them in just that one function, and be done with it.
The compiler still creates an "actual class", so it behaves and performs just as if you wrote the class yourself, but without the clutter 
I also use it for ad-hoc return models in MVC.
Same issue, creating a class for use in a single function just clutters your code.
Your front-end makes it JavaScript so it loses its type anyway.
When you decide you need to make it a class later on that's perfectly possible (there's even a shortcut for it) and it has no side-effects whatsoever (as it was already a class after compilation) so it's clean and easy.
You may not need them per se, but it makes your code cleaner and easier to read.
Not using them is just limiting yourself by not using a great tool from your toolbox (unlike SELECT *, which, again, is just bad practice).
|
|
|
|
|
Sander Rossel wrote: Just use an anonymous type a tuple, get the fields you want, use them in just that one function, and be done with it.
FTFY
Sander Rossel wrote: Creating a class just to be used in a single function is kind of overkill and clutters your code base.
It could be argued that mixing dataaccess into your functions also clutters the code.
Sander Rossel wrote: Your front-end makes it JavaScript so it loses its type anyway.
Not everything is used on the web, but I would use typed code in the business layer anyway, it lower the number of bugs considerably.
Note that anonymous classes are still typed, you just don't know what type. I just prefer to know!
Sander Rossel wrote: You may not need them per se, but it makes your code cleaner and easier to read.
That's an opinion.
|
|
|
|
|
A TUPLE!?
Because having property names "Field1", "Field2" and "Field3" is so much better than actual meaningful property names? 
I've used tuples once or twice and I've always came to regret it when I needed to change the code a week later.
Tuples were added for support with functional languages, F# specifically, that use tuples a little different than C#.
Jörgen Andersson wrote: It could be argued that mixing dataaccess into your functions also clutters the code.
Again, you're talking about bad practice and there are very good reasons to "clutter" your code here. Using anonymous types is NOT bad practice.
Jörgen Andersson wrote: Note that anonymous classes are still typed, you just don't know what type. I just prefer to know!
Why does the type of the object matter so much? It's just a type with some strong-typed properties that you'll never use again.
In cases such as this you're not using the type at all, so why type it out?
return Json(new { Name = name, Valid = valid });Jörgen Andersson wrote: That's an opinion fact.
FTFY
|
|
|
|
|
Sander Rossel wrote: I've always came to regret it when I needed to change the code a week later.
But that wasn't because it was a Tuple was it?
|
|
|
|
|
Yes it is.
How the hell should I know what "Field1" or "Field2" is.
Need to look back at the definition to see how it's created...
Readability is NULL 
|
|
|
|
|
Some time ago we had a version of Resharper that insisted on changing everything to var everywhere.
But we changed the Resharper rules as we didn't like that very much ...
|
|
|
|
|
Yes, I had a predecessor who Resharped a massive project with "change everything to var for no justifiable reason" set as an option. Horrible, horrible, horrible!
I think it used to be on by default but isn't any more but either way, it's an utterly ridiculous option in an otherwise splendid product.
98.4% of statistics are made up on the spot.
|
|
|
|
|
Where I work now uses "var" simply because resharper\validation tools tell them to. When you ask why they use var, what advantages it gives, no-one can actually tell you, they simply say "that's the standard". Your code fails review if you don't use var so I write my code like a normal sane person and when I come to check it in I change all my types to "var", check it in then die a little inside.
|
|
|
|
|
Go with the flow my friend 
[Flush]
|
|
|
|
|
ReSharper is a mighty tool! But like with any other tool if you use it wrong it causes damage...
They really should update the rules of ReSharper.
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
MyMostExcellentPDFCreateAndReaderAndEmailer pdfWhatever = new MyMostExcellentPDFCreateAndReaderAndEmailer()
or
var pdfWhatever = new MyMostExcellentPDFCreateAndReaderAndEmailer()
It is just neater and you know the type because of the instantiation.
BTW, ReSharper is such a great tool, that Microsoft is duplicating its functionality and baking it into their own IDE starting with VS2017 + updates.
Also, a lot of the devs at Microsoft, use ReSharper.
|
|
|
|
|
Excellent example. "var" is hiding the actual problem which is your terribly named class.
|
|
|
|
|
|
Strange conclusion. Most people would say putting type names in functions is a newbie mistake.
var intAge = GetAgeAsInt();
Cool code, bro. I love how you use one anti-pattern to solve another 
Edit: lol thought we were talking about calling methods, not defining variables, that's not really the issue.
|
|
|
|
|
|
This isn't the soapbox, if all you're going to do is troll then don't bother posting at all.
|
|
|
|
|
var is more than accepted when used correctly. To argue this makes you look like a newbie. Get over it.
See my reply to the the OP as well.
Other than that, 
|
|
|
|
|
Slacker007 wrote: var is more than accepted when used correctly.
We're talking about using it everywhere as dictated by these tools so you're fighting straw-man arguments.
Nice edit BTW, but I saw the comments before you deleted them, probably because you realised what a hypocrite they made you sound.
|
|
|
|
|
|
#Troll, troll, troll your boat....#
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
