|
The vast majority of the time when looking at code I don't need to know what everything is - so without var I am presented with a load of noise and redundancy. If I want to know what something is and it isn't immediately obvious then I can hover over it and it tells me and for the purpose of that session I don't need to do that again.
I prefer to concentrate on the code rather than a load of type declaration noise. Admittedly it is a fine line - I don't use var everywhere - int i = 10 never becomes var i = 10, for example. And using var has become something I have adjusted to over time - at first I didn't like it, then I used it to remove redundancy var l = new List<string>() rather than List<string> l = new List<string>(). Now I use it in most places other than the aforementioned value type decls.
|
|
|
|
|
Other than what it was invented for (linq statements and anonymous types) an example of a good use of var is:
var foo = new SomeReallyLongTemplateDeclaration<bar<loo<koo,ka,choo>>>;
Here, you know what type foo is because it's type is readily apparent on the right-hand side of the statement.
Basically if you can readily determine the type from the right-hand side, then it's ok to use var . Otherwise, declare the type instead of using var .
So here, not so good:
var boo = SomeFunction();
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I only use var in cases where the type is either given elsewhere on the line of declaration
var frobables = new List<Frobable>();
var frobables2 = GetFrobables();
or is an intermediate value whose exact type is both nasty looking and whose explicit declaration doesn't add much value.
var temp = db.tableName
.Where(x => )
.Select(x => new
{
x.Property1,
x.Property2,
x.Property3,
x.Property4
});
I only use dynamic in one off code, eg single shot tools or data importers; like the fluffy languages it resembles, for anything that needs to be maintained the long term costs exceed the short term savings.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing 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
|
|
|
|
|
And you get far too many who just go "sod it, I can't be assed":
var x = 6;
foreach (var x in y.GetAll())
...
There is a good blog post on it here: The Use and Abuse of the C# “var” Keyword[^]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
idiots can write unreadable code in any language.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing 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
|
|
|
|
|
I use something called a "debugger". I always knew this was quite a maverick thing to do, but looking at the QA section I didn't realise just how maverick!
|
|
|
|
|
Interesting! I had forgotten some languages don't come with a debugger.
Good one!
|
|
|
|
|
rjmoses wrote: I had forgotten some languages don't come with a debugger.
... and those languages are hopelessly buggered at a result.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing 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
|
|
|
|
|
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.
|
|
|
|
|
You have to wonder how any of these people manage to do anything useful.
I was sent this this morning: Cyanide & Happiness: Millenials[^] (possibly NSFW, very little of C&A is)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
They don't! If I see one more "I'm ugly. I bet I won't even get one share." on FB, I'm going to unfriend myself.
|
|
|
|
|
You rebel you.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Depends on what you think is advanced
I use lambdas in C# all the time, but they've been around for over 10 years and now also turn up in other languages like JavaScript and, apparently, C++.
I use named tuples in C#, they were introduced two or three years ago, I think.
I've used pattern matching too.
A comment above this one mentions var and dynamic , I use var quite often and dynamic when I need it.
Basically, if it's in the language, why shouldn't I use it if I have need for it?
Personally, I don't find lambdas difficult to read at all.
In fact, a simple lambda can much better convey what you're doing than a function and be better maintainable.
For example:
myCollection.Where(x => x.IsActive).ToList();
myCollection.Where(IsActive).ToList();
private bool IsActive(Something x)
{
return x.IsActive;
} If the specs change, for example x.IsActive && x.Status == Status.Done , the first is an easy fix, the second would become IsActiveAndStateIsDone or some such, which gets harder to read every time.
In the case when the lambda is an Expression , like with Entity Framework, a function can't even be parsed and you have to use a lambda.
|
|
|
|
|
I'm always fighting reading a lambda. How you would express "x => x.IsActive" in words? Maybe this can help me
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
How would you express a function in words?
I'd say "x => x.IsActive" translates to "element is active".
So in case of a Where you'd get "where element is active" and in case of an OrderBy you'd get "order by element is active".
If you're looking for a more literal reading I'd say "x arrow x dot active", which is a lot easier than describing another function in detail.
I believe they're even called "arrow functions" in JavaScript.
|
|
|
|
|
Thank you for this. I think my confusion comes because I try to read it like mathematical functions e.g. "f: x->x^3"
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Try reading it as a trimmed down function (which now also allow for an arrow instead of curly braces).
myCollection.Where(bool IsActive(MyObject x) { return x.IsActive; });
myCollection.Where(bool IsActive(MyObject x) => return x.IsActive);
myCollection.Where(bool IsActive(MyObject x) => x.IsActive);
myCollection.Where(bool (MyObject x) => x.IsActive);
myCollection.Where((x) => x.IsActive);
myCollection.Where(x => x.IsActive); It is pretty close to the mathematical notation.
Unfortunately, it doesn't always work that well.
myCollection.Where((x, y) => x.IsActive && y > 10);
myCollection.Where((MyObject x, int y) => x.IsActive && y > 10);
myCollection.Where((collectionItem, index) => collectionItem.IsActive && index > 10); Hope this explains it even further.
|
|
|
|
|
Thank you very much, yes this helps I think
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
I am not sure it classifies as advanced but I have used unsafe code with casts and pointer arithmetic in C# a lot and am now switching to Span<t>, ref structs and SIMD instructions
|
|
|
|
|
I like to use 'throw' because a 'goto' that allows you to jump out of your current function to some unknown place is just so cool!
I, for one, like Roman Numerals.
|
|
|
|
|
I use C# var extensively (basically C++ auto) in protest of lack of proper typedef support in C#
Real programmers use butterflies
|
|
|
|
|
While I use lambdas in my C# code, I don't consider them especially 'advanced'. Most of the time I'm actually averse to using such features in any language, because they tend to encourage writing clever code rather than maintainable code. Since I have code in the field older than some of you folks reading this, maintainable wins.
I sporadically read news about new C++ features. None of them inspire me, as they whiff strongly of compiler weenies saying "look what I can do!". They are also overly-reliant on templates, and I find the syntax clumsy and verbose. I consider myself well-skilled in C++, and look for productivity-enhancing changes to the language. They're few and far between.
C# is somewhat a different story. Most of the features I read about seem designed to improve productivity and code quality, even when they are dismissed as 'syntactic sugar'.
Software Zen: delete this;
|
|
|
|
|
Writing clever code instead of maintainable---nahh, nobody ever does that.
My own criteria is that I want to be able to look at a section of code and "grok" it in a few seconds.
|
|
|
|
|
I find it interesting that many seem to think 'var' is such a bad thing. In C++, there's the auto keyword, and there's even the complementary keyword decltype which is particularly useful when you want the result type of an expression, or the return type of a function.
As I understand it, auto fills a similar role as var does in other language(s?), and there's actually a coding guideline promoted by Herb Sutter, no less, to 'aaa', or 'almost always [use] auto'. One of the main reasons is to help enforce type safety, which of course is outstandingly important in C++, probably more than in any other language. Another reason is maintainability: every use of auto probably doesn't need to be changed when you change some type in your code later.
That said, I often deliberately don't use auto, for one (or both) of two reasons: helping with autocompletion (the editor sometimes won't know what member variables and methods to suggest when dereferencing an auto variable), readability (provided the type name is easy enough to read, rather than a nested<type>::with<template_arguments>), and disambiguation (when I want the value to remain unchanged - i. e. const - rather than modifiable). I suspect the former will no longer be a reason when we finally manage to switch to a newer IDE version later this year, that's why I said two reasons
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I agree with Sutter about almost always using auto and will even do this:
const auto& item = ... ;
Another advantage of auto is that there are fewer affected-bys when you rename a type.
Another advantage is that auto reduces the number of line splits, which I like to avoid.
|
|
|
|