The new holy war in C#:

Point p = new Point(5, 3);

vs.
var p = new Point(5, 3);

vs. (new)
Point p = new (5, 3);

and... FIGHT!!

"Most" of the time, I like being explicit.

Point p = new Point(5,3)

Mostly because I have far more production Java than C# and that's just what I'm used to.

I like var in LINQ or in a foreach.
Otherwise I am explicit.
Unless we have a team agreement you can do whatever you want.

Actually all three make good sense to me, depends from where you're going.
- first one is C++ like way
- second one makes more sense if your code is dynamically typed
- third one is interesting, wondering why we weren't doing that in other languages like C++ from the start (probably because of pointers and stuff)

I use var so all my variable names are aligned

Not c#, but i always use var in java

Ugh, 3rd one looks ugly.
I use var for everything created runtime except for more complicated datatypes (like lists of x, multidimensional arrays, dictionaries etc..)

Dictionary<byte, struct> xy = new Dictionary<byte, struct>();

Just feeels right instead of

var xy = new Dictionary<byte, struct>();

The second one gives me hardcore javascript like vietnam flashbacks

Ranting about the holy war eh? You should try HolyC. Its a superior language I promise you won't look back.

@holloway honestly it surprises me how much of a genius that dude was even when he went bonkers

@deadbender Terry A Davis was a genius. Sadly outnumbered by his own illness

First!!
Second maaaaaybeee...
Third hell no.. o.O

Okay let's just get this out of the way, the third is for braindead jellyfish.

The first is when the type name is short and makes sense.

The second is good for when you have templates and especially nested templates, long type names, or type names that are ugly (have typos, or are inaccurate and cannot be fixed because it's not your code)

I like to use var whenever the type is obvious, because writing it twice in the same line would be redundant.
var a = new Type();
var b = new ReallyLongNestedType<Because<WhyNot>>();

However if it is not explicitly stated already, I do not use var:
Type c = a;
Type c = Helper.GetC();

IMO var is a sin in a language like c# it reduces readability, maybe for some dynamically language. Third seems weird so I'd always go for the first one, best in terms of readability and your ide can easily autocomplete it for an easy write

I use var whenever I can!

vs

Don't use C#, use Rust.

😄

first one okay
second one i would use
third one... what is this monstrosity!
kill it with git reset --hard

I don't hate the new way of constructing an object but IMHO it is something nobody needed, I dare ask whose idea it was and why.

3 is confusing as fuck (at least at first). 2 is very JavaScript-ish.

I use var everywhere because resharper does that faint squiggly thing when you don't. That annoys me more than having to mouse over to see the type

Everyone knows the correct way of defining an object should be:

@highlight
|point|
point := 5@3

@highlight Pain

@M3m35terJ05h Shouldn't that be configurable? Enforcing one of a few possible (and valid) ways of doing something sounds very arrogant (and I've only heard good stuff about ReSharper).

@kamen It's probably configurable. But the rule at my work is do what the resharper defaults say. And the defaults say all sorts of things about style and ways of doing things.

Resharper is way overhyped imo. Every resharper feature I've heard people tout is in vanilla visual studio. The vanilla search everywhere isn't quite as fast or as good as resharper's but it's damn close. Not worth the performance overhead imo

@M3m35terJ05h
Why not using Rider ?

@Tounai I've never tried rider but I'm not really a fan of idea/android studio. I mean, I haven't found anything better for java and android but I still don't like them. So if that experience is anything to go by, I'd like to keep it away from my C#.

Props to jetbrains for making kotlin though.

@M3m35terJ05h yeah, Rider is mostly the same thing than IntelliJ

@highlight

qs :: Ord t => [t] -> [t]

qs [] = []

qs (x:xs) =

let s = qs [ a|a<-xs,a<=x ]; l = qs [ a|a<-xs,a>x ];

in s++[x]++l

Nice.

Could use better indentation/spacing though 🤔

@matt-jd I’ve never found var to confuse me partly because I use descriptive variable names

Id probably use option 3 to initialise fields and properties

@gruff what advantage would var have in a non dynamically typed language? It is much clearer to state what kind of variable you are working with

@matt-jd If the type is already obvious, the type declaration is just noise. Especially if it's a long type name

@matt-jd there is no advantage, you can use either and is down to personal preference or the existing project style. Me I like my words lined up much easier to read just thing of a dictionary declaration why write the type twice for no reason. If your dictionary is named sensibly and the fact we have much more ide feedback it is obvious what it is for. In the old days when you didn’t have they feedback it was useful and also why we had Hungarian notation which is generally considered an anti pattern now

@bittersweet haskell Syntax is so cryptic sometimes. But feels logical when you start to wrap your head about it.

It's the quicksort algorithm, isn't it?

@Wombat Yeah. It's a really bad quicksort 😆

@bittersweet why bad?

@Wombat It shows off the quicksort "methodology" in a very beautiful, concise and recursive way.

But Haskell is often geared more towards correct, safe code than efficient code, and that's what fucks us over here.

Often you want your variables to be immutable for safety, so that's what they are by default — so the above Haskell snippet, while elegant-looking, has horrible memory characteristics as it copies each part, instead of sorting in-place (mutating the list itself).

Sorting efficiently in Haskell is definitely possible, although it's easier to just call the standard built-in sort.

@bittersweet I understand. Thanks.

struct point * p = point_new(3,5);

Using var makes refactoring considerably easier, if you extract the functionality into an interface you don't need to go changing the returned variable declaration everywhere its used.