Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C# Pattern Matching

docs.microsoft.com

Post reply on HN
Print view View original

161–170 of 214 posts

Re: C# Pattern Matching

#161

Post by goto11 »

tigershark wrote: post #155
JamesBarney wrote: post #79

Earlier quoted context omitted.

Why are switches an anti-pattern? Switching a simple switch with a strategy pattern can make code far more complex and hard to understand. Switches are simple to code, simple to read, and easy to change.

Because it’s a switch statement, not an expression and a lot of people tend to use it for doing stuff more complex than a single line. Being it a statement there is nothing that forces you to return from each case and you may forget to use the break keyword mistakenly executing also the next case.

That is not the case in C# though, the break is required by the syntax.

Re: C# Pattern Matching

#162

Post by oaiey »

pbz wrote: post #123
eyegor wrote: post #93

Heads up for C# devs, you should switch all your code bases to use (x is null) and !(x is null) instead of ==. The is operator can't be overloaded, and always compiles to IL eq, whereas == can be overloaded in custom types. Of course it would also be nice if everything was moved to nullable reference types [0], but that's a non trivial amount of work. Note that most C#8 features can be enabled manually through the cs…

The new "something is not null" check in C#8 is "something is object/set"; for example: if (x is {})

Thanks. Just learned that object/tuple deconstruction works with is keyword as well (I mean makes sense). That makes argument checking so much less burden.

That also explains the switch in parameter checking from == null to is null for the default code analyzers/refactors/code hints.

Re: C# Pattern Matching

#163

Post by tablloyd »

to11mtm wrote: post #53
keithnz wrote: post #7

Earlier quoted context omitted.

as an aside, if you got Rider as part of your resharper subscription, try it out, it is basically a drop in replacement for visual studio but faster and with many many little quality of life improvements you never knew you needed :)

I started using Rider recently. It's faster yes, but seems to be a bit more memory hungry out of the gate than VS+Resharper. There is one HUGE thing I miss however - the Package Manager console. There's still a few things I have to do in there and thus have to switch back to VS.

Theres a nuget & terminal tab across the bottom bar which combined offer the same functionality as the nuget package manager console.

Re: C# Pattern Matching

#164

Post by oaiey »

Someone1234 wrote: post #43
aar0nsa3nz wrote: post #12

Earlier quoted context omitted.

With C# 8 you can also write it as: public static double ComputeArea(object shape) => shape switch { Square s => s.Side * s.Side, Circle c => c.Radius * c.Radius * Math.PI, Rectangle r => r.Height * r.Length _ => throw new ArgumentException( message: "shape is not recognized", paramName: nameof(shape)) };

Their long game is to slowly convert C# into F# without anyone realizing it. They're roughly half way through already.

Well C# 7.2 and 7.3 was moving it more to Rust. So that F# statement is a bit limited. They steal best ideas from everywhere and integrate it into the multi-paradigm language C# actually is.

In 2020 Pattern Matching is just a elementary feature everyone wants to have in all general purpose language. Like async/await. Or LINQ. That is just 101 for languages from now on.

Re: C# Pattern Matching

#165

Post by oaiey »

ape4 wrote: post #32
rkagerer wrote: post #6

Here's an example of the new syntactic sugar: public static double ComputeArea(object shape) { switch (shape) { case Square s: return s.Side * s.Side; case Circle c: return c.Radius * c.Radius * Math.PI; case Rectangle r: return r.Height * r.Length; default: throw new ArgumentException( message: "shape is not recognized", paramName: nameof(shape)); } } The when clause can be used to deal with special cases (e.g. to a…

Its cool but I would call it switch-by-class-type instead of pattern matching.

The example is very limited. C# has a dozen different matching method including tuples, object deconstruction, etc.

What i vaguely remember from my OCaml times, I think working with lists is the major gap they have. And that is non-trivial.

Re: C# Pattern Matching

#166

Post by [deleted] »

tlwest wrote: post #128

A new construct to save a line of code? Whatever happened to "every proposed language feature starts at -100 points, and must must become positive to even possibly be considered."? Given that probably 90% of code is written by C or D class programmers, every new feature adds cognitive load that makes it less likely that the median programmer (who almost certainly works offshore and who likely doesn't have enough Engl…

[deleted]

Re: C# Pattern Matching

#167

Post by oaiey »

throwawa66 wrote: post #14
czechdeveloper wrote: post #10

Earlier quoted context omitted.

Every single feature C# got in past years increased my productivity. I understand that it may cause issues to new learners, but overall, what of them do you consider bloat?

Wait till you get to work in some complex code bases and you'll understand why jamming all kinds of idioms into one language can become a disaster. It's a tool after all, if you know how to use it properly you don't paint yourself into a corner. However, too much flexibility can lead to many problems in larger teams. Good luck!

I agree with your sentiment. But writing good code is also avoiding playing "who knows more language features" between the coder and the reviewer.

I have seen a function which incorporated all new language features of that language version just because the dev could. A simple for loop would have made the same work. The reviewer failed here totally. Readability, Simplicity and consistency in the code base are a thing when reviewing.

Preventing this is a duty of the code reviewer and the team.

Re: C# Pattern Matching

#168

Post by BigolJones »

emodendroket wrote: post #99
flamtap wrote: post #86

Earlier quoted context omitted.

As a long-time ReSharper user, I’ve been meaning to give rider a close look for some time now. Unfortunately the last project I was on was heavy into WPF, and that was about the only box VS didn’t tick. Any tips, tricks, or pitfalls to avoid making the switch from VS to Rider?

I used VS for years before switching to Rider and honestly... just jump in, there's not much to know. If you've used ReSharper the features should seem pretty familiar.

I've actually considered it, but didn't really bring myself on doing it. How is it in general? Why do you prefer Rider?

Re: C# Pattern Matching

#169

Post by goto11 »

tlwest wrote: post #128

A new construct to save a line of code? Whatever happened to "every proposed language feature starts at -100 points, and must must become positive to even possibly be considered."? Given that probably 90% of code is written by C or D class programmers, every new feature adds cognitive load that makes it less likely that the median programmer (who almost certainly works offshore and who likely doesn't have enough Engl…

I feel for you! But people misusing language features is not really the fault of the language per se, it is more a failure of process, culture, tests and code reviews. I don't believe dumbing down a language leads to fewer bugs, it will just lead to more verbose bugs.

Re: C# Pattern Matching

#170

Post by martijn_himself »

This is neat, but also super confusing.

Is the ability to build class hierarchies not the ultimate reason to use C#, an Object-Oriented language? Which one of the two is idiomatic?

Great, now we have code littered with methods that take objects as parameters, so we have no clue what to actually pass to the method?

C# is a fantastic language but I feel increasingly lost with the barrage of new features added to it.

Post reply on HN