Not programming, but a preference question.
-
Collin Jasnoch wrote:
var component = new ThirdPartyNameSpace.RequiredComponent(); var diffComponent = new DifferentThirdPartyNameSpace.RequiredComponent();
I read this and thought: "What the hell is the type returned by this methods?" "Oh wait, these are not methods, these are fully qualified types." Can you picture the ammount of unnecessary confusion created by this code when someone else try to read it? Or even your self after sometime? This easy to write and terrible to read. If you inherit a code that has a lot of vars good luck sweeping the code to understand its purpose. If you have a printed copy of the code, well then there is no way to understand the code.
Collin Jasnoch wrote:
ThirdPartyNameSpace.RequiredComponent ewComponent = new ThirdPartyNameSpace.RequiredComponent();
That's what the "#using" directive is for, then you would have:
RequiredComponent notEwAtAllComponent = new RequiredComponent()
Now you have a very readable code and intellisense made it not hard to type, magic heh? When looking at the code from a mostly left to right culture I can instantly identify the type being declared. Second, if you have components with same names and different namespaces, you can make it much shorter also with the "#using" directive: #using ThirdPartyNameSpace; #using diffNS = DifferentThirdPartyNameSpace;
diffNS.RequiredComponent diffComponent = diffNS.RequiredComponent();
Lastly, var should be used for anonymous types. That's the real good use of it and shouldn't be abused like I often see. Your particular example is a hell to review.
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
As was pointed out by others alias names are definitely not a solution to the problem. In fact they are worse, IMO (maybe I am alone there though)
Fabio Franco wrote:
Can you picture the ammount of unnecessary confusion created by this code when someone else try to read it? Or even your self after sometime?
Simply put no I do not. A good programmer does not need the definition of the type to leave knowledge of what is happening. For example:
var saleId = GetActiveSaleId();
if(Customer.Sales.Contains(saleId))
{
//run some code
}Do you care what saleId is? Does it really matter if it is
intor a custom object? It shouldn't. Under the thought of I must know the type programmers do stuff like this.IEnumerable<DataWarehouse.Sales> sCollection = CustomerCollection.GetActiveCustomer().Sales;
int id = ActiveSale.GetId();
...if(sCollection.Contains(id))
{
//run same code
}The first has a clean if statement. I need not know what the actual objects are and no exactly what is going on. The later I am immediately confused as I am unsure what sCollection is or what I am checking with. You see that the definition has nothing to do with clarity. Maybe my brain works different. I have used languages that do not have concrete definition (e.g. Ruby) and have worked in teams that demanded proper naming. I also demand it and hopefully you see why
Fabio Franco wrote:
If you inherit a code that has a lot of vars good luck sweeping the code to understand its purpose. If you have a printed copy of the code, well then there is no way to understand the code.
Again I have no problem sweeping "good" code that only uses vars. Using vars is irrelevant. I have swept code that did not even used vars and 'weeped' a little. I think you really drive my point with "copy of the code". One should be able to copy the code with out the definition and allow a reader to understand it. That is good code as it is transferable even out of the language then.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Collin Jasnoch wrote:
Return object changes.
If you have a lot of code which would make that a valid rational then I would suspect something is wrong with your code/design.
Have you ever used third party libraries? Things do become obsolete and change. Doesn't even have to be "Third Party". Could be the actual framework itself. This seems to be your most common response to my posts. Most of the time you just don't even grasp the point. Which is again the case. You take a small example I give and use that to troll my posts claiming my code has bad design. Examples are examples. If I can show a simple case where it happens (see above) it fits. Either respond to the actual point or don't respond at all.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Compile it, and look at the errors. best, Bill
"The greatest mystery is not that we have been flung at random between the profusion of matter and of the stars, but that within this prison we can draw from ourselves images powerful enough to deny our nothingness." Andre Malraux
Have you ever heard of pseudo code? My code was not given in a response to someones question about how to solve something. It was given in a response for showing why you should not do something. If you fail to grasp the difference and expect to find usable code in the lounge you are mistaken. I never claimed it was usable code. It got the point across did it not? Yet you ramble on about compile issues. Are you griping because the classes are not public? Are you griping because of typos? Are you griping because my methods do not exist? Who cares? How is this relevant at all to the topic at hand? Again, code was not given to correct an issue. It was given as a case to prove a point.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Yes, esteemed colleague, Colin, you are missing something, and it's an understanding of how you can "legally" use 'var. Since the use of 'var is a major focus of this thread, I feel that's important. I would never have commented on your code based solely on errors in spelling. And, the comment on two classes with duplicate names was meant as a "lightweight" suggestion, not an attack. Surely it is not too much to ask for anyone who posts code, even here on the Lounge, to compile it, and see if it compiles ? Meanwhile, may the hair-trigger fingered down-voters (and I don't mean you) just keep having at me, because I will say what I see, and the compiler (VS 2012 RC in this case) reports as errors :) best, Bill
"The greatest mystery is not that we have been flung at random between the profusion of matter and of the stars, but that within this prison we can draw from ourselves images powerful enough to deny our nothingness." Andre Malraux
Not sure why you would expect code given as an case on a topic to compile. Was not provided as a solution to any problem. Was not provided as a real code base even. It was a simple example. If you would like to explain my "illegal" usage of var then by all means explain away. Also, you are using a Beta product. I see errors in there that should not exist as its beta. Try this. When using XAML resources type "ResourceKey" as it prompts you. Then compile. Totally irrelvant to the topic at hand, I know. :rolleyes: P.S. I have not downvoted you. But I would presume the downvoters are doing so mostly because you are not actually posting what you are talking about. Why keep telling us to compile the pseudo-code? Why not just post the error you are seeing and explain why you think I incorrectly used 'var'?
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
As was pointed out by others alias names are definitely not a solution to the problem. In fact they are worse, IMO (maybe I am alone there though)
Fabio Franco wrote:
Can you picture the ammount of unnecessary confusion created by this code when someone else try to read it? Or even your self after sometime?
Simply put no I do not. A good programmer does not need the definition of the type to leave knowledge of what is happening. For example:
var saleId = GetActiveSaleId();
if(Customer.Sales.Contains(saleId))
{
//run some code
}Do you care what saleId is? Does it really matter if it is
intor a custom object? It shouldn't. Under the thought of I must know the type programmers do stuff like this.IEnumerable<DataWarehouse.Sales> sCollection = CustomerCollection.GetActiveCustomer().Sales;
int id = ActiveSale.GetId();
...if(sCollection.Contains(id))
{
//run same code
}The first has a clean if statement. I need not know what the actual objects are and no exactly what is going on. The later I am immediately confused as I am unsure what sCollection is or what I am checking with. You see that the definition has nothing to do with clarity. Maybe my brain works different. I have used languages that do not have concrete definition (e.g. Ruby) and have worked in teams that demanded proper naming. I also demand it and hopefully you see why
Fabio Franco wrote:
If you inherit a code that has a lot of vars good luck sweeping the code to understand its purpose. If you have a printed copy of the code, well then there is no way to understand the code.
Again I have no problem sweeping "good" code that only uses vars. Using vars is irrelevant. I have swept code that did not even used vars and 'weeped' a little. I think you really drive my point with "copy of the code". One should be able to copy the code with out the definition and allow a reader to understand it. That is good code as it is transferable even out of the language then.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Collin Jasnoch wrote:
Simply put no I do not. A good programmer does not need the definition of the type to leave knowledge of what is happening.
Where did you get that from? Of course if you're developing an e-commerce application, that's the least of the worries. Now if you're developing an AI engine, or something that has hardcore business logic, then yes it matters. And also, you're not taking into consideration the fact that applications are not bug free, and several bugs happen from inappropriate assignments, and that sir is where having a type in a really clear view becomes important.
Collin Jasnoch wrote:
You see that the definition has nothing to do with clarity.
I disagree with the point you made.
Collin Jasnoch wrote:
I have used languages that do not have concrete definition
So have most of us, like javascript, it doesn't mean is a good thing. Then we will enter in a debate whether a strongly typed language is better. And to me is much, much better, that's why C# is my language of choice.
Collin Jasnoch wrote:
Using vars is irrelevant.
Right, so you see no problem in var receiving a type that is returned by method like:
var someCollection = configManager.GetConfigSettings();
Now, tell me, do you have any idea what the var type is inferring? To me using vars is lazy and a bad habit. You can find var usage recommendation in microsoft documentation, I just can't find it now where, but I bet if you're interested, you'll find. And the recommendation is to use var other than anonymous type only if the team is in a common consensus with it. Actually the var keyword only came to be because of the necessity to infer types when LINQ was introduced
Collin Jasnoch wrote:
One should be able to copy the code with out the definition and allow a reader to understand it.
I agree, but again, not everything is as simple as that. Having a general understanding reading the code because it has proper naming and all that stuff is simply a ground rule. Now, understanding the details, specially when using not so trivial types from things like base class libraries, marshaling and reflection, well, sorry, that won't be enough. I think you may not have gotten to the point to develo
-
Fabio Franco wrote:
Visual Studio:
Right click -> Go to DefinitionYeah, that doesn't interfere with "sweeping the code to understand its purpose" at all! ;P It's easier to scan a "
var x = new RealName()" statement than a "AliasedName x = new AliasedName()" statement.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Richard Deeming wrote:
Yeah, that doesn't interfere with "sweeping the code to understand its purpose" at all!
You got me here :) Anyway, that's just a case
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
-
Have you ever used third party libraries? Things do become obsolete and change. Doesn't even have to be "Third Party". Could be the actual framework itself. This seems to be your most common response to my posts. Most of the time you just don't even grasp the point. Which is again the case. You take a small example I give and use that to troll my posts claiming my code has bad design. Examples are examples. If I can show a simple case where it happens (see above) it fits. Either respond to the actual point or don't respond at all.
Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Collin Jasnoch wrote:
Things do become obsolete and change.
Doesn't even have to be "Third Party". Could be the actual framework itself.That has nothing to do with the statement that I quoted. There a many, many ways in which new requirements can make changes necessary. The specific case that you mentioned is a small, small fraction of that.
-
Collin Jasnoch wrote:
Simply put no I do not. A good programmer does not need the definition of the type to leave knowledge of what is happening.
Where did you get that from? Of course if you're developing an e-commerce application, that's the least of the worries. Now if you're developing an AI engine, or something that has hardcore business logic, then yes it matters. And also, you're not taking into consideration the fact that applications are not bug free, and several bugs happen from inappropriate assignments, and that sir is where having a type in a really clear view becomes important.
Collin Jasnoch wrote:
You see that the definition has nothing to do with clarity.
I disagree with the point you made.
Collin Jasnoch wrote:
I have used languages that do not have concrete definition
So have most of us, like javascript, it doesn't mean is a good thing. Then we will enter in a debate whether a strongly typed language is better. And to me is much, much better, that's why C# is my language of choice.
Collin Jasnoch wrote:
Using vars is irrelevant.
Right, so you see no problem in var receiving a type that is returned by method like:
var someCollection = configManager.GetConfigSettings();
Now, tell me, do you have any idea what the var type is inferring? To me using vars is lazy and a bad habit. You can find var usage recommendation in microsoft documentation, I just can't find it now where, but I bet if you're interested, you'll find. And the recommendation is to use var other than anonymous type only if the team is in a common consensus with it. Actually the var keyword only came to be because of the necessity to infer types when LINQ was introduced
Collin Jasnoch wrote:
One should be able to copy the code with out the definition and allow a reader to understand it.
I agree, but again, not everything is as simple as that. Having a general understanding reading the code because it has proper naming and all that stuff is simply a ground rule. Now, understanding the details, specially when using not so trivial types from things like base class libraries, marshaling and reflection, well, sorry, that won't be enough. I think you may not have gotten to the point to develo
You again have completely missed the point and your example proves it. In your example you show a definition of a variable but no usage. Do you know what happens when you do this in code? The compiler throws it away. It's useless so what's the point. My point is the usage of variables should make it clear what is happening. More often than not (yes even in AI) the type is irrelevant.
if(entityID < otherEntityID)
{
//process
}Why do you care if someObject is
int,double, or a custom object the uses the < operator? You shouldn't. If you need to know that you really don't grasp SOC and OOP. The only thing you need to know is what should happen when the first is less than the second. The how it is implemented is only needed to be understood by the developer of the type be it code>int,double, or a custom object. FYI I have developed image process techniques, AI image processing, motion tracking, data regression, machine UIs, web clients, web MT, eCommerce modules, and much more.Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
You again have completely missed the point and your example proves it. In your example you show a definition of a variable but no usage. Do you know what happens when you do this in code? The compiler throws it away. It's useless so what's the point. My point is the usage of variables should make it clear what is happening. More often than not (yes even in AI) the type is irrelevant.
if(entityID < otherEntityID)
{
//process
}Why do you care if someObject is
int,double, or a custom object the uses the < operator? You shouldn't. If you need to know that you really don't grasp SOC and OOP. The only thing you need to know is what should happen when the first is less than the second. The how it is implemented is only needed to be understood by the developer of the type be it code>int,double, or a custom object. FYI I have developed image process techniques, AI image processing, motion tracking, data regression, machine UIs, web clients, web MT, eCommerce modules, and much more.Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Collin Jasnoch wrote:
More often than not (yes even in AI) the type is irrelevant.
I understand the point you're trying to make, but I strongly disagree with the statement above. The simple fact that you don't know if it's a reference or value type can make a whole difference on how the code behaves. If you're trying to debug something that's much, much worse. I find it really important to know the exact type of the object not only while developing, but while reviewing my team's code or inheriting projects from other teams. In the end, making C# just like JavaScript by using var everywhere, will make it lose most of the advantages of a strongly typed language (on an interpretation level) while keeping the disadvantages. You may not agree and if you don't this discussion will last forever and we will never convince each other of anything. And if there wasn't the need of var for anonymous types I wish it wasn't there, it would save me a lot of time on code review.
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
-
Collin Jasnoch wrote:
More often than not (yes even in AI) the type is irrelevant.
I understand the point you're trying to make, but I strongly disagree with the statement above. The simple fact that you don't know if it's a reference or value type can make a whole difference on how the code behaves. If you're trying to debug something that's much, much worse. I find it really important to know the exact type of the object not only while developing, but while reviewing my team's code or inheriting projects from other teams. In the end, making C# just like JavaScript by using var everywhere, will make it lose most of the advantages of a strongly typed language (on an interpretation level) while keeping the disadvantages. You may not agree and if you don't this discussion will last forever and we will never convince each other of anything. And if there wasn't the need of var for anonymous types I wish it wasn't there, it would save me a lot of time on code review.
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
I wish people would name appropriately.
varis not the problem. Developers naming standards are. That is my only point. You give an example of needing to know if it is ref type or value type. Well if the code requires you to need to know that you should include that info in the name. Same is true for even type info. If the code really requires to know if something is afloator adoublethen it should be called out in the name. At first when I would see this I would go X| But if the code clearly needed to be that way it would make sence. In such cases I would first wonder if refactoring was needed etc. I have seen cases where even this makes sence though (performance for different I/O). The declaration of a variable can be "screens" away from the usage that concerns you (ouch refactor that method). I.e. it should not matter, the name however is always present in its usage.Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
I wish people would name appropriately.
varis not the problem. Developers naming standards are. That is my only point. You give an example of needing to know if it is ref type or value type. Well if the code requires you to need to know that you should include that info in the name. Same is true for even type info. If the code really requires to know if something is afloator adoublethen it should be called out in the name. At first when I would see this I would go X| But if the code clearly needed to be that way it would make sence. In such cases I would first wonder if refactoring was needed etc. I have seen cases where even this makes sence though (performance for different I/O). The declaration of a variable can be "screens" away from the usage that concerns you (ouch refactor that method). I.e. it should not matter, the name however is always present in its usage.Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Collin Jasnoch wrote:
varis not the problem.But
varallows the problem to be created. Since we don't have control over how everyone follows good standards and naming conventions, havingvaravailable for everything creates a potential to have an even messier code. It's like Visual Basic. Visual Basic is much more forgiving and that creates a greater potential for bad code. I'm not saying Visual Basic developers are worse, I'm saying that because of what the language allows, we're much more susceptible to inherit bad code from bad developers.Collin Jasnoch wrote:
you should include that info in the name
But sometimes that can become impractical and confusing:
var refIEnumberableOfIntCompanyIDs = GetCompanyIDs();
There are many combination of ways we could write the code above to have all the meaning necessary for that variable. Instead of using
var, why not just:IEnumerable companyIDs = GetCompanyIDs();
Can it be cleaner than that? I doubt there is a way in C# to deduce the type of companyIDs faster and easier than that.
Collin Jasnoch wrote:
The declaration of a variable can be "screens" away from the usage that concerns you
Well it's just another one on the bunch. There are many other things that concerns me and just when I think there can't be anything else to concern me, there comes
vareverywhere :doh: My point is, don't using the wrong tool for the job, just because it makes your work easier.varwas designed to infer anonymous types and should rarely be used outside that scope. It may be easier to kill a cockroach with a bazooka, but please don't. That's the message I always try to transmit. Maybe my principle thatvarshouldn't be used anywhere other than to infer anonymous types, is a little to strict, but I'm surevarshouldn't be abused.varwas not designed so we could drop using explicit type declaration.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
-
Collin Jasnoch wrote:
varis not the problem.But
varallows the problem to be created. Since we don't have control over how everyone follows good standards and naming conventions, havingvaravailable for everything creates a potential to have an even messier code. It's like Visual Basic. Visual Basic is much more forgiving and that creates a greater potential for bad code. I'm not saying Visual Basic developers are worse, I'm saying that because of what the language allows, we're much more susceptible to inherit bad code from bad developers.Collin Jasnoch wrote:
you should include that info in the name
But sometimes that can become impractical and confusing:
var refIEnumberableOfIntCompanyIDs = GetCompanyIDs();
There are many combination of ways we could write the code above to have all the meaning necessary for that variable. Instead of using
var, why not just:IEnumerable companyIDs = GetCompanyIDs();
Can it be cleaner than that? I doubt there is a way in C# to deduce the type of companyIDs faster and easier than that.
Collin Jasnoch wrote:
The declaration of a variable can be "screens" away from the usage that concerns you
Well it's just another one on the bunch. There are many other things that concerns me and just when I think there can't be anything else to concern me, there comes
vareverywhere :doh: My point is, don't using the wrong tool for the job, just because it makes your work easier.varwas designed to infer anonymous types and should rarely be used outside that scope. It may be easier to kill a cockroach with a bazooka, but please don't. That's the message I always try to transmit. Maybe my principle thatvarshouldn't be used anywhere other than to infer anonymous types, is a little to strict, but I'm surevarshouldn't be abused.varwas not designed so we could drop using explicit type declaration.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
Fabio Franco wrote:
But sometimes that can become impractical and confusing:
var refIEnumberableOfIntCompanyIDs = GetCompanyIDs();
There are many combination of ways we could write the code above to have all the meaning necessary for that variable. Instead of using
var, why not just:IEnumerable<int> companyIDs = GetCompanyIDs();
Can it be cleaner than that? I doubt there is a way in C# to deduce the type of companyIDs faster and easier than that.
I understand exactly what you are saying but you are reading too much into needing to see the declaration. If you see a variable somewhere called
companyIdsyou can deduce it isIEnumerable. Sure it might be guids, ints, or some custom Id object. But this is the point I having been trying to make. If that matters then it should be clear in the name. The declaration accomplishes nothing that a mouse over did not. I still have to seek out the actual declartion. Whats the point? I can mouse over. That is faster. More efficient is avoiding that need. If the developer needs to know that it is aguidand not anintleave them a trail in the name.Fabio Franco wrote:
varwas not designed so we could drop using explicit type declaration.Just because silly putty was not designed to capture 'silly' comics does not make it wrong to use it as such (OT: Silly Putty was the first try at Plastic Explosives). I do understand you point. Espeacially your comment about VB being loose and allowing it. But My point is not at all that using
varis OK and not bad practice (the opposite of what many post). It is actually that the argument(s) against it is/are moot. If your only argument is that you have a clear declaration of the variable and need to know its type I have pointed out why that is irrelevant. 1. Naming is more approprate to relay a variables intended usage e.g.int c = GetActiveCustomerCount();vs.var activeCustomerCount = GetActiveCustomerCount();your responce to this has been:Fabio Franco wrote:
we don't have control over how everyone follows good standards and naming conventions, having
varavailable for everything -
Fabio Franco wrote:
But sometimes that can become impractical and confusing:
var refIEnumberableOfIntCompanyIDs = GetCompanyIDs();
There are many combination of ways we could write the code above to have all the meaning necessary for that variable. Instead of using
var, why not just:IEnumerable<int> companyIDs = GetCompanyIDs();
Can it be cleaner than that? I doubt there is a way in C# to deduce the type of companyIDs faster and easier than that.
I understand exactly what you are saying but you are reading too much into needing to see the declaration. If you see a variable somewhere called
companyIdsyou can deduce it isIEnumerable. Sure it might be guids, ints, or some custom Id object. But this is the point I having been trying to make. If that matters then it should be clear in the name. The declaration accomplishes nothing that a mouse over did not. I still have to seek out the actual declartion. Whats the point? I can mouse over. That is faster. More efficient is avoiding that need. If the developer needs to know that it is aguidand not anintleave them a trail in the name.Fabio Franco wrote:
varwas not designed so we could drop using explicit type declaration.Just because silly putty was not designed to capture 'silly' comics does not make it wrong to use it as such (OT: Silly Putty was the first try at Plastic Explosives). I do understand you point. Espeacially your comment about VB being loose and allowing it. But My point is not at all that using
varis OK and not bad practice (the opposite of what many post). It is actually that the argument(s) against it is/are moot. If your only argument is that you have a clear declaration of the variable and need to know its type I have pointed out why that is irrelevant. 1. Naming is more approprate to relay a variables intended usage e.g.int c = GetActiveCustomerCount();vs.var activeCustomerCount = GetActiveCustomerCount();your responce to this has been:Fabio Franco wrote:
we don't have control over how everyone follows good standards and naming conventions, having
varavailable for everythingCollin Jasnoch wrote:
If your only argument is that you have a clear declaration of the variable and need to know its type I have pointed out why that is irrelevant.
I do agree with your point but I still believe that using explicitly declared type (even when the type is not so relevant) is better than having
var. Sometimes we can't predict how the type will become actually relevant when tracking out bugs. Classic example is ref and value type the behave differently when passed over as method parameters.Collin Jasnoch wrote:
This is not true. In the above example the poorly named explicitly declared 'c' will lead to much more confusion than the implicit definition of the clearly named variable.
I do think it's true, imagine:
var c = GetActiveCustomerCount();
That's when it gets even messier,
varadds to the already confusing code, so again my point is, use it only when it makes sense.Collin Jasnoch wrote:
And to it I have one word.
Adapt.I agree, that's what I've done when I started using lambda expressions instead of anonymous delegates. What I don't agree is with this moves I specially see in young developers (and it bothers me a lot) to use
vareverywhere, because it's easier not to have to think about your types. To me yes, it is a bad practice, it encourages lazy thinking and that is never good. Like once a reprimanded one member of my team for usingvaron theforeachof a dictionary. I asked him why and he said: "It's because I don't know what's the type the collection holds". Ifvardidn't exist, he would have been forced to research it and understand whatKeyValuePairis.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
