|
C# is strict by default, dynamic is the Option Strict Off 
|
|
|
|
|
I have seen a VB var reused to hold a different variable elsewhere in the code. And the comment the original coder wrote was "reusing a variable, this is really efficient coding".
What a prat.
|
|
|
|
|
I guess it keeps the stack nice and clean 
Too bad his comment takes up the resources that his efficient coding saved 
|
|
|
|
|
Comments aren't compiled.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
<- sarcasm face...
|
|
|
|
|
I have a strong dislike for var. Makes me guessing the data type while reviewing someone's code. It's a true irritant. May be I'm very old school, but this is how I feel. I cannot look at a variable name without it's data type explicitly specified. 
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
|
|
|
|
|
I can see why you need var - you can't use Linq properly without it - but it gets used as a lazy "I don't care" variable type which doesn't help comprehension and maintenance at all.
And dynamic I suspect is only there so VB programmers feel at home...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
dynamic is part of the Dynamic Language Runtime, which allows interoperability with loosely typed languages such as Ruby (or so I'm told).
It also comes in handy when using late binding with COM objects.
And I've used it once or twice with some Type<T> where T isn't really important, but can't be deduced, for example List<T>.Count.
var is really only necessary for anonymous types.
|
|
|
|
|
OriginalGriff wrote: you can't use Linq properly without it
You mean stuff like =>
MyModel _currentModel = _myModelList.Find(Mml => Mml.IdModel == InIdOfModel);
?
Yeah, my codestyle might be offending... 
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Yes, you can use bits of linq without var, but once you get to anonymous types (which is one of it's big strengths) you need var as you can't declare a variable of an anonymous type.
It should have stayed that way: var would have been a whole load better if it only contained anonymous types and null values...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
The most offending is your mix of camelCase, PascalCase and underscores in variable names... 
|
|
|
|
|
But actually there is a logic behind it 
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
How else do you quickly identify between private, protected, and public? Or properties and fields? Or foos vs bars?
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Hungarian notation, of course, but at least properly camelCase and PascalCase them 
Unless you're serious, in which case I don't know how to answer that
|
|
|
|
|
Only a little. I like camelCase for javaScript and Pascal for C#, and the only reason I do that is to keep it 100% clear if a variable lives on the client or the server.
Hungarian notation. So gross.
(PS: You could answer it with "Go look at the declaration, fool!")
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: Hungarian notation
Quote: Linus Torvalds
“Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged – the compiler knows the types anyway and can check those, and it only confuses the programmer.”
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Nathan Minier wrote: (PS: You could answer it with "Go look at the declaration, fool!")
No that's what many people think, but real Hungarian is not about simple type prefixes.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Sure, but it will address every question I asked
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Sander Rossel wrote: Unless you're serious, in which case I don't know how to answer that
So you have no answer 
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
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).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
