11–20 of 214 posts
Is type-sensitive code totally acceptable now? I do use it at times but generally try to avoid it.
C# as standard uses camelCase for internal variables and UpperCamelCase for public variables, properties and methods. https://docs.microsoft.com/en-us/dotnet/standard/design-guid...
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…
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))
};Is type-sensitive code totally acceptable now? I do use it at times but generally try to avoid it.
Unfortunately, real-life use scenarios are verbose and involved and require a lot of background context that detracts from just demonstrating the syntax. This is just demonstrating the syntax. Standard patterns of software design still apply.
Pattern matching is so much better in F#. C# gets more and bloated to the point of paralysis. It's not yet there but I;m sure it will at some point.
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?
Such a beautiful, elegant language. Simple to grasp and lets the compiler handle all that legitimate complexity. Wish more language designers would respect code authors like these designers do.
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…
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)) };
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));
}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!
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)) };
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)); }
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…
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)) };
[0] Roslyn Analyzers: https://docs.microsoft.com/en-us/visualstudio/code-quality/r...
Is type-sensitive code totally acceptable now? I do use it at times but generally try to avoid it.