More about methods

Which you choose depends on what makes the most sense for the action.

Implementing functionality using methods

Let's start by implementing some functionality by using both static and instance methods:

Implementing functionality using operators

string s1 = "Hello "; 
string s2 = "World!";
string s3 = string.Concat(s1, s2); 
WriteLine(s3); // Hello World!

string s3 = s1 + s2;

A well-known biblical phrase is Go forth and multiply, meaning to procreate. Let's write code so that the * (multiply) symbol will allow two Person objects to procreate.

We do this by defining a static operator for the * symbol. The syntax is rather like a method, because in effect, an operator is a method, but uses a symbol instead of a method name, which makes the syntax more concise.

Implementing functionality using local functions

We will use a local function to implement a factorial calculation:

1. In Person.cs, add statements to define a Factorial function that uses a local function inside itself to calculate the result, as shown in the following code:

   // method with a local function
   public static int Factorial(int number)
   {
     if (number < 0)
     {
       throw new ArgumentException(
         $"{nameof(number)} cannot be less than zero.");
     }
     return localFactorial(number);
     int localFactorial(int localNumber) // local function
     {
       if (localNumber < 1) return 1;
       return localNumber * localFactorial(localNumber - 1);
     }
   }
   

2. In Program.cs, add a statement to call the Factorial function and write the return value to the console, as shown in the following code:

   WriteLine($"5! is {Person.Factorial(5)}");
   

3. Run the code and view the result, as shown in the following output:

   5! is 120
   

Raising and handling events

Methods are often described as actions that an object can perform, either on itself or on related objects. For example, List<T> can add an item to itself or clear itself, and File can create or delete a file in the filesystem.

Another way of thinking of events is that they provide a way of exchanging messages between two objects.

Calling methods using delegates

For example, imagine there is a method in the Person class that must have a string type passed as its only parameter, and it returns an int type, as shown in the following code:

public int MethodIWantToCall(string input)
{
  return input.Length; // it doesn't matter what the method does
}

I can call this method on an instance of Person named p1 like this:

int answer = p1.MethodIWantToCall("Frog");

Alternatively, I can define a delegate with a matching signature to call the method indirectly. Note that the names of the parameters do not have to match. Only the types of parameters and return values must match, as shown in the following code:

delegate int DelegateWithMatchingSignature(string s);

Now, I can create an instance of the delegate, point it at the method, and finally, call the delegate (which calls the method), as shown in the following code:

// create a delegate instance that points to the method
DelegateWithMatchingSignature d = new(p1.MethodIWantToCall);
// call the delegate, which calls the method
int answer2 = d("Frog");

You are probably thinking, "What's the point of that?" Well, it provides flexibility.

For example, we could use delegates to create a queue of methods that need to be called in order. Queuing actions that need to be performed is common in services to provide improved scalability.

Another example is to allow multiple actions to perform in parallel. Delegates have built-in support for asynchronous operations that run on a different thread, and that can provide improved responsiveness. You will learn how to do this in Chapter 12, Improving Performance and Scalability Using Multitasking.

Delegates and events are two of the most confusing features of C# and can take a few attempts to understand, so don't worry if you feel lost!

Defining and handling delegates

public delegate void EventHandler(
  object? sender, EventArgs e);
public delegate void EventHandler<TEventArgs>(
  object? sender, TEventArgs e);

Let's explore delegates and events:

Defining and handling events

When assigning a method to a delegate field, you should not use the simple assignment operator as we did in the preceding example.

Delegates are multicast, meaning that you can assign multiple delegates to a single delegate field. Instead of the = assignment, we could have used the += operator so we could add more methods to the same delegate field. When the delegate is called, all the assigned methods are called, although you have no control over the order in which they are called.

If the Shout delegate field was already referencing one or more methods, by assigning a method, it would replace all the others. With delegates that are used for events, we usually want to make sure that a programmer only ever uses either the += operator or the -= operator to assign and remove methods:

Making types safely reusable with generics

Working with non-generic types

System.Collections.Hashtable can be used to store multiple values each with a unique key that can later be used to quickly look up its value. Both the key and value can be any object because they are declared as System.Object. Although this provides flexibility when storing value types like integers, it is slow, and bugs are easier to introduce because no type checks are made when adding items.

Let's write some code:

1. In Program.cs, create an instance of the non-generic collection, System.Collections.Hashtable, and then add four items to it, as shown in the following code:

   // non-generic lookup collection
   System.Collections.Hashtable lookupObject = new();
   lookupObject.Add(key: 1, value: "Alpha");
   lookupObject.Add(key: 2, value: "Beta");
   lookupObject.Add(key: 3, value: "Gamma");
   lookupObject.Add(key: harry, value: "Delta");
   

2. Add statements to define a key with the value of 2 and use it to look up its value in the hash table, as shown in the following code:

   int key = 2; // lookup the value that has 2 as its key
   WriteLine(format: "Key {0} has value: {1}",
     arg0: key,
     arg1: lookupObject[key]);
   

3. Add statements to use the harry object to look up its value, as shown in the following code:

   // lookup the value that has harry as its key
   WriteLine(format: "Key {0} has value: {1}",
     arg0: harry,
     arg1: lookupObject[harry]);
   

4. Run the code and note that it works, as shown in the following output:

   Key 2 has value: Beta
   Key Packt.Shared.Person has value: Delta
   

Working with generic types

This provides flexibility, it is faster, and bugs are easier to avoid because type checks are made when adding items.

Let's write some code to solve the problem by using generics:

Implementing interfaces

If a type implements an interface, then it is making a promise to the rest of .NET that it supports specific functionality. This is why they are sometimes described as being contracts.

Common interfaces

Comparing objects when sorting

namespace System
{
  public interface IComparable
  {
    int CompareTo(object? obj);
  }
  public interface IComparable<in T>
  {
    int CompareTo(T? other);
  }
}

For example, the string type implements IComparable by returning -1 if the string is less than the string being compared to or 1 if it is greater. The int type implements IComparable by returning -1 if the int is less than the int being compared to or 1 if it is greater.

If a type implements one of the IComparable interfaces, then arrays and collections can sort it.

Comparing objects using a separate class

1. In the PacktLibrary project, add a new class file named PersonComparer.cs containing a class that implements the IComparer interface that will compare two people, that is, two Person instances. Implement it by comparing the length of their Name field, or if the names are the same length, then by comparing the names alphabetically, as shown in the following code:

   namespace Packt.Shared;
   public class PersonComparer : IComparer<Person>
   {
     public int Compare(Person? x, Person? y)
     {
       if (x is null || y is null)
       {
         return 0;
       }
       // Compare the Name lengths...
       int result = x.Name.Length.CompareTo(y.Name.Length);
       // ...if they are equal...
       if (result == 0)
       {
         // ...then compare by the Names...
         return x.Name.CompareTo(y.Name);
       }
       else // result will be -1 or 1
       {
         // ...otherwise compare by the lengths.
         return result; 
       }
     }
   }
   

2. In Program.cs, add statements to sort the array using this alternative implementation, as shown in the following code:

   WriteLine("Use PersonComparer's IComparer implementation to sort:"); 
   Array.Sort(people, new PersonComparer());
   foreach (Person p in people)
   {
     WriteLine($"  {p.Name}");
   }
   

3. Run the code and view the result, as shown in the following output:

   Use PersonComparer's IComparer implementation to sort:
     Adam
     Jenny
     Simon
     Richard
   

Implicit and explicit interface implementations

For example, both IGamePlayer and IKeyHolder might have a method called Lose with the same parameters because both a game and a key can be lost. In a type that must implement both interfaces, only one implementation of Lose can be the implicit method. If both interfaces can share the same implementation, that works, but if not then the other Lose method will have to be implemented differently and called explicitly, as shown in the following code:

public interface IGamePlayer
{
  void Lose();
}
public interface IKeyHolder
{
  void Lose();
}
public class Person : IGamePlayer, IKeyHolder
{
  public void Lose() // implicit implementation
  {
    // implement losing a key
  }
  void IGamePlayer.Lose() // explicit implementation
  {
    // implement losing a game
  }
}
// calling implicit and explicit implementations of Lose
Person p = new();
p.Lose(); // calls implicit implementation of losing a key
((IGamePlayer)p).Lose(); // calls explicit implementation of losing a game
IGamePlayer player = p as IGamePlayer;
player.Lose(); // calls explicit implementation of losing a game

Defining interfaces with default implementations

Managing memory with reference and value types

I have mentioned reference types a couple of times. Let's look at them in more detail.

For example, in a macOS terminal, I can enter the command ulimit -a to discover that the stack size is limited to 8,192 KB and that other memory is "unlimited." This limited amount of stack memory is why it is so easy to fill it up and get a "stack overflow."

Defining reference and value types

When you define a type using record struct or struct, you are defining a value type. This means that the memory for the object itself is allocated on the stack.

If a struct uses field types that are not of the struct type, then those fields will be stored on the heap, meaning the data for that object is stored in both the stack and the heap!

These are the most common struct types:

• Number System types: byte, sbyte, short, ushort, int, uint, long, ulong, float, double, and decimal
• Other System types: char, DateTime, and bool
• System.Drawing types: Color, Point, and Rectangle

Almost all the other types are class types, including string.

Apart from the difference in terms of where in memory the data for a type is stored, the other major difference is that you cannot inherit from a struct.

How reference and value types are stored in memory

int number1 = 49;
long number2 = 12;
System.Drawing.Point location = new(x: 4, y: 5);
Person kevin = new() { Name = "Kevin", 
  DateOfBirth = new(year: 1988, month: 9, day: 23) };
Person sally;

• The number1 variable is a value type (also known as struct) so it is allocated on the stack and it uses 4 bytes of memory since it is a 32-bit integer. Its value, 49, is stored directly in the variable.
• The number2 variable is also a value type so it is also allocated on the stack, and it uses 8 bytes since it is a 64-bit integer.
• The location variable is also a value type so it is allocated on the stack and it uses 8 bytes since it is made up of two 32-bit integers, x and y.
• The kevin variable is a reference type (also known as class) so 8 bytes for a 64-bit memory address (assuming a 64-bit operating system) is allocated on the stack and enough bytes on the heap to store an instance of a Person.
• The sally variable is a reference type so 8 bytes for a 64-bit memory address is allocated on the stack. It is currently null, meaning no memory has yet been allocated for it on the heap.

Figure 6.1: How value and reference types are allocated in the stack and heap

If a value type has a field that is a reference type, then that part of the value type is stored on the heap. Point is a value type that consists of two fields, both of which are themselves value types, so the entire object can be allocated on the stack. If the Point value type had a field that was a reference type, like string, then the string bytes would be stored on the heap.

Equality of types

When you check the equality of two value type variables, .NET literally compares the values of those two variables on the stack and returns true if they are equal, as shown in the following code:

int a = 3;
int b = 3;
WriteLine($"a == b: {(a == b)}"); // true

When you check the equality of two reference type variables, .NET compares the memory addresses of those two variables and returns true if they are equal, as shown in the following code:

Person a = new() { Name = "Kevin" };
Person b = new() { Name = "Kevin" };
WriteLine($"a == b: {(a == b)}"); // false

This is because they are not the same object. If both variables literally point to the same object on the heap, then they would be equal, as shown in the following code:

Person a = new() { Name = "Kevin" };
Person b = a;
WriteLine($"a == b: {(a == b)}"); // true

string a = "Kevin";
string b = "Kevin";
WriteLine($"a == b: {(a == b)}"); // true

You can do something similar with your classes to make the equality operators return true even if they are not the same object (same memory address on the heap) but instead if their fields have the same values, but that is beyond the scope of this book. Alternatively, use a record class because one of their benefits is that they implement this behavior for you.

Defining struct types

Working with record struct types

C# 10 introduced the ability to use the record keyword with struct types as well as with class types.

public record struct DisplacementVector(int X, int Y);

With this change, Microsoft recommends explicitly specifying class if you want to define a record class even though the class keyword is optional, as shown in the following code:

public record class ImmutableAnimal(string Name);

Releasing unmanaged resources

Garbage collection is an advanced topic, so for this topic, I will show some code examples, but you do not need to write the code yourself.

Each type can have a single finalizer that will be called by the .NET runtime when the resources need to be released. A finalizer has the same name as a constructor; that is, the type name, but it is prefixed with a tilde, ~.

public class Animal
{
  public Animal() // constructor
  {
    // allocate any unmanaged resources
  }
  ~Animal() // Finalizer aka destructor
  {
    // deallocate any unmanaged resources
  }
}

The preceding code example is the minimum you should do when working with unmanaged resources. But the problem with only providing a finalizer is that the .NET garbage collector requires two garbage collections to completely release the allocated resources for this type.

Though optional, it is recommended to also provide a method to allow a developer who uses your type to explicitly release resources so that the garbage collector can release managed parts of an unmanaged resource, such as a file, immediately and deterministically, and then release the managed memory part of the object in a single garbage collection instead of two rounds of garbage collection.

public class Animal : IDisposable
{
  public Animal()
  {
    // allocate unmanaged resource
  }
  ~Animal() // Finalizer
  {
    Dispose(false);
  }
  bool disposed = false; // have resources been released?
  public void Dispose()
  {
    Dispose(true);
    // tell garbage collector it does not need to call the finalizer
    GC.SuppressFinalize(this); 
  }
  protected virtual void Dispose(bool disposing)
  {
    if (disposed) return;
    // deallocate the *unmanaged* resource
    // ...
    if (disposing)
    {
      // deallocate any other *managed* resources
      // ...
    }
    disposed = true;
  }
}

There are two Dispose methods, one public and one protected:

The call to GC.SuppressFinalize(this) is what notifies the garbage collector that it no longer needs to run the finalizer, and removes the need for a second garbage collection.

Ensuring that Dispose is called

using (Animal a = new())
{
  // code that uses the Animal instance
}

The compiler converts your code into something like the following, which guarantees that even if an exception occurs, the Dispose method will still be called:

Animal a = new(); 
try
{
  // code that uses the Animal instance
}
finally
{
  if (a != null) a.Dispose();
}

You will see practical examples of releasing unmanaged resources with IDisposable, using statements, and try...finally blocks in Chapter 9, Working with Files, Streams, and Serialization.

Working with null values

Making a value type nullable

You can enable this by adding a question mark as a suffix to the type when declaring a variable.

Let's see an example:

1. Use your preferred coding tool to add a new Console Application to the Chapter06 workspace/solution named NullHandling. This section requires a full application with a project file, so you will not be able to use a .NET Interactive notebook.
2. In Visual Studio Code, select NullHandling as the active OmniSharp project. In Visual Studio, set NullHandling as the startup project.
3. In Program.cs, type statements to declare and assign values, including null, to int variables, as shown in the following code:

   int thisCannotBeNull  = 4; 
   thisCannotBeNull = null; // compile error!
   int? thisCouldBeNull = null; 
   WriteLine(thisCouldBeNull); 
   WriteLine(thisCouldBeNull.GetValueOrDefault());
   thisCouldBeNull = 7; 
   WriteLine(thisCouldBeNull); 
   WriteLine(thisCouldBeNull.GetValueOrDefault());
   

4. Comment out the statement that gives a compile error.
5. Run the code and view the result, as shown in the following output:

   0
   7
   7
   

The first line is blank because it is outputting the null value!

Understanding nullable reference types

The most significant change to the language in C# 8 was the introduction of nullable and non- nullable reference types. "But wait!", you are probably thinking, "Reference types are already nullable!"

And you would be right, but in C# 8 and later, reference types can be configured to no longer allow the null value by setting a file- or project-level option to enable this useful new feature. Since this is a big change for C#, Microsoft decided to make the feature opt-in.

During the transition, you can choose between several approaches for your own projects:

• Default: No changes are needed. Non-nullable reference types are not supported.
• Opt-in project, opt-out files: Enable the feature at the project level and, for any files that need to remain compatible with old behavior, opt out. This is the approach Microsoft is using internally while it updates its own packages to use this new feature.
• Opt-in files: Only enable the feature for individual files.

Enabling nullable and non-nullable reference types

To enable the feature at the project level, add the following to your project file:

<PropertyGroup>
  ...
  <Nullable>enable</Nullable>
</PropertyGroup>

#nullable disable

To enable the feature at the file level, add the following to the top of a code file:

#nullable enable

Declaring non-nullable variables and parameters

So, how do nullable reference types work? Let's look at an example. When storing information about an address, you might want to force a value for the street, city, and region, but the building can be left blank, that is, null:

Checking for null

// check that the variable is not null before using it
if (thisCouldBeNull != null)
{
  // access a member of thisCouldBeNull
  int length = thisCouldBeNull.Length; // could throw exception
  ...
}

C# 7 introduced is combined with the ! (not) operator as an alternative to !=, as shown in the following code:

if (!(thisCouldBeNull is null))
{

C# 9 introduced is not as an even clearer alternative, as shown in the following code:

if (thisCouldBeNull is not null)
{

If you are trying to use a member of a variable that might be null, use the null-conditional operator ?., as shown in the following code:

string authorName = null;
// the following throws a NullReferenceException
int x = authorName.Length;
// instead of throwing an exception, null is assigned to y
int? y = authorName?.Length;

// result will be 3 if authorName?.Length is null 
int result = authorName?.Length ?? 3; 
Console.WriteLine(result);

Checking for null in method parameters

When defining methods with parameters, it is good practice to check for null values.

public void Hire(Person manager, Person employee)
{
  if (manager == null)
  {
    throw new ArgumentNullException(nameof(manager));
  }
  if (employee == null)
  {
    throw new ArgumentNullException(nameof(employee));
  }
  ...
}

public void Hire(Person manager!!, Person employee!!)
{
  ...
}

The if statement and throwing of the exception are done for you.

Inheriting from classes

1. In the PacktLibrary project, add a new class file named Employee.cs.
2. Modify its contents to define a class named Employee that derives from Person, as shown in the following code:

   using System;
   namespace Packt.Shared;
   public class Employee : Person
   {
   }
   

3. In Program.cs, add statements to create an instance of the Employee class, as shown in the following code:

   Employee john = new()
   {
     Name = "John Jones",
     DateOfBirth = new(year: 1990, month: 7, day: 28)
   };
   john.WriteToConsole();
   

4. Run the code and view the result, as shown in the following output:

   John Jones was born on a Saturday.
   

Note that the Employee class has inherited all the members of Person.

Extending classes to add functionality

1. In Employee.cs, add statements to define two properties for an employee code and the date they were hired, as shown in the following code:

   public string? EmployeeCode { get; set; } 
   public DateTime HireDate { get; set; }
   

2. In Program.cs, add statements to set John's employee code and hire date, as shown in the following code:

   john.EmployeeCode = "JJ001";
   john.HireDate = new(year: 2014, month: 11, day: 23); 
   WriteLine($"{john.Name} was hired on {john.HireDate:dd/MM/yy}");
   

3. Run the code and view the result, as shown in the following output:

   John Jones was hired on 23/11/14
   

Hiding members

1. In Employee.cs, add statements to redefine the WriteToConsole method, as shown highlighted in the following code:

   using static System.Console; 
   namespace Packt.Shared;
   public class Employee : Person
   {
     public string? EmployeeCode { get; set; }
     public DateTime HireDate { get; set; }
     public void WriteToConsole()
     {
       WriteLine(format:
         "{0} was born on {1:dd/MM/yy} and hired on {2:dd/MM/yy}",
         arg0: Name,
         arg1: DateOfBirth,
         arg2: HireDate);
     }
   }
   

2. Run the code and view the result, as shown in the following output:

   John Jones was born on 28/07/90 and hired on 01/01/01 
   John Jones was hired on 23/11/14
   

Figure 6.4: Hidden method warning

As the warning describes, you can hide this message by applying the new keyword to the method, to indicate that you are deliberately replacing the old method, as shown highlighted in the following code:

public new void WriteToConsole()

Overriding members

Let's see an example:

Inheriting from abstract classes

This is a particular problem if you still need to create class libraries that will work with .NET Framework and other platforms that do not support .NET Standard 2.1.

In those earlier platforms, you could use abstract classes as a sort of halfway house between a pure interface and a fully implemented class.

When a class is marked as abstract, this means that it cannot be instantiated because you are indicating that the class is not complete. It needs more implementation before it can be instantiated.

For example, the System.IO.Stream class is abstract because it implements common functionality that all streams would need but is not complete, so you cannot instantiate it using new Stream().

public interface INoImplementation // C# 1.0 and later
{
  void Alpha(); // must be implemented by derived type
}
public interface ISomeImplementation // C# 8.0 and later
{
  void Alpha(); // must be implemented by derived type
  void Beta()
  {
    // default implementation; can be overridden
  }
}
public abstract class PartiallyImplemented // C# 1.0 and later
{
  public abstract void Gamma(); // must be implemented by derived type
  public virtual void Delta() // can be overridden
  {
    // implementation
  }
}
public class FullyImplemented : PartiallyImplemented, ISomeImplementation
{
  public void Alpha()
  {
    // implementation
  }
  public override void Gamma()
  {
    // implementation
  }
}
// you can only instantiate the fully implemented class
FullyImplemented a = new();
// all the other types give compile errors
PartiallyImplemented b = new(); // compile error!
ISomeImplementation c = new(); // compile error!
INoImplementation d = new(); // compile error!

Preventing inheritance and overriding

public sealed class ScroogeMcDuck
{
}

You can prevent someone from further overriding a virtual method in your class by applying the sealed keyword to the method. No one can change the way Lady Gaga sings, as shown in the following code:

using static System.Console;
namespace Packt.Shared;
public class Singer
{
  // virtual allows this method to be overridden
  public virtual void Sing()
  {
    WriteLine("Singing...");
  }
}
public class LadyGaga : Singer
{
  // sealed prevents overriding the method in subclasses
  public sealed override void Sing()
  {
    WriteLine("Singing with style...");
  }
}

Understanding polymorphism

It all depends on the type of variable holding a reference to the object. For example, a variable of the Person type can hold a reference to a Person class, or any type that derives from Person.

Let's see how this could affect your code:

1. In Employee.cs, add statements to override the ToString method so it writes the employee's name and code to the console, as shown in the following code:

   public override string ToString()
   {
     return $"{Name}'s code is {EmployeeCode}";
   }
   

2. In Program.cs, write statements to create a new employee named Alice, store it in a variable of type Person, and call both variables' WriteToConsole and ToString methods, as shown in the following code:

   Employee aliceInEmployee = new()
     { Name = "Alice", EmployeeCode = "AA123" };
   Person aliceInPerson = aliceInEmployee; 
   aliceInEmployee.WriteToConsole(); 
   aliceInPerson.WriteToConsole(); 
   WriteLine(aliceInEmployee.ToString()); 
   WriteLine(aliceInPerson.ToString());
   

3. Run the code and view the result, as shown in the following output:

   Alice was born on 01/01/01 and hired on 01/01/01 
   Alice was born on a Monday
   Alice's code is AA123 
   Alice's code is AA123
   

When a method is hidden with new, the compiler is not smart enough to know that the object is an Employee, so it calls the WriteToConsole method in Person.

The member modifiers and the effect they have are summarized in the following table:

In my opinion, polymorphism is academic to most programmers. If you get the concept, that's cool; but, if not, I suggest that you don't worry about it. Some people like to make others feel inferior by saying understanding polymorphism is important for all C# programmers to learn, but IMHO it's not.

You can have a successful career with C# and never need to be able to explain polymorphism, just as a racing car driver doesn't need to be able to explain the engineering behind fuel injection.

Casting within inheritance hierarchies

Implicit casting

Explicit casting

1. In Program.cs, add a statement to assign the aliceInPerson variable to a new Employee variable, as shown in the following code:

   Employee explicitAlice = aliceInPerson;
   

2. Your coding tool displays a red squiggle and a compile error, as shown in Figure 6.5:

   

   Figure 6.5: A missing explicit cast compile error

3. Change the statement to prefix the assigned variable named with a cast to the Employee type, as shown in the following code:

   Employee explicitAlice = (Employee)aliceInPerson;
   

Avoiding casting exceptions

We can handle this by writing a try statement, but there is a better way. We can check the type of an object using the is keyword:

What if you want to execute a block of statements when Alice is not an employee?

In the past, you would have had to use the ! (not) operator, as shown in the following code:

if (!(aliceInPerson is Employee))

if (aliceInPerson is not Employee)

Inheriting and extending .NET types

Inheriting exceptions

Extending types when you can't inherit

Microsoft has applied the sealed keyword to the System.String class so that no one can inherit and potentially break the behavior of strings.

Using static methods to reuse functionality

Let's write some code:

1. In the PacktLibrary project, add a new class named StringExtensions, as shown in the following code, and note the following:
   • The class imports a namespace for handling regular expressions.
   • The IsValidEmail method is static and it uses the Regex type to check for matches against a simple email pattern that looks for valid characters before and after the @ symbol.

   using System.Text.RegularExpressions;
   namespace Packt.Shared;
   public class StringExtensions
   {
     public static bool IsValidEmail(string input)
     {
       // use simple regular expression to check
       // that the input string is a valid email
       return Regex.IsMatch(input,
         @"[a-zA-Z0-9\.-_]+@[a-zA-Z0-9\.-_]+");
     }
   }
   

2. In Program.cs, add statements to validate two examples of email addresses, as shown in the following code:

   string email1 = "pamela@test.com"; 
   string email2 = "ian&test.com";
   WriteLine("{0} is a valid e-mail address: {1}", 
     arg0: email1,
     arg1: StringExtensions.IsValidEmail(email1));
   WriteLine("{0} is a valid e-mail address: {1}",
     arg0: email2,
     arg1: StringExtensions.IsValidEmail(email2));
   

3. Run the code and view the result, as shown in the following output:

   pamela@test.com is a valid e-mail address: True 
   ian&test.com is a valid e-mail address: False
   

Using extension methods to reuse functionality

Although extension methods might not seem to give a big benefit, in Chapter 11, Querying and Manipulating Data Using LINQ, you will see some extremely powerful uses of extension methods.

Using an analyzer to write better code

Suppressing warnings

To suppress a warning, you have several options, including adding code and setting configuration.

[assembly:SuppressMessage("StyleCop.CSharp.OrderingRules", "SA1200:UsingDirectivesMustBePlacedWithinNamespace", Justification = "Reviewed.")]

To suppress using a directive, as shown in the following code:

#pragma warning disable SA1200 // UsingDirectivesMustBePlacedWithinNamespace
using System;
#pragma warning restore SA1200 // UsingDirectivesMustBePlacedWithinNamespace

Let's suppress the warning by modifying the stylecop.json file:

Fixing the code

Understanding common StyleCop recommendations

1. External alias directives
2. Using directives
3. Namespaces
4. Delegates
5. Enums
6. Interfaces
7. Structs
8. Classes

Within a class, record, struct, or interface, you should order the contents, as shown in the following list: