So let us see how we can improve all of these in our code!<\/p>\n
The Proper Way to Do a Null Checks<\/h2>\n
We perform null-checks quite often in our code, to guard against the dreaded Do you know what the problem is with this approach? The Here is how we can perform a null-check with the new The Beginning with C# 9, you can use a negation pattern to do a null-check:<\/p>\n The same applies to this type of check, it will only evaluate to Nesting is when we have code between two curly braces. One simple example of nesting is the body of a method. We see that this is a natural occurrence in the language. However, we can face some problems when we have multiple levels of nesting.<\/p>\n Why is code nesting a problem? Usually, one or two levels of nesting are not problematic. But, the more levels of nesting we have, the harder it becomes to read the code, and bugs will become harder to catch.<\/p>\n Luckily, we can fix this easily. We are going to give you a few C# tips for reducing nesting in our code.<\/p>\n Let us look at an example where we have an if-else statement. Inside the if-statement we are returning some value:<\/p>\n In cases like these, the entire else statement can be removed, and we are effectively reducing the nesting level for that part of the code:<\/p>\n Sometimes, we need to make sure that a couple of conditions are met before we perform some operation. This usually results in multiple levels of nesting and code that is harder to read:<\/p>\n We can fix this by applying the \u201cearly return\u201d principle:<\/p>\n The early return principle states that we should return from a method as soon as possible. In our case, we first check if the product is We can optimize this further by joining the two if-statements into a single one:<\/p>\n Using statements in the past always assumed an additional level of nesting in our code that was not necessary:<\/p>\n Starting with C# 8, we can remove the curly braces from the It is important to note that when using this feature, the C# 9 introduced a set of new logical patterns that we can use to improve the readability of our logical expressions. Let us see how we can use them in our code!<\/p>\n We are going to write a function to check if a specified character is a letter:<\/p>\n This is the typical approach we would take, although it is a little cumbersome to write because we have to repeat the character parameter for every check.<\/p>\n With the new This new version is much more readable because it almost reads like a sentence. We also do not need to specify the character parameter more than once.<\/p>\n We often encounter a situation in our code where we need to return a Although this approach is mostly fine, we have to ask ourselves if we even need an if-statement in the first place. Since we already have a logical expression inside the if-statement, we can simplify the method by simply returning the value of that logical expression:<\/p>\n We have to write far less code to achieve the same result, which is always desirable.<\/p>\n We can further simplify the previous method by using an expression body:<\/p>\n If we notice that the boolean expression is becoming complex, we can split it into a couple of meaningfully named local variables.<\/p>\n Switch statements can be very useful when we want to evaluate some object, and based on the set of possible values return a different result.<\/p>\n Let\u2019s write a switch statement to check if the current day is a weekend day or not:<\/p>\n As we can see, we have to write a lot of code. We can compact this further by joining all of the That\u2019s a little better, wouldn\u2019t you agree? But we can do even better than this!<\/p>\n Beginning with C# 8, switch expressions were introduced to help us reduce the amount of code we have to write even more.<\/p>\n Let\u2019s transform the previous switch statement into a switch expression:<\/p>\n As we can see, it\u2019s much more concise and readable than before. So are we finished now? Almost.<\/p>\n Starting with C# 9, we can also use logical patterns in our switch expressions. The One last optimization we can introduce is to use the negation logical pattern Exception handling is a very important aspect of our code. We can often see one pattern repeated through the codebase is catching an exception, handling it locally, and then rethrowing it to a higher-level component.<\/p>\n The rethrowing step is where we can easily make a mistake:<\/p>\n Do you know what is the problem when we rethrow an exception like this?<\/p>\n The stack trace of the exception gets rewritten to the line of code where we explicitly rethrow it. This means that we lose all of the valuable information about what caused the exception in the first place. This can make debugging the code very hard.<\/p>\n However, we can fix this very easily:<\/p>\n When we do it like this, the exception is rethrown while preserving the original stack trace. We are now saving all of that valuable information about what caused the exception in the first place. It will be much easier for us to debug the code, and figure out what the problem is.<\/p>\n Do you have a situation in your code where you need to handle a specific exception multiple times? We often encounter a case like this, where we have to perform different exception handling logic based on some condition.<\/p>\n Let us say we want to handle an Although this works, it\u2019s not the cleanest approach. There is a much better solution that you might not know about.<\/p>\n Here is how we can elegantly catch the same exception based on a certain condition:<\/p>\n This approach is much cleaner and easier to extend when we need to add more conditions.<\/p>\n Beginning with C# version 9, the long-awaited Here is how we can define a simple record:<\/p>\n When defined like this, it is called a “Positional record”. We can also define the same record like this:<\/p>\n The new Positional records are a great candidate for Data Transfer Objects (DTOs) because they are immutable and very simple to define. When replacing classes with records for DTOs, you will find that the amount of code in your codebase will drastically reduce.<\/p>\n Often, we have methods that return a collection. We perform some validation beforehand, then populate the collection and return it. However, what should we return in case the preconditions are not met?<\/p>\n One option is to return This is generally a bad practice because we now force the calling code to check the A better approach would be to just return an empty collection:<\/p>\n Although this approach is fine, we can achieve the same result with a cleaner approach:<\/p>\n Using Let\u2019s create a simple What is preventing us from adding or removing blogs from the With this approach nothing. Our Clearly, we can\u2019t allow this much freedom to our consumers. We will enforce encapsulation by creating a private field for storing the blogs. Let\u2019s modify the This implementation is a little better, but we still have the same issue as before. Nothing is preventing our consumers from manipulating the To completely close the Great, we have almost completely encapsulated the The previous code no longer works:<\/p>\n This is because the However, nothing is preventing our consumers from doing this:<\/p>\nNullReferenceException<\/code>. The most common way we do this is:<\/p>\nvar product = GetProduct();\r\n\r\nif (product == null)\r\n{\r\n \/\/ Do something if the object is null.\r\n}<\/pre>\n==<\/code> operator can be overridden and there is no strict guarantee that comparing an object with null<\/code> will produce the result that we expect. Luckily, there is a new operator that is introduced in C# version 7, the is<\/code> operator.<\/p>\nis<\/code> operator:<\/p>\nvar product = GetProduct();\r\n\r\nif (product is null)\r\n{\r\n \/\/ Do something if the object is null.\r\n}<\/pre>\nis<\/code> operator will always evaluate to true<\/code> if the specified object instance is null<\/code>. It is also a cleaner way of writing null-checks because it reads like a sentence.<\/p>\nvar product = GetProduct();\r\n\r\nif (product is not null)\r\n{\r\n \/\/ Do something if the object is not null.\r\n}<\/pre>\ntrue<\/code> if the specified object is not null<\/code>. It can not be overridden.<\/p>\nC# Tips to Reduce Nesting in Your Code<\/h2>\n
Product PurchaseProduct(int id)\r\n{\r\n var product = GetProduct(id);\r\n\r\n if (product.Quantity > 0)\r\n {\r\n product.Quantity--;\r\n\r\n return product;\r\n }\r\n else\r\n {\r\n SendOutOfStockNotification(product);\r\n\r\n return null;\r\n }\r\n}<\/pre>\nProduct PurchaseProduct(int id)\r\n{\r\n var product = GetProduct(id);\r\n\r\n if (product.Quantity > 0)\r\n {\r\n product.Quantity--;\r\n\r\n return product;\r\n }\r\n\r\n SendOutOfStockNotification(product);\r\n\r\n return null;\r\n}<\/pre>\nbool IsProductInStock(int id)\r\n{\r\n var product = GetProduct(id);\r\n\r\n if (product is not null)\r\n {\r\n if (product.Quantity > 0)\r\n {\r\n return true;\r\n }\r\n }\r\n\r\n return false;\r\n}<\/pre>\nbool IsProductInStock(int id)\r\n{\r\n var product = GetProduct(id);\r\n\r\n if (product is null)\r\n {\r\n return false;\r\n }\r\n\r\n if (product.Quantity <= 0)\r\n {\r\n return false;\r\n }\r\n\r\n return true;\r\n}<\/pre>\nnull<\/code>, and return false<\/code> if it is. Then we check if the quantity is less than or equal to zero, and return false<\/code> if it is. Otherwise, the product is not null<\/code> and the quantity is greater than zero, so we return\u00a0true<\/code>.<\/p>\nbool IsProductInStock(int id)\r\n{\r\n var product = GetProduct(id);\r\n\r\n if (product is null || product.Quantity <= 0)\r\n {\r\n return false;\r\n }\r\n\r\n return true;\r\n}<\/pre>\nIntroducing Using Declarations<\/h3>\n
using (var streamReader = new StreamReader(\"...\"))\r\n{\r\n string content = streamReader.ReadToEnd();\r\n}\r\n<\/pre>\nusing<\/code> statements in our code:<\/p>\nusing var streamReader = new StreamReader(\"...\");\r\n\r\nstring content = streamReader.ReadToEnd();\r\n<\/pre>\n
using<\/code> statement has block-level scope.<\/p>\nImprove Logical Expression Readability<\/h2>\n
bool IsLetter(char ch) => (ch >= 'a' && ch <= 'z') || (ch >= 'A' && ch <= 'Z');\r\n<\/pre>\n
and<\/code> and or<\/code> logical pattern combinators, we can rewrite the previous function:<\/p>\nbool IsLetter(char ch) => ch is (>= 'a' and <= 'z') or (>= 'A' and <= 'Z');\r\n<\/pre>\n
Remove If-Else Statements for Setting Boolean Values<\/h2>\n
bool<\/code> value from a function:<\/p>\nbool IsInStock(Product product)\r\n{\r\n if (product.Quantity > 0)\r\n {\r\n return true;\r\n }\r\n else\r\n {\r\n return false;\r\n }\r\n}<\/pre>\nbool IsInStock(Product product)\r\n{\r\n return product.Quantity > 0;\r\n}<\/pre>\nbool IsInStock(Product product) => product.Quantity > 0;\r\n<\/pre>\n
How to Simplify Switch Statements<\/h2>\n
switch (DateTime.Now.DayOfWeek)\r\n{\r\n case DayOfWeek.Monday:\r\n return \"Not Weekend\";\r\n case DayOfWeek.Tuesday:\r\n return \"Not Weekend\";\r\n case DayOfWeek.Wednesday:\r\n return \"Not Weekend\";\r\n case DayOfWeek.Thursday:\r\n return \"Not Weekend\";\r\n case DayOfWeek.Friday:\r\n return \"Not Weekend\";\r\n case DayOfWeek.Saturday:\r\n return \"Weekend\";\r\n case DayOfWeek.Sunday:\r\n return \"Weekend\";\r\n default:\r\n throw new ArgumentOutOfRangeException();\r\n}<\/pre>\ncase<\/code> statements that return the same result:<\/p>\nswitch (DateTime.Now.DayOfWeek)\r\n{\r\n case DayOfWeek.Monday:\r\n case DayOfWeek.Tuesday:\r\n case DayOfWeek.Wednesday:\r\n case DayOfWeek.Thursday:\r\n case DayOfWeek.Friday:\r\n return \"Not Weekend\";\r\n case DayOfWeek.Saturday:\r\n case DayOfWeek.Sunday:\r\n return \"Weekend\";\r\n default:\r\n throw new ArgumentOutOfRangeException();\r\n}<\/pre>\nDateTime.Now.DayOfWeek switch\r\n{\r\n DayOfWeek.Monday => \"Not Weekend\",\r\n DayOfWeek.Tuesday => \"Not Weekend\",\r\n DayOfWeek.Wednesday => \"Not Weekend\",\r\n DayOfWeek.Thursday => \"Not Weekend\",\r\n DayOfWeek.Friday => \"Not Weekend\",\r\n DayOfWeek.Saturday => \"Weekend\",\r\n DayOfWeek.Sunday => \"Weekend\",\r\n _ => throw new ArgumentOutOfRangeException()\r\n}\r\n<\/pre>\nor<\/code> logical pattern fits nicely with what we are trying to achieve:<\/p>\nDateTime.Now.DayOfWeek switch\r\n{\r\n DayOfWeek.Monday or DayOfWeek.Tuesday or DayOfWeek.Wednesday or DayOfWeek.Thursday or DayOfWeek.Friday => \"Not Weekend\",\r\n DayOfWeek.Saturday or DayOfWeek.Sunday => \"Weekend\",\r\n _ => throw new ArgumentOutOfRangeException()\r\n}<\/pre>\nnot<\/code>:<\/p>\nDateTime.Now.DayOfWeek switch\r\n{\r\n not (DayOfWeek.Saturday or DayOfWeek.Sunday) => \"Not Weekend\",\r\n DayOfWeek.Saturday or DayOfWeek.Sunday => \"Weekend\",\r\n _ => throw new ArgumentOutOfRangeException()\r\n}<\/pre>\nThe Proper Way to Rethrow Exceptions<\/h2>\n
try\r\n{\r\n await GetBlogsFromApi();\r\n}\r\ncatch (HttpRequestException e)\r\n{\r\n throw e;\r\n}<\/pre>\ntry\r\n{\r\n await GetBlogsFromApi();\r\n}\r\ncatch (HttpRequestException e)\r\n{\r\n throw;\r\n}\r\n<\/pre>\nHow to Filter Exceptions<\/h2>\n
HttpRequestException<\/code> in one way when the StatusCode<\/code> is 400<\/code> (Bad Request), and in another way when the StatusCode<\/code> is 404<\/code> (Not Found). The naive approach would be to catch the exception and then write an if-statement to check a condition:<\/p>\ntry\r\n{\r\n await GetBlogsFromApi();\r\n}\r\ncatch (HttpRequestException e)\r\n{\r\n if (e.StatusCode == HttpStatusCode.BadRequest)\r\n {\r\n HandleBadRequest(e);\r\n }\r\n else if (e.StatusCode == HttpStatusCode.NotFound)\r\n {\r\n HandleNotFound(e);\r\n }\r\n}\r\n<\/pre>\ntry\r\n{\r\n await GetBlogsFromApi();\r\n}\r\ncatch (HttpRequestException e) when (e.StatusCode == HttpStatusCode.BadRequest)\r\n{\r\n HandleBadRequest(e);\r\n}\r\ncatch (HttpRequestException e) when (e.StatusCode == HttpStatusCode.NotFound)\r\n{\r\n HandleNotFound(e);\r\n}<\/pre>\nWhy You Should Use Records as Data Transfer Objects<\/h2>\n
record<\/code> types feature was introduced. Records are reference types, just like classes. However, records have an amazing feature that classes don\u2019t – they are immutable by default.<\/p>\npublic record ProductDto(string Id, string Name, string Category, decimal Price);\r\n<\/pre>\n
public record ProductDto\r\n{\r\n public string Id { get; init; }\r\n\r\n public string Name { get; init; }\r\n\r\n public string Category { get; init; }\r\n\r\n public decimal Price { get; init; }\r\n}\r\n<\/pre>\ninit<\/code> setter allows the value of the property to be set only once when the object instance is created. After that, it can no longer be modified, thus ensuring immutability.<\/p>\nThe Proper Way to Return Empty Collections<\/h2>\n
null<\/code> values:<\/p>\nIEnumerable<Product> GetProductsByCategory(string category)\r\n{\r\n if (string.IsNullOrWhiteSpace(category))\r\n {\r\n return null;\r\n }\r\n\r\n var products = _dbContext.Products.Where(p => p.Category == category).ToList();\r\n\r\n return products;\r\n}<\/pre>\nnull<\/code> result.<\/p>\nIEnumerable<Product> GetProductsByCategory(string category)\r\n{\r\n if (string.IsNullOrWhiteSpace(category))\r\n {\r\n return new List<Product>();\r\n }\r\n\r\n var products = _dbContext.Products.Where(p => p.Category == category).ToList();\r\n\r\n return products;\r\n}\r\n<\/pre>\nIEnumerable<Product> GetProductsByCategory(string category)\r\n{\r\n if (string.IsNullOrWhiteSpace(category))\r\n {\r\n return Enumerable.Empty<Product>();\r\n }\r\n\r\n var products = _dbContext.Products.Where(p => p.Category == category).ToList();\r\n\r\n return products;\r\n}\r\n<\/pre>\nArray.Empty<\/code> and Enumerable.Empty<\/code> is the preferred way for returning an empty collection from a method. This is because every time you instantiate an empty array or list, it is stored in memory. This increases the pressure on the Garbage Collector. However, when we use Array.Empty<\/code> or Enumerable.Empty<\/code> there is only one instance of an empty collection that is created, which is reusable. This will reduce the memory consumption of our application.<\/p>\nC# Tips to Make Your Code Robust With Readonly Collections<\/h2>\n
Writer<\/code> class, with a collection of blogs:<\/p>\npublic class Writer\r\n{\r\n public Writer(string name, List<Blog> blogs)\r\n {\r\n Name = name;\r\n Blogs = blogs;\r\n }\r\n\r\n public string Name { get; set; }\r\n\r\n public List<Blog> Blogs { get; set; }\r\n}<\/pre>\nBlogs<\/code> collection?<\/p>\nWriter<\/code> class has no encapsulation. Someone could manipulate a Writer<\/code> instance as they wish:<\/p>\nvar writer = new Writer(\u201cCode Maze\u201d, new List<Blog>());\r\n\r\nwriter.Blogs.Add(blog1);\r\n\r\nwriter.Blogs.Remove(blog2);\r\n<\/pre>\n
Writer<\/code> class:<\/p>\npublic class Writer\r\n{\r\n private List<Blog> _blogs = new List<Blog>();\r\n\r\n public Writer(string name, List<Blog> blogs)\r\n {\r\n Name = name;\r\n _blogs = blogs;\r\n }\r\n\r\n public string Name { get; set; }\r\n\r\n public List<Blog> Blogs => _blogs;\r\n}\r\n<\/pre>\nBlogs<\/code> collection.<\/p>\nBlogs<\/code> collection from modification we can use one of the read-only collection interfaces. We can use either IReadonlyCollection<\/code> or IReadonlyList<\/code>. Let\u2019s go with IReadonlyCollection<\/code> and modify the Writer<\/code> class:<\/p>\npublic class Writer\r\n{\r\n private List<Blog> _blogs = new List<Blog>();\r\n\r\n public Writer(string name, List<Blog> blogs)\r\n {\r\n Name = name;\r\n _blogs = blogs;\r\n }\r\n\r\n public string Name { get; set; }\r\n\r\n public IReadonlyCollection<Blog> Blogs => _blogs;\r\n}\r\n<\/pre>\nWriter<\/code> class.<\/p>\nvar writer = new Writer(\u201cCode Maze\u201d, new List<Blog>());\r\n\r\nwriter.Blogs.Add(blog1); \/\/ Compiler error.\r\n\r\nwriter.Blogs.Remove(blog2); \/\/ Compiler error.\r\n<\/pre>\n
IReadonlyCollection<\/code> interface doesn\u2019t contain methods for altering the collection.<\/p>\nvar writer = new Writer(\u201cCode Maze\u201d, new List<Blog>());\r\n\r\n(writer.Blogs as List<Blog>).Add(blog1);\r\n<\/pre>\n
![\"Benchmark](\"https:\/\/code-maze.com\/wp-content\/uploads\/2021\/07\/benchmark_results_final.png\")
<\/a><\/p>\n