Category Archives for "Master C#"

In Parameters in C# 7.2 – Productive C#

Learn how to use in parameters introduced in C# 7.2.

If you liked the post, don't forget to share it and subscribe to the newsletter using the form below the post!

Do you want more? Learn about the Productive C# Membership here.

Transcript Of The Video

In this video I am going to talk about the in parameters feature introduced in C# 7.2. 

C# 7.2 added some features that allows to work more efficiently with value types and this is one of those features. I have a console application configure to use the C# 7.2 language and let's have a look at the code that we have and how we can use the in parameters to make the code better.

I have a public struct spaceship that has a name, coordinates and a width and a height. I have a method that takes two spaceships and return a boolean if the two spaceships collide. Then I have a program that create two instances for SpaceShip, the Millennium Falcon and the Enterprise and then I run the collide method 100 millions times and I measure how long does it takes.

Let's try to run it and see what is the result... it's building the solution... now is running and it takes about 2.54 seconds to run. Ok. Perfect. When we call the collide methods, what actually happens is that these two parameters are copied by value. By default C#  copy by value value types passed to methods. We all know the in C# there is the ref keyword that can be added to the parameters like this so that instead of passing the parameter by value, you pass it by reference. You need to specify ref when you actually call the method. If I run the code again, you see thta now the performance is a lot better. It is 1.39 seconds. It's basically twice as fast as before. This is something you were always able to do since the beginning of C#.

What C# 7.2 adds is basically the ability to use in as a keyword instead of ref and it means that you still pass the value type by reference but also there is an additional value the is delivering that is it's not possible to change the parameters that actually passed internally. If I do for example, spaceship1.X = 10, you see that the compiler say you cannot assign to a member of variable 'in' SpaceShip because it is a readonly variable. So basically using the in keyword is like using ref readonly. If you use ref there is nothing that garantees the method to actually change the parameters while using the in feature you can have this additional validation from the compiler. If I run this code, you see that he performance is similar to using ref because we are still passing the parameters by reference.

The additional advantage of using in is that you don't need to use in when you actually call the method. You only use in when you actually define the method itself. This is a very small feature but it is quite handy when you deal with value types. It improve performances and at the same time ensure same validation especially when the methods are readonly and don't really need to change the values of the parameters.

The other important thing I want to mention is to always pay attention to measure performance because it is not guarantee that the performance is necessarely better. I believe honestly that the in parameters feature is not only about performance but it is mainly about enforsing the readonly validation. This is one of the biggest value of the in parameter.

The reason why it's called in is because it is complementary to out. This is it, thank you very much for watching.

C# 7.X features

C# 7.X and Beyond – A sneak peek at the future of C#

Have a quick sneak peek at the future of C#.

Do you know all the features available in the current latest release of C# 7?
Do you know all the potential features who might make it into C# 7.3, C# 8 and beyond?

At the .NET Cambridge community, I introduced all the C# 7 features and quickly introduced all the potentially upcoming features in the future versions of the language.

Here I share all the slides I used during my presentation.

C# 7.0 up to C# 7.2 introduced the following features:

  • Inline Out Variable
  • Tuples
  • Pattern Matching in Is Expression
  • Pattern Matching in Switch Statement
  • Local Functions
  • Throw Expressions
  • Binary Literals and Digit Separators
  • Expression bodied members
  • ValueTask<T>
  • Ref returns and locals
  • Async Main
  • Default expressions
  • In Parameters
  • Ref readonly
  • Readonly struct
  • Ref struct
  • Private Protected access modifier
  • Non-Trailing named arguments

What's baking for the future of C#? 

  • Ref local assignment expression
  • Ref this for extension methods
  • by value vs `in` overload tiebreaker
  • Attributes on auto-implemented properties
  • New generic constraints
  • Operators == and != for Tuples
  • IEnumerable<T> in params
  • Target typed stackalloc initializers
  • Utf8 string literal
  • Nullable References
  • Records
  • Slicing with Ranges
  • Native Number Types
  • Fixed sized buffers
  • Negation of if/while condition
  • Extension everything
  • Async Enumerable and Async Dispose
  • Query foreach
  • Null-conditional await
  • Null-coalescing assignments
  • Default implementation in interfaces
  • Dictionary literals
  • Constant patterns
  • is not pattern?
  • Methods in Enums
  • Implicitly scoped using statement

Enjoy the presentation and please share this blog post on the futrue of C# with your colleagues and friends!

Don't forget that C# is developed in the open.

You can influence the direction of the language by expressing your opinion on the official GitHub project.

PS: You can find a discount coupon for the Productive C# Membership at the end of the slide deck 🙂

In the future of C# there will be more love!

C# deserves more love! 

Help me  spread how good C# is and makes C# more lovable by subscribing to the Productive C# blog using the form below.

More importantly, help me beat JavaScript 🙂

lovecsharp
2 Try .NET

Learn C# Online with Try.NET

Learn how you can run C# code in the browser and learn C# without installing Visual Studio. This is perfect when you are getting started with C# to familiarise with the language and it's also great for experienced developers.

Video Link: https://www.youtube.com/watch?v=Ff7sXQele3s

Previous Posts

Transcript Of The Video

Hi, I am Andrea and welcome to Productive C#. In this video I want to talk about Try.NET. If you are completely new to C# and you want to give it a go without installing Visual Studio, that is the main IDE that you can use to actually write and build C# applications), you can do it now, by going to try.dot.net

If you go to this URL, you will find a very simplified editor and in this case there is a program written in C# that prints the first 20 Fibonacci numbers and you can actually run it by clicking the "Run" button and you will see an execution of the C# program. Let's play a bit with it and see what the experience is. Basically you have a complete C# editor here and you also have Intellisense. Let's say I  want to create a variable, then I want to do a foreach var numbers in number , Console.WriteLine and autocomplete number and you can do run. 

So, if you are new to C# and you want to actually play with the language without installing a full fledged editor, you can do that now using this website. Microsoft is actually working on this and actually quite good. 

Even if you are an experienced developer and you want to quickly run some C# for experimentation or if you don't have a machine with Visual Studio and you don't have time to actually install it, you can just go to this website  and immediately run some C#. Pretty much all the .NET framework libraries are referenced automatically for you and you can actually start playing with it. Very very useful tool. 

In addition to that, I want to show you that Microsoft is currently rolling it out to their documentation site. So, if you go to docs.microsoft.com, that is the main website for all the documentation, you can go for example to the C# QuickStart Guide , click on that and let's say I go to Hello World, let's click "Run your first C# program". What you can see here, on the right, you find a .NET editor that actually allows you to write C# directly in the browser and that's basically powered by the same engine that I showed you before in the other website. You can run it and get the results.  So you basically have a kind of interactive way of learning C# and this is definitely a recommended way to learn C# if you are completely new to the language. Go to this website, play a bit with this tutorial and you can get good at C# without even installing Visual Studio. 

Of course, if you are serious about programming in C# and I am sure you are, you absolutely have to install Visual Studio because allows you to build any kind of applications and it's an incredible tool. But remember that you have this website available for you if you need to learn C# or you actually want to play with it very quickly without waiting to install a complete IDE. Thanks you very much for watching.

private protected

Access Modifiers in C# and Private Protected

Learn about the new private protected access modifier in C# 7.2 and how it relates to all the other access modifiers.

Video Link: https://www.youtube.com/watch?v=KTk_XNQMPr4

Transcript Of The Video

In this video I want to talk about the private protected member access modifier that has been introduced in C# 7.2. In order to do so, I'd like to have a quick look at all the other access modifiers to better understand how the new modifier works. I have a solution in Visual Studio with two projects: one console application and one library that is actually referenced by the console application. The first modifier we are all familiar with is Public. When I declare a member as Public, means that everyone can access it, inside the assembly or outside. If you make a member Private, you can't change it outside the context of the class. The next access modifier is Protected. Now all the types that derive from Shape are able to access the member. However, you are not able to create an instance of a shape and change the member. Only the classes themselves are able to change the member. The other modifier is Internal. This means that this member can be accessed everywhere inside the assembly where it belongs. However, the member is inaccessible outside the assembly boundary. The next level is Protected Internal. It's the combination of the previous two using OR. It is Protected or Internal. The member can be accessed everywhere inside the assembly where is defined and also can be accessed in all derived types regardless in which assembly they lives. In C# 7.2 a new modifier has been added and it is called Private Protected. It gives access to a particular member only to derived types inside the assembly where is defined. Everywhere else is inaccessible. It is the combination of Protected and Internal. There was no way to do this before.  This is a new modifier that gives you an additional level of power in defining how you want to encapsulate your members. This access modifier was already available in the CLR so no changes were required in the CLR to implement this feature. It was never been implemented in C# mostly because it was quite difficult to name. It can creates a bit of a confusion. The best way to see it is: Private Protected is Protected And Internal while Protected Internal is Protected Or Internal.

Previous Posts

Empathy map

The Future of Engineering at Redgate — A futurespective empathy map approach

Few days ago, I come across to a bunch of tests that were using the null conditional operator in the wrong way and I think it is worth sharing it.

Have a look at this code and how I fixed it.

Dangerous use of null C# conditional operator in test

What's the problem with the original code?

When result is null, the test pass even if clearly shouldn't!

The reason is because of the "short-circuiting" behaviour.

When result is null, then the rest of the chain’s execution stops! The test then pass because the method ends and by default a test without assertions is a pass.

You can learn more about "short-circuiting"  with null conditional operators here

How did I fix it?

In this particular case I have just removed the null conditional operator and performed a simple comparison using equality instead of relying on calling ToString. 

So...

Be careful when using null conditional operators in assertions and remember about "short-circuiting".



Christmas Holidays and Automatic Code Formatting

How often do you talk about code formatting during code reviews?

Probably too often...

Have you considered to define rules for your team to automate code formatting?

I am sure you did.

You probably came to the conclusion that it is going to take too much time to  find an agreement between all members of your team. You are also aware that doing a massive clean up of your legacy code base is likely going to touch all the files inside your solution and will cause crazy and complicated merge conflicts to resolve. It's just too much pain to even think about it, isn't it?

I attempted this few times in past projects unsuccessfully... 

So let me explain the process I decided to follow this time...

It turns out that the week between Christmas and the New Year is a perfect time for cleaning 🙂

There are usually very few pull requests left open and most of your colleagues are out of the office.

For the first time in my career, I finally managed to complete a full clean-up of the code base I am currently working on (Redgate ReadyRoll) and put an end to any discussions about code formatting. More importantly, we can now clean-up any code with a single keyboard shortcut. 

This is awesome and a massive time saver for the team!

Andrea, this is cool, but how did you do it?
Who approved your changes if nobody was in the office?

Few weeks before Christmas, I ran a full R# clean-up of our solution and created a pull request for it. 

Full Cleanup to agree on code formatting rules

As you can read from the text of the pull request, the main goal was to identify formatting options we didn't like and try to come up with a list of all the changes we wanted to make.

The entire team agreed that consistency is more important than achieving 100% agreement.

I was pleased to see that we managed to get an acceptable level of agreement fairly quickly.

The main point of discussions were:

Finally, during Christmas I made the changes...

Pull Requests to implement Code Formatting rules

Overall it took me about 3 days of work to make all the changes.

Yes, it takes a bit of patience but I believe it's worth.

My recommendation would be to starting using code clean-up tools immediately when you start a new project so that you can avoid this pain in the future.

If you are not in this position, you now know what to do next Christmas 🙂

You can learn more about code cleanup with R# at the following address:
Code Style and Cleanup

Happy formatting!

1 Dangerous use of null C# conditional operator in test

Be careful in using the C# null conditional operators in tests

Few days ago, I come across to a bunch of tests that were using the null conditional operator in the wrong way and I think it is worth sharing it.

Have a look at this code and how I fixed it.

Dangerous use of null C# conditional operator in test

What's the problem with the original code?

When result is null, the test pass even if clearly shouldn't!

The reason is because of the "short-circuiting" behaviour.

When result is null, then the rest of the chain’s execution stops! The test then pass because the method ends and by default a test without assertions is a pass.

You can learn more about "short-circuiting"  with null conditional operators here

How did I fix it?

In this particular case I have just removed the null conditional operator and performed a simple comparison using equality instead of relying on calling ToString. 

So...

Be careful when using null conditional operators in assertions and remember about "short-circuiting".



1 2 3 13
>