Forem: Carl-Hugo Marcotte

Architecting ASP.NET Core Applications—Unveiling the Third Edition

Carl-Hugo Marcotte — Mon, 25 Mar 2024 10:59:00 +0000

After hundreds of hours of work, a new team, and two new tech reviewers, I'm delighted to announce the release of the third edition of Architecting ASP.NET Core Applications, a unique guide for constructing resilient ASP.NET Core web applications.

But that was not the title of the first two editions?!? That's correct. After thoughtful consideration, the book has a new title!
Why? All editions were never only about design patterns, which is even more true for the 3rd edition, which expands even more than before into architectural styles and application organization, offering diverse strategies for structuring ASP.NET Core applications.
Of course, I wanted to keep the essence of the first two editions, so here's the subtitle that brings that continuity: An Atypical Design Patterns Guide for .NET 8, C# 12, and Beyond.

Have you noticed the and Beyond suffix? Well, that's because the book is good not only for .NET 8 and C# 12, but you'll also be able to leverage its content for future versions, and we wanted to clarify this.

Read the official LinkedIn Launch Post! Buy the book on Amazon!

Let's start with the updated Table of Content:

Section 1: Principles and Methodologies
1. Introduction
2. Automated Testing
3. Architectural Principles
4. REST APIs

Section 2: Designing with ASP.NET Core
5. Minimal API
6. Model-View-Controller
7. Strategy, Abstract Factory, and Singleton Design Patterns
8. Dependency Injection
9. Application Configuration and the Options Pattern
10. Logging patterns

Section 3: Components Patterns
11. Structural Patterns
12. Behavioral Patterns
13. Operation Result Pattern

Section 4: Application Patterns
14. Layering and Clean Architecture
15. Object Mappers
16. Mediator and CQS Patterns
17. Vertical Slice Architecture
18. Request-EndPoint-Response (REPR)
19. Introduction to Microservices Architecture
20. Modular Monolith

Have you noticed? We removed the UI chapters and replaced them with more REST APIs and backend content!
Yes! This third edition is a testament to our commitment to relevancy and depth, which is now exclusively focused on developers striving for robust REST API and backend design knowledge.

Definition of terms and acronyms

If there are terms, acronyms, or concepts you are unsure about, I left a list at the end of the article under Definition of terms and acronyms.

Backend Design Like You've Never Seen Before

Architecting ASP.NET Core Applications is your gateway to mastering REST API and backend designs. It gives you the know-how for building robust and maintainable apps grounded in Gang of Four (GoF) design patterns and well-known architectural principles like SOLID, DRY, and YAGNI. The book focuses on the technical architecture mindset. It is written as a journey where we improve code over time, rework and refactor examples, and more to ensure you understand the logic behind the techniques we are covering. At the end of the book, I want you to understand the choices that we made so you can apply a similar way of thinking to your real-world problems, which are not covered in any books because each challenge is unique in the real world!

This book is a deep dive into the architectural essence of building enduring ASP.NET Core applications. The third edition is here to quench your thirst for knowledge with an expanded section on Minimal APIs, more automated testing content, more architectural building blocks, more ways to organize your applications, and a closing chapter about building a modular monolith. We explore many application-building techniques, from layering to microservices.

What is a Modular Monolith?

Modular Monolith: A modular monolith organizes code into modules within a single application, combining the simplicity of a monolith with modular flexibility, easing maintenance and deployment.

Figure 20.2: A Modular Monolith, an aggregator, and three modules, each owning its own database schema

You can also read the following articles to learn more about Microservices Aggregation (Modular Monolith).

What's new in the third edition?

The sections are reimagined for a smoother learning journey, and the content has been revised to improve the clarity of each chapter. Chapters now prioritize REST API design and patterns, shedding extraneous UI code to concentrate on what truly matters in backend development.

Chapter 2 has been overhauled to cover testing approaches like black-box, white-box, and grey-box testing. The foundational architectural principles are rearranged, and the chapter is improved to establish the groundwork for modern application design even better than before. Two new chapters now focus on REST APIs and Minimal APIs, while a third chapter about building Web APIs using MVC was updated.

I improved and increased the number of real-world-like examples where numerous code projects have been updated or rewritten completely. The Dependency Injection chapter benefited from significant updates as well. I split the options and logging chapter in two, and improved the content.

Many other changes were applied, like improving the heading of chapters for easier navigation, and all chapters benefitted from content tweaks, diagram updates, code sample revamps, and more. On top of that, I added new content around open-source tools like Mapperly, MassTransit, and Refit.

Additionally, Chapter 18 is a new chapter dedicated to the Request-EndPoint-Response (REPR) pattern using Minimal APIs. I also listened to your feedback and added some code to the Microservices chapter. The new microservices project extends the REPR code sample to microservices architecture and introduces API layering with a Backend For Frontend (BFF) example. Finally, Chapter 20 is also new, discusses modular monolith architecture, and builds on top of Chapters 18 and 19's new e-commerce examples. That last project, rebuilt in three flavors, is a larger implementation that combines more building blocks like a real app would while keeping it small enough to fit in a book.

What is Microservices Architecture?

Microservices Architecture breaks down a large application into smaller, independent pieces, each performing a specific function. These microservices communicate with each other to form a scalable system, often deployed in the cloud as containerized or serverless applications, enhancing flexibility and scalability.

Figure 19.25: A diagram that represents the deployment topology and relationship between the different services

You can also read the following articles to learn more about Implementing Microservices Architectures.

Your ASP.NET Core Development Companion

Once again, this release is crafted for intermediate ASP.NET Core developers eager to refine their knowledge of design patterns and application development. Software architects keen on revitalizing their theoretical and hands-on expertise will also find this third edition an invaluable ally. With comprehensive coverage of updated architectural patterns, RESTful design, SOLID principles, and a touch of microservices, this edition stands as a pillar of modern backend application design.

For the best experience, I recommend you read the book cover to cover first to ensure you understand the decisions behind the refactoring and improvements we make throughout. Of course, afterward, you can use it as a reference and browse it however you please.

Embrace The Journey of Backend Mastery

Join me on an exceptional learning path that will revolutionize your ASP.NET Core application architecture perspective. The third edition awaits you, promising a transformative encounter with REST API and backend design unlike anything you’ve experienced before.

Definition of terms and acronyms

Here is a reference to certain terms and acronyms from the article.
Hopefully, these definitions will help you out.

Terms and acronyms

REST API: REST (Representational State Transfer) API is a design style that uses HTTP requests to access and use data, allowing applications to communicate and exchange data in a standardized format, enhancing interoperability and simplicity in web services.

RESTful: RESTful refers to web services that adhere to REST principles, enabling seamless and efficient interaction between clients and servers through standardized HTTP operations.

Gang of Four (GoF) design patterns: These foundational patterns, identified by four authors, offer solutions to common design challenges, improving code reusability and maintainability.

GoF Design Patterns (Strategy, Abstract Factory, Singleton): Strategy enables selecting algorithms at runtime; Abstract Factory offers an interface for creating families of related objects; Singleton ensures a class has only one instance and provides a global point of access to it.

SOLID, DRY, and YAGNI principles: SOLID represents five principles of object-oriented design that increase software maintainability; DRY ("Don't Repeat Yourself") emphasizes avoiding code duplication; YAGNI ("You Aren't Gonna Need It") advises against adding unnecessary functionality.

Minimal API: ASP.NET Core Minimal APIs enable fast and efficient REST endpoint creation with minimal code, dependencies, and configuration, focusing on simplicity and performance while streamlining route and action declaration without needing traditional scaffolding or controllers.

Model-View-Controller (MVC): MVC is a design pattern that separates an application into three main components—Model, View, and Controller—to isolate business logic, user interface, and user input.

Dependency Injection: This technique allows the creation of dependent objects outside of a class and provides those objects to the class, improving modularity and testability and breaking tight coupling.

REPR (Request-EndPoint-Response) Pattern: This pattern promotes the simple routing and handling of HTTP requests by directly associating requests with their handling functions and responses, promoting clean and readable code.

Microservices Architecture: This architecture style structures an application as a collection of small, autonomous services, improving modularity and scalability.

Modular Monolith: A modular monolith organizes code into modules within a single application, combining the simplicity of a monolith with modular flexibility, easing maintenance and deployment.

Read the official LinkedIn Launch Post! Buy the book on Amazon!

Implementing Microservices Architectures

Carl-Hugo Marcotte — Sat, 25 Jun 2022 14:50:55 +0000

This article aims to give you an overview of the concepts surrounding microservices and event-driven architecture, which should help you make informed decisions about whether you should go for a microservices architecture or not.

The following topics will be covered:

What are microservices?
An introduction to event-driven architecture

This article is an excerpt from my book, An Atypical ASP.NET Core 6 Design Patterns Guide.

What are microservices?

Besides being a buzzword, microservices represent an application that is divided into multiple smaller applications. Each application, or microservice, interacts with the others to create a scalable system. Usually, microservices are deployed to the cloud as containerized or serverless applications.

Before getting into too many details, here are a few principles to keep in mind when building microservices:

Each microservice should be a cohesive unit of business.
Each microservice should own its data.
Each microservice should be independent of the others.

Furthermore, everything we have studied so far—that is, the other principles of designing software—applies to microservices but on another scale. For example, you don't want tight coupling between microservices (solved by microservices independence), but the coupling is inevitable (as with any code). There are numerous ways to solve this problem, such as the Publish-Subscribe pattern.

There are no hard rules about how to design microservices, how to divide them, how big they should be, and what to put where. That being said, I'll lay down a few foundations to help you get started and orient your journey into microservices.

Cohesive unit of business

A microservice should have a single business responsibility. Always design the system with the domain in mind, which should help you divide the application into multiple pieces. If you know Domain-Driven Design (DDD), a microservice will most likely represent a Bounded Context, which in turn is what I call a cohesive unit of business. Basically, a cohesive unit of business (or bounded context) is a self-contained part of the domain that has limited interactions with other parts of the domain.

Even if a microservice has micro in its name, it is more important to group logical operations under it than to aim at a micro-size. Don't get me wrong here; if your unit is tiny, that's even better. However, suppose you split a unit of business into multiple smaller parts instead of keeping it together (breaking cohesion).

In that case, you are likely to introduce useless chattiness within your system (coupling between microservices). This could lead to performance degradation and to a system that is harder to debug, test, maintain, monitor, and deploy.

Moreover, it is easier to split a big microservice into smaller pieces than assemble multiple microservices back together.

Try to apply the Single Responsibility Principle (SRP) to your microservices: a microservice should have only one reason to change unless you have a good reason to do otherwise.

Ownership of data

Each microservice is the source of truth of its cohesive unit of business. A microservice should share its data through an API (a web API/HTTP, for example) or another mechanism (integration events, for example). It should own that data and not share it with other microservices directly at the database level.

For instance, two different microservices should never access the same relational database table. If a second microservice needs some of the same data, it can create its own cache, duplicate the data, or query the owner of that data but not access the database directly; never.

This data-ownership concept is probably the most critical part of the microservices architecture and leads to microservices independence. Failing at this will most likely lead to a tremendous number of problems. For example, if multiple microservices can read or write data in the same database table, each time something changes in that table, all of them must be updated to reflect the changes. If different teams manage the microservices, that means cross-team coordination. If that happens, each microservice is not independent anymore, which opens the floor to our next topic.

Microservice independence

At this point, we have microservices that are cohesive units of business and own their data. That defines independence.

This independence offers the systems the ability to scale while having minimal to no impact on the other microservices. Each microservice can also scale independently, without the need for the whole system to be scaled. Additionally, when the business requirements grow, each part of that domain can evolve independently.

Furthermore, you could update one microservice without impacting the others or even have a microservice go offline without the whole system stopping.

Of course, microservices have to interact with one another, but the way they do should define how well your system runs. A little like Vertical Slice architecture, you are not limited to using one set of architectural patterns; you can independently make specific decisions for each microservice. For example, you could choose a different way for how two microservices communicate with each other versus two others. You could even use different programming languages for each microservice.

Tip

I recommend sticking to one or a few programming languages for smaller businesses and organizations as you most likely have fewer developers, and each has more to do. Based on my experience, you want to ensure business continuity when people leave and make sure you can replace them and not sink the ship due to some obscure technologies used here and there (or too many technologies).

Now that we've defined the basics, let's jump into the different ways microservices can communicate using event-driven architecture.

An introduction to event-driven architecture

Event-driven architecture (EDA) is a paradigm that revolves around consuming streams of events, or data in motion, instead of consuming static states.

What I define by a static state is the data stored in a relational database table or other types of data stores, like a NoSQL documents store. That data is dormant in a central location and waiting for actors to consume and mutate it. It is stale between every mutation and the data (a record, for example) represents a finite state.

On the other hand, data in motion is the opposite: you consume the ordered events and determine the change in state that each event brings.

What is an event? People often interchange the words event, message, and command. Let’s try to clarify this:

A message is a piece of data that represents something.
A message can be an object, a JSON string, bytes, or anything else your system can interpret.
An event is a message that represents something that happened in the past.
A command is a message sent to tell one or more recipients to do something.
A command is sent (past tense), so we can also consider it an event.

A message usually has a payload (or body), headers (metadata), and a way to identify it (this can be through the body or headers).

We can use events to divide a complex system into smaller pieces or have multiple systems talk to each other without creating tight couplings. Those systems could be subsystems or external applications, such as microservices.

Like Data Transfer Objects (DTO) of web APIs, events become the data contracts that tie the multiple systems together (coupling). It is essential to think about that carefully when designing events. Of course, we cannot foresee the future, so we can only do so much to get it perfect the first time. There are ways to version events, but this is out of the scope of this article.

EDA is a fantastic way of breaking tight coupling between microservices but requires rewiring your brain to learn this newer paradigm. Tooling is less mature, and expertise is scarcer than more linear ways of thinking (like using point-to-point communication and relational databases), but this is slowly changing and well worth learning (in my opinion).

We can categorize events into the following overlapping buckets:

Domain events
Integration events
Application events
Enterprise events

As we’ll explore next, all types of events play a similar role with different intents and scopes.

Domain events

A domain event is a term based on DDD representing an event in the domain. This event could then trigger other pieces of logic to be executed subsequently. It allows a complex process to be divided into multiple smaller processes. Domain events work well with domain-centric designs, like Clean Architecture, as we can use them to split complex domain objects into multiple smaller pieces. Domain events are usually application events. We can use MediatR to publish domain events inside an application.

To summarize, domain events integrate pieces of domain logic together while keeping the domain logic segregated, leading to loosely coupled components that hold one domain responsibility each (single responsibility principle).

Integration events

Integration events are like domain events but are used to propagate messages to external systems, to integrate multiple systems together while keeping them independent. For example, a microservice could send the new user registered event message that other microservices react to, like saving the user id to enable additional capabilities or sending a greeting email to that new user.

We use a message broker or message queue to publish such events. We’ll cover those next, after covering application and enterprise events.

To summarize, integration events integrate multiple systems together while keeping them independent.

Application events

An application event is an event that is internal to an application; it is just a matter of scope. If the event is internal to a single process, that event is also a domain event (most likely). If the event crosses microservices boundaries that your team owns (the same application), it is also an integration event. The event itself won't be different; it is the reason why it exists and its scope that describes it as an application event or not.

To summarize, application events are internal to an application.

Enterprise events

An enterprise event describes an event that crosses internal enterprise boundaries. These are tightly coupled with your organizational structure. For example, a microservice sends an event that other teams, part of other divisions or departments, consume.

The governance model around those events should be different from application events that only your team consumes. Someone must think about who can consume that data, under what circumstances, the impact of changing the event schema (data contract), schema ownership, naming conventions, data-structure conventions, and more, or risk building an unstable data highway.

Note

I like to see EDA as a central data highway in the middle of applications, systems, integrations, and organizational boundaries, where the events (data) flow between systems in a loosely coupled manner.

It’s like a highway where cars flow between cities (without traffic jams). The cities are not controlling what car goes where but are open to visitors.

To summarize, enterprise events are integration events that cross organizational boundaries.

Conclusion

We defined events, messages, and commands in this quick overview of event-driven architecture. An event is a snapshot of the past, a message is data, and a command is an event that suggests other systems to take action. Since all messages are from the past, calling them events is accurate. We then organized events into a few overlapping buckets to help identify the intents. We can send events for different objectives, but whether it is about designing independent components or reaching out to different parts of the business, an event remains a payload that respects a certain format (schema). That schema is the data contract (coupling) between the consumers of those events. That data contract is probably the most important piece of it all; break the contract, break the system.

Now, let's see how event-driven architecture can help us follow the SOLID principles at cloud-scale:

S: Systems are independent of each other by raising and responding to events. The events themselves are the glue that ties those systems together. Each piece has a single responsibility.
O: We can modify the system’s behaviors by adding new consumers to a particular event without impacting the other applications. We can also raise new events to start building a new process without affecting existing applications.
L: N/A.
I: Instead of building a single process, EDA allows us to create multiple smaller systems that integrate through data contracts (events) where those contracts become the messaging interfaces of the system.
D: EDA enables systems to break tight coupling by depending on the events (interfaces/abstractions) instead of communicating directly with one another, inverting the dependency flow.

EDA does not only come with advantages; it also has a few drawbacks:

Microservices come at a cost and building a monolith is still a good idea for many projects.
It is easier to add new features to a monolith than it can be to add them to a microservice application.
Most of the time, mistakes cost less in a monolith than in a microservices application.

You will explore any intricacies of microservices in more detail in An Atypical ASP.NET Core 6 Design Patterns Guide, along with analysis of each of the following patterns:

Mediating communication between microservices using message queues and the Publish-Subscribe pattern.
Shielding and hiding the complexity of the microservices cluster using Gateway patterns.
Using one model to read the data and one model to mutate the data with CQRS pattern.
Adding missing features, adapting one system to another, or migrating an existing application to an event-driven architecture model, to name a few possibilities, with the Microservices Adapter pattern.

Summary

The microservices architecture is different to building monoliths. Instead of one big application, we split it into multiple smaller ones that we call microservices. Microservices must be independent of one another; otherwise, we will face the same problems associated with tightly coupled classes, but at the cloud scale.

Microservices are great when you need scaling, want to go serverless, or split responsibilities between multiple teams, but keep the operational costs in mind. Starting with a monolith and migrating it to microservices when scaling is another solution. You can also plan your future migration toward microservices, which leads to the best of both worlds while keeping operational complexity low.

I don't want you to discard the microservices architecture, but I just want to make sure that you weigh up the pros and cons of such a system before blindly jumping in. Your team's skill level and ability to learn new technologies may also impact the cost of jumping into the microservices boat.

Boolean algebra laws with C#

Carl-Hugo Marcotte — Sun, 29 Aug 2021 14:31:22 +0000

This article explores multiple Boolean algebra laws in a programmer-oriented way, leaving the mathematic notation aside. Those laws can be beneficial when working with boolean logic to simplify complex conditions. This article is very light in explanation and exposes the laws using C#. Don't worry, I'm not recycling myself as a math teacher.

This article is part of a learn programming series where you need no prior knowledge of programming.
If you want to learn how to program and want to learn it using .NET/C#, this is the right place.
I suggest reading the whole series in order, starting with Creating your first .NET/C# program, but that's not mandatory.

This article is part of a sub-series, starting with Introduction to Boolean algebra and logical operators.
It is not mandatory to read all articles in order, but I strongly recommend it, especially if you are a beginner.
If you are already reading the whole series in order, please discard this word of advice.

Let's explore Boolean algebra laws in alphabetical order.
Some are very simple, while some may seem more complex, but all are very useful tools.

In the examples, the variables (A, B, C) are all booleans, like this:

bool A, B, C;

Absorption Law

The absorption law goes as follow:

A && (A || B) always equals A
A || A && B always equals A

Annulment Law

The annulment law goes as follow:

A && false is always false
A || true is always true

Associative Law

The associative law says that no matter the order or priority of the OR comparisons, the result will always be the same.
The following conditions yield the same result:

A || (B || C)
(A || B) || C
(A || C) || B
A || B || C

Complement Law

The complement law goes as follow:

A && !A is always false
A || !A is always true

Commutative Law

The commutative law goes as follow:

A && B is the same as B && A
A || B is the same as B || A

Consensus Law

The consensus law goes as follow:

(A || B) && (!A || C) && (B || C) is equivalent to (A || B) && (!A || C)
A && B || A && C || B && C is equivalent to A && B || A && C

These two might be harder to grasp, so here's my take at a quick explanation:

In the first two comparisons of (A || B) && (!A || C) && (B || C), A and !A are almost cancelling themselves, leaving the outcome of the comparison to B and C. Based on that fact, no matter the values, the last comparison && (B || C) becomes useless (already evaluated).
The second one is similar. In the first two comparisons of A && B || A && C || B && C, we test B and C, making the last comparison void || B && C.

Word of advice: it is not mandatory to remember the consensus law, so feel free to skip this one if you think it's too complicated for today. You can always come back to it later.

De Morgan's laws

This one is very interesting and can be handy from time to time.
In plain English, De Morgan's laws are:

The negation of a disjunction is the conjunction of the negations.
The negation of a conjunction is the disjunction of the negations.

Logical conjunction means AND (&&), and the logical disjunction means OR (||).
Unless you are into mathematics, you don't have to remember that.

Now to the part that interests us, in C#, De Morgan's laws are:

!(A || B) is equivalent to !A && !B
!(A && B) is equivalent to !A || !B

Distributive Law

The distributive law goes as follow:

A && B || A && C is equivalent to A && (B || C)
(A || B) && (A || C) is equivalent to A || B && C

Double negation law

The double negation law says that two negations negate themselves.
In C# this looks like:

!!A is equivalent to A

Identity Law

The identity law goes as follow:

A && true always equals A
A || false always equals A

Idempotent Law

The idempotent law goes as follow:

A && A always equals A
A || A always equals A

Redundancy Law

The redundancy law goes as follow:

(A || B) && (A || !B) always equals A
A && B || A && !B always equals A
(A || !B) && B is equivalent to A && B
A && !B || B is equivalent to A || B

Conclusion

In this article, we explored a bunch of Boolean algebra laws from a C# programmer perspective. You can find information on them, including mathematic proofs, online or in books if you are into maths. Personally, I prefer the plain C# version, so that's why I translated them to this here. Even if some of those laws might seem a bit too complicated to remember, don't be discouraged; even the simplest ones are helpful: start there.

Programming is like playing LEGO^® blocks: we can combine all of those laws, which are logic patterns. For example, !(!A || !B) looks complicated, but after applying De Morgan's law, it becomes equivalent to !(!(A && B)). By removing the useless parenthesis we end up having !!(A && B), which exposes a double negation. Applying the double negation law leads to A && B. That simplified version of the original condition looks way simpler, doesn't it?

Learning the basics is helpful in the long run. If you have a good memory, feel free to memorize all of this as a starting point. If you don't, don't worry, learn them one by one. The idea is to simplify your code, so it reaches a more maintainable state. With a bit of time, you will most likely know and apply many (if not all) of them without thinking about it. Just start with the simplest ones, bookmark the article, and learn the others later. Understanding rules, laws, and concepts should get you further than just remembering them; but that takes more time.

Fun fact: I've run many interviews in 2021, and one of my favorite technical questions is based on complicated conditions that can be simplified using some of those laws. And no, I'm not looking for candidates that know the name of the laws, just if they can resolve a complex if-statement and how.

Please leave your questions or comments below or drop me a Tweet.

Next step

Stay tuned by following me on dev.to, Twitter, or other places you can find me.
You can look at my blog for more info.

Using the switch selection statement to simplify conditional statements blocks

Carl-Hugo Marcotte — Sun, 25 Jul 2021 15:54:34 +0000

This article explores how to simplify certain complex conditional blocks by introducing the switch statement.
The switch keyword is very standard in programming languages.
We use it to compare a variable with many values.

Please note that we are not covering switch expressions in this article.

This article is part of a sub-series, starting with Introduction to Boolean algebra and logical operators.
It is not mandatory to read all articles in order, but I strongly recommend it, especially if you are a beginner.
If you are already reading the whole series in order, please discard this word of advice.

The Switch

In the previous article, Using if-else selection statements to write conditional code blocks, we covered the basics behind contextual code.
This article explores the switch statement by converting a complex if block to a switch.
We go through the syntax afterward.

Initial code (if):

using System;

Console.WriteLine("Enter something: ");
var input = Console.ReadLine();
if (input == "hello" || input == "world" || input == "hello world")
{
    Console.WriteLine("Hello World!");
}
else if (input == "goodbye")
{
    Console.WriteLine("Au revoir!"); // Goodbye in French
}
else if (input == "name?")
{
    Console.WriteLine("What is your name?");
    var name = Console.ReadLine();
    Console.WriteLine($"Your name is {name}");
}
else
{
    Console.WriteLine("Invalid input");
}
Console.WriteLine("End of the program.");

Converted code (switch):

using System;

Console.WriteLine("Enter something: ");
var input = Console.ReadLine();
switch (input)
{
    case "hello":
    case "world":
    case "hello world":
        Console.WriteLine("Hello World!");
        break;
    case "goodbye":
        Console.WriteLine("Au revoir!"); // Goodbye in French
        break;
    case "name?":
        Console.WriteLine("What is your name?");
        var name = Console.ReadLine();
        Console.WriteLine($"Your name is {name}");
        break;
    default:
        Console.WriteLine("Invalid input");
        break;
}
Console.WriteLine("End of the program.");

Let's now analyze the previous code, starting with the new keywords:

switch
case
break
default

The switch keyword starts a code block that must be followed by a variable in parenthesis, like this:

switch (variable)
{
    // Code block
}

The case keyword, followed by a value and :, is an equality comparison against the original variable passed to the switch.
You can see case "goodbye": as the equivalent of if (variable == "goodbye").
A case block can be empty or end with a break or return.
We will not cover the return keyword in this article because it is related to other concepts that we have not explored yet.
When the case is empty, it continues to the next case.
For example, case "hello": falls back to case "world": that falls back to case "hello world": that gets executed.

Interesting fact: C# does not support falling from one non-empty case to another as some other languages do.

The break keyword is a jump statement that allows controlling the flow of the program by exiting the current block, a.k.a. jumping out of the switch block.

Finally, in a switch block, the default keyword is the equivalent of the else; it is hit when no other case was hit.

Before the exercise, let's peek at the program flow created by a switch statement.

Flow of the program

In a nutshell, a switch statement allows comparing if a variable is equal to a value from a list of cases.
Here is a visual representation of the program flow created by a switch block:

Next, it's your turn to try it out.

Exercise

Convert the following code to use a switch statement.

var input = Console.ReadLine();
if(input == "A")
{
    Console.WriteLine("1");
}
else if (input == "B")
{
    Console.WriteLine("2");
}
else if (input == "C")
{
    Console.WriteLine("3");
}
else if (input == "D")
{
    Console.WriteLine("4");
}
else if (input == "E")
{
    Console.WriteLine("5");
}
else
{
    Console.WriteLine("Invalid input");
}

Once you are done, you can compare with My Solution below.

My Solution
Program.cs

var input = Console.ReadLine();
switch (input)
{
    case "A":
        Console.WriteLine("1");
        break;
    case "B":
        Console.WriteLine("2");
        break;
    case "C":
        Console.WriteLine("3");
        break;
    case "D":
        Console.WriteLine("4");
        break;
    case "E":
        Console.WriteLine("5");
        break;
    default:
        Console.WriteLine("Invalid input");
        break;
}

Good job! You completed another small chapter of your programming journey.

Conclusion

This article explored the switch statement, which allows comparing if a variable is equal to a value from a list of cases.
The switch statement is another way to create conditional code and control our programs' flow.

The switch statement is handy for variables with a finite number of values like enums.
More recent versions of C# also introduce switch expressions and pattern matching that open many other possibilities. However, many of those possibilities require knowledge of object-oriented programming that we are not exploring in this article series.

Please leave your questions or comments below or drop me a Tweet.

Next step

It is now time to move to the next article: Common Boolean algebra laws which is coming soon. Stay tuned by following me on dev.to, Twitter, or other places you can find me.
You can look at my blog for more info.

Using if-else selection statements to write conditional code blocks

Carl-Hugo Marcotte — Sat, 19 Jun 2021 16:11:54 +0000

In this article, we are exploring conditional execution flows. What is a code path? What is a conditional? What's an if statement? These are the subject that we cover here.
As part of the beginner journey, we focus on the if-else selection statements LEGO® block, laying down the foundation for more advanced use-cases.

In this article, we are exploring conditional execution flows. What is a code path? How will we do that? These are the subject that we cover here.
As part of the beginner journey, we focus on the if-else selection statements LEGO® block, laying down the foundation for more advanced use-cases.

This article is part of a sub-series, starting with Introduction to Boolean algebra and logical operators.
It is not mandatory to read all articles in order, but I strongly recommend it, especially if you are a beginner.
If you are already reading the whole series in order, please discard this word of advice.

Conditional execution flow

In the article How to read user inputs from a console, we talked about the flow of a program, moving from the first instruction to the next.
Let's call that linear execution flow.
Here, you will learn how to run only part of the code based on different values, leading to a more complex execution flow model.

By writing conditional code blocks, we can create a program that actually has more complex logic than what we programmed so far.
Our program will be able to do different things based on different runtime values, like user inputs.

Let's now explore how to program that using C#.

Equality operators

Before we dig into the conditional blocks, we will visit two new operators to help us compare if two values are equal or not.
Those works with all primitive types like string and int, for example.

Equality operator ==

The equality operator == allows comparing if two values are equal.
The syntax is left_operands == right_operand and returns a Boolean value.

Tip: you can read this as left_operand is equal to right_operand.

Here is an example:

var left = "A";
var right = "B";
var result = left == right; // false
// ...

In the preceding code, since A is not equal to B, the result of the left == right comparison is false.
In the case of "A" == "A", the result would have been true.

We have one last operator to look into before exploring the if-else selection statements, the inequality operator.

Inequality operator !=

The inequality operator != is the opposite of the equality operator and allows comparing if two values are different (not equal).
The syntax is left_operands != right_operand and returns a Boolean value.

Tip: you can read this as left_operand is not equal to right_operand or left_operand is different than right_operand.

Here is an example:

var left = "A";
var right = "B";
var result = left != right; // true
// ...

In the preceding code, since A is not equal to B, the result of the left != right comparison is true.

More info: the inequality operator is syntactic sugar, equivalent to !(left == right).
This simplifies writing C# code a lot.

Other comparison operators exist, but let's keep our scope narrow here and jump into the main subject instead.

if-else selection statements

The if-else selection statements are blocks of C# code that are executed conditionally based on a Boolean expression—a condition that evaluates to true or false.
In this section, we are exploring the following concepts:

Statements block
The if statement
The else statement
The else if statement

Statements block

In C#, a statements block is delimited by { and }, like this:

// Code before the statement block
{ // Statement block start delimiter
    //
    // Code inside the block
    //
} // Statement block end delimiter
// Code after the statement block

A block creates a sub-context that can access its parent context.
However, the parent context can't access that sub-context.
Here is an example that illustrates this concept:

using System;

var a = 1;
{
    var b = 2;
    Console.WriteLine($"Inside block; a = {a}");
    Console.WriteLine($"Inside block; b = {b}");
}
Console.WriteLine($"Outside block; a = {a}");
Console.WriteLine($"Outside block; b = {b}"); // Error: The name 'b' does not exist in the current context

In the preceding code, the program can access the a variable from inside the statements block but cannot access the b variable from outside of it.
Because of that, if we execute the code, .NET will report an error telling us The name 'b' does not exist in the current context.

We use statements blocks extensively throughout the article, so don't worry about it if you are unsure why you would write one.
Let's explore why I indented the code inside the block before writing our first conditional code block using the if statement.

Indentation

Have you noticed the indentation added inside the statements block?
By convention, we add that indentation for readability.
That makes the different contexts (or nested-levels) line up vertically, like this:

In C#, we usually use 4 spaces to indent the code.
People may also use 2 spaces (not frequent in the .NET/C# world).
Some people also prefer to use tabs instead of spaces.
By default, Visual Studio and Visual Studio Code will translate a tab to N spaces automatically (default: 4), so you don't have to type 4 spaces every time. One tab will do.

"Fun" fact: A tabs versus spaces war also exists where people prefer tabs over spaces or vice versa and argue that their way is the best over the other.
I personally use spaces, tried tabs, tried many techniques during the years, and realized that it does not matter much in the end.
If you are working in a team or an enterprise, there may well be existing guidelines around this.

Next, we explore the if statement.

The `if` statement

The if statement does literally what its English definition is: if the condition is true, then enter the statements block; otherwise, don't.
This is where we begin to put that Boolean algebra to good use.
The syntax goes like this:

if (condition)
{
    // Do something when condition is true
}

Here is an example:

using System;

Console.WriteLine("Enter something: ");
var input = Console.ReadLine();
if (input == "GO")
{
    Console.WriteLine("The user entered GO!");
}
Console.WriteLine("End of the program.");

In the preceding code, input == "GO" represents the condition that evaluates to a boolean result.
When running the program, if the user enters GO (uppercase), the program will print The user entered GO!. Otherwise, it will skip that code block.
Here is a running example:

As we can see from that recording, if we enter something other than GO, the program skips the statements block.
Here is the visual representation of this program flow when the user enters GO:

Here is the visual representation of this program flow when the user enters NOT GO:

Note: in the preceding diagrams, the parts that are not executed are grayed out.

But what happens if we want something different to happen if the input is not GO while keeping this logic?

The `else` statement

The else statement must follow an if statement block (or an else if block; see below).
We can't write an else block alone.
The else statements block is a fallback statements block that is executed when the if condition is evaluated to false.

The syntax goes like this:

if (condition)
{
    // Do something when condition is true
}
else
{
    // Do something when condition is false
}

In the following example, we put that to good use and display Console.WriteLine("The user did not enter GO!"); when the input is different than "GO".
We could write this with two if statements or an if followed by an else statement.
Let's start by the first option:

using System;

Console.WriteLine("Enter something: ");
var input = Console.ReadLine();
if (input == "GO")
{
    Console.WriteLine("The user entered GO!");
}
if (input != "GO")
{
    Console.WriteLine("The user did not enter GO!");
}
Console.WriteLine("End of the program.");

In this case, the preceding code would do the trick.
However, we can remove that second comparison input != "GO" by leveraging the else statement instead.
This will a) remove that comparison (slightly improve performance) and b) make our program more maintainable by removing the duplicated logic.
The alternative looks like the following:

using System;

Console.WriteLine("Enter something: ");
var input = Console.ReadLine();
if (input == "GO")
{
    Console.WriteLine("The user entered GO!");
}
else // Only this line changed
{
    Console.WriteLine("The user did not enter GO!");
}
Console.WriteLine("End of the program.");

Running any of those two programs results in the following execution flow:

And there we go; we can now use the if and the if-else statements to control the program's execution flow.
With them, we can execute only certain statement blocks based on runtime values, like values entered by the user.

Here is the visual representation of this program flow when the user enters GO:

Here is the visual representation of this program flow when the user enters NOT GO:

Note: in the preceding diagrams, the parts that are not executed are grayed out.

Ok, but what happens when we want to write a different message if the user enters SHOW ME?

The `else if` statement

The else if statement is a follow-up if statement if you wish.
As we saw in the preceding section, we can have two if statements back to back, but they are independent of each other.
On the other hand, the else if statement allows to add another conditional block after the if, but the condition is only be evaluated when the previous condition was evaluated to false.
We can chain as many else if statements as we need.
An else statement can optionally go last; after all else if blocks.

Here are a few examples of the syntax:

// if + else if
if (condition1)
{
    // ...
}
else if (condition2)
{
    // ...
}

// if + else if + else if
if (condition1)
{
    // ...
}
else if (condition2)
{
    // ...
}
else if (condition3)
{
    // ...
}

// if + else if + else
if (condition1)
{
    // ...
}
else if (condition2)
{
    // ...
}
else
{
    // ...
}

// if + else if + else if + else
if (condition1)
{
    // ...
}
else if (condition2)
{
    // ...
}
else if (condition3)
{
    // ...
}
else
{
    // ...
}

As mentioned, we can add as many else if blocks as needed.
Let's now apply that to our problem: we want to write a different message if the user enters SHOW ME.

We could do this only with if statements, but as you can see below, it can get complicated:

using System;

Console.WriteLine("Enter something: ");
var input = Console.ReadLine();
if (input == "GO")
{
    Console.WriteLine("The user entered GO!");
}
if (input == "SHOW ME")
{
    Console.WriteLine("The user entered SHOW ME!");
}
if (input != "GO" && input != "SHOW ME") // <--
{
    Console.WriteLine("The user did not enter GO nor SHOW ME!");
}
Console.WriteLine("End of the program.");

By looking at the preceding code, we can see that the more logic we add, the more complex the else-like block becomes (the if line marked by a <-- comment).
Here we have two conditions (input == "GO" and input == "SHOW ME") so we must make sure that both are false before executing the default block (input != "GO" && input != "SHOW ME").

Tips: I strongly advise against writing that type of code as it can get out of hand very quickly.
In this case, seeing it firsthand will allow you to identify such code.
Always aim at simplicity and readability.

Let's simplify that code using if—else if—else blocks instead:

using System;

Console.WriteLine("Enter something: ");
var input = Console.ReadLine();
if (input == "GO")
{
    Console.WriteLine("The user entered GO!");
}
else if (input == "SHOW ME")
{
    Console.WriteLine("The user entered SHOW ME!");
}
else
{
    Console.WriteLine("The user did not enter GO nor SHOW ME!");
}
Console.WriteLine("End of the program.");

We can notice two sets of changes:

Replacing the second if by an else if.
Replacing the last if by an else.

Here is a diff of those two listings, where the - lines are replaced by the + lines:

using System;

Console.WriteLine("Enter something: ");
var input = Console.ReadLine();
if (input == "GO")
{
    Console.WriteLine("The user entered GO!");
}
- if (input == "SHOW ME")
+ else if (input == "SHOW ME")
{
    Console.WriteLine("The user entered SHOW ME!");
}
- if (input != "GO" && input != "SHOW ME")
+ else
{
    Console.WriteLine("The user did not enter GO nor SHOW ME!");
}
Console.WriteLine("End of the program.");

As the preceding code block highlights, using if, else if, then else allowed us to get rid of the complex condition that negates the other two conditions.
This code is still simple, but if you think about adding more and more conditions, the last if would become very hard to maintain, error-prone, and hard to read.
Moreover, all conditions would be duplicated. Once for its own if block and negated for that last if.

Using an else statement just makes our life easier, so why not, right?
Anyway, running any of those two programs results in the following execution flow:

Now, let's explore how the code is evaluated.
Those two small sets of differences change many things in the execution flow, as demonstrated in the following image:

In the preceding image, we can notice that each condition is evaluated (on the left). In contrast, the conditions are evaluated only when the previous one was false (on the right).
This is the big difference between using if—else if—else or not.

To make it easier to understand, let's compare the steps depicting the scenario of a user typing GO (input == "GO"):

The steps of the left listing goes like this: 1. The first few lines are executed. 2. The first `if` is evaluated to `true`. 3. The program writes a line to the console. 4. The second `if` is evaluated as `false`. 5. The third `if` is evaluated as `false`. 6. The program writes a line to the console. The steps of the right listing goes like this: 1. The first few lines are executed. 2. The first `if` is evaluated to `true`. 3. The program writes a line to the console. 4. The program writes a line to the console.

In the right execution flow, only the first if is evaluated.
The program skips the evaluation of the else if statement and jumps over both the else if and else blocks.

Here is the visual representation of this program flow when the user enters GO:

Here is the visual representation of this program flow when the user enters SHOW ME:

Here is the visual representation of this program flow when the user enters NOT GO:

Note: in the preceding diagrams, the parts that are not executed are grayed out.

As you may begin to realise, if, else if, and else blocks are different ways to control the flow of execution of your programs.
Now that we explored that, it is time for you to practice.

Exercise

You must write a program that:

Asks the user to input his first name.
Asks the user to input his last name.
If the user enters your first name and last name, write Hey! that's me! to the console.
If the user enters any other name combination, write Hello, FIRST_NAME, LAST_NAME where FIRST_NAME and LAST_NAME are the names the user entered.

Here are a few optional hints in case you feel stuck:

Hint 1
If you don't remember how to ask a user for his input, have a look at How to read user inputs from a console.

Hint 2
There are multiple ways of implementing this solution.
However, an if followed by an else block should be a good start.

Hint 3
The AND operator (&&) and the equality operator (==) will allow you to combine both conditions (first name and last name) into one.
Feel free to have a look at Introduction to Boolean algebra and logical operators if you need a reminder on logical operators.

Once you are done, you can compare with My Solution below.

My Solution
Program.cs

const string MyFirstName = "Carl-Hugo";
const string MyLastName = "Marcotte";

Console.WriteLine("What is your first name? ");
var firstName = Console.ReadLine();
Console.Clear();

Console.WriteLine("What is your last name? ");
var lastName = Console.ReadLine();
Console.Clear();

if (firstName == MyFirstName && lastName == MyLastName)
{
    Console.WriteLine("Hey! that's me!");
}
else
{
    Console.WriteLine($"Hello, {firstName}, {lastName}");
}

In the preceding code, I:

Leveraged constants to make those values more obvious and easier to change (located at the top of the file). We explored constants in Introduction to C# constants.
Used if—else blocks, introduced in this article.
Composed the conditional expression using the equality operator (==) and the AND logical operator (&&), translating the English requirements to code: « If the user enters your first name and last name [...] ».
Employed string interpolation to format the output of the else block. We explored string interpolation in Introduction to string interpolation.

As you may start to notice, the more we move forward, the more LEGO® blocks we can piece together, and the more complex the application we can build.
All the pieces are simple. The craft is about assembling them correctly.
The hardest part of programming is probably to teach our brain to think computer, allowing it to translate human-described requirements to code.

Tip: don't think about the code itself; understand the human version of the problem instead, then try to fix it. This should help you.

Here is an alternative way you could have implemented the condition:

// ...
if (firstName != MyFirstName || lastName != MyLastName)
{
    Console.WriteLine($"Hello, {firstName}, {lastName}");
}
else
{
    Console.WriteLine("Hey! that's me!");
}
// ...

In the preceding code, the logic is inverted.
That condition could also have been simplified to:

// ...
if (!(firstName == MyFirstName && lastName == MyLastName))
{
    Console.WriteLine($"Hello, {firstName}, {lastName}");
}
// ...

If you are not sure how I was able to play with those conditions, we will explore that in a future article about common Boolean algebra laws.

Good job! You completed another small chapter of your programming journey.

Conclusion

In this article, we learned how to write code that gets executed only when certain conditions are met.
We learnt about the equality (==) and inequality (!=) operators.
Then we explored how to write if, else if, and else statements blocks to alter the linear flow of a program.
We also briefly covered code indentation as a standard way to improve the readability of your code.

Please leave your questions or comments below or drop me a Tweet.

Next step

It is now time to move to the next article: Using the switch selection statement to simplify conditional statements blocks which is coming soon. Stay tuned by following me on dev.to, Twitter, or other places you can find me.
You can look at my blog for more info.

Introduction to Boolean algebra and logical operators

Carl-Hugo Marcotte — Thu, 13 May 2021 16:01:18 +0000

In this article, I introduce you to Boolean algebra, a branch of algebra that evaluates the value of a condition to true or false. This is a fundamental part of programming that you can't escape, and you will use this until the end of your programmer career and maybe even beyond that point.

The article is not focusing on mathematical applications and representations but on programming. The objective is to give you the knowledge you need for the next article of the series.

This article is part of a learn programming series where you need no prior knowledge of programming. If you want to learn how to program and want to learn it using .NET/C#, this is the right place. I suggest reading the whole series in order, starting with Creating your first .NET/C# program, but that's not mandatory.

This article is the first part of a sub-series showcasing the following articles:

Introduction to Boolean algebra and logical operators (you are here)

Writing conditional code blocks with if-else selection statements

Advanced logical operators and common Boolean algebra laws

Boolean type

In C#, bool is the type that represents a boolean value. A bool can have a value of true or false. A bool is the memory representation of a bit. A bit is a base 2 digit that is either 0 or 1. The value 0 means false, and the value 1 means true.

Want to know more? The mathematic that we learn at school is base-10; a.k.a., there are 10 numbers: 0 to 9.
On the other hand, computers use base-2, or a binary numeral system, that includes only two numbers: 0 and 1.
Chances are, this is not something that you need to know right away, but I recommend learning this concept one day.
Knowing base-2 (binary), base-8 (octal), and base-16 (hexadecimal) can only help you (yes, there are more than just base-2 and base-10).

The following code shows the two possibilities, written in C#:

// Using var
var thisIsTrue = true;
var thisIsFalse = false;

// Using the type name
bool thisIsAlsoTrue = true;
bool thisIsAlsoFalse = false;

Now that we covered how to declare a variable of type bool, let's look at the basic operations of Boolean algebra.

Basic operations

There are three basic operations in boolean algebra:

Name	Known-as	C#
Conjunction	AND	`&&`
Disjunction	OR	\|\|
Negation	NOT	`!`

With AND, OR, and NOT, we can create most logical conditions that a program requires to run. Let's start by exploring the NOT logical operator.

Logical operator NOT

The NOT operator is a unary prefix operator and is different from AND and OR, which are binary operators. It prefixes a boolean value and inverts it. In C# (and many other languages), the NOT symbol is !.

More info: C# 8.0 introduced the ! as a suffix operator, a.k.a. the null-forgiving operator, which is a totally different thing.

The following table lists the two possible use of the negation operator and their outcome:

Expression (C#)	English	Result
`!true`	NOT `true`	`false`
`!false`	NOT `false`	`true`

The following code uses the preceding grid to explore the possibilities using C#, outputting the values in the console:

var value1 = true;
var value2 = false;
var value3 = !value1; // false
var value4 = !value2; // true
Console.WriteLine($"value1: {value1}");
Console.WriteLine($"value2: {value2}");
Console.WriteLine($"value3: {value3}");
Console.WriteLine($"value4: {value4}");

When running the program, we obtain the following output:

value1: True
value2: False
value3: False
value4: True

As we can observe here, the value of the value3 and value4 variables are the opposite of their negated source. This is the main takeaway here: the NOT operator, in !variable, flips the original value of variable.

One last bit: as an analogy, you could see a boolean as a light switch and the negation as the action of flipping the switch on/off.
For example, when you flip the light-switch from off (false) to on (true); on is the equivalent of not off (!false) while off is the equivalent of not on (!true).

Next, let's jump into the AND logical operator.

Conditional logical operator AND

In C#, the conditional logical AND operator is represented by &&.

Important: It is essential to double the symbol, otherwise & (single) is a binary operator (acting on bits), and it is different.

The && operator is a binary operator that acts on two operands, like result = operand1 && operand2.

Here is an example of using the && operator:

var leftOperand = true;
var rightOperand = true;
var result = leftOperand && rightOperand; // true
Console.WriteLine($"Result: {result}");

The preceding code outputs Result: True to the console.
Now that you may be wondering why true && true returns true, let's have a look at the logical table of the AND operator:

Left	Right	C#	English	Result
`true`	`true`	`true && true`	`true` AND `true`	`true`
`true`	`false`	`true && false`	`true` AND `false`	`false`
`false`	`true`	`false && true`	`false` AND `true`	`false`
`false`	`false`	`false && false`	`false` AND `false`	`false`

As you may have noticed from the preceding table, all combinations result in false except when both operands are true; that's how the AND operator works. Let's update the preceding code to cover the true && false scenario:

var leftOperand = true;
var rightOperand = false;
var result = leftOperand && rightOperand; // false
Console.WriteLine($"Result: {result}");

This updated code outputs Result: False to the console, precisely like the table predicted.

Ok, we are not done yet. Next, we look at the OR operator, which has a similar syntax but a different logical outcome.

Conditional logical operator OR

In C#, the conditional logical OR operator is represented by ||.

Important: It is essential to double the symbol, otherwise | (single) is a binary operator (acting on bits), and it is different.

The || operator, same as the && operator, is a binary operator that acts on two operands, like result = operand1 || operand2.

Here is a C# example of using the || operator:

var leftOperand = true;
var rightOperand = true;
var result = leftOperand || rightOperand; // true
Console.WriteLine($"Result: {result}");

The preceding code outputs Result: True to the console. Like the AND operator, the OR operator also has a logical table that comes with it. Let's have a look:

Left	Right	C#	English	Result
`true`	`true`	`true` \|\| `true`	`true` OR `true`	`true`
`true`	`false`	`true` \|\| `false`	`true` OR `false`	`true`
`false`	`true`	`false` \|\| `true`	`false` OR `true`	`true`
`false`	`false`	`false` \|\| `false`	`false` OR `false`	`false`

An interesting observation is how the || operator returns true whenever there is at least one operand that is equal to true. In other words, the || operator returns false only when there is no true (when both operands are false). In code, the only way to have a result of false would be the following code:

var result = false || false; // false
Console.WriteLine($"Result: {result}");

The preceding code outputs Result: False to the console.

Now that we covered the basic operators, it is time to look at the logical exclusive OR operator, which is closer to the spoken OR than the logical OR that we just learned about.

Logical exclusive OR operator (XOR)

In spoken languages, we usually use OR as an exclusive OR. For example, when we say, « do you prefer blue or green? » we expect a response about one of the two but not both. That type of OR is called the exclusive OR, also known as XOR. In C#, the XOR operator is ^.

Advanced information: the XOR operator is a compound operator, or shortcut if you which.
We can compose the equivalent of the XOR operator using basic operators like NOT, AND, and OR.
In C#, the XOR operator can be expressed as one of the following expressions: (left || right) && (!left && !right) or (left && !right) || (!left && right).
In the preceding two code snippets, the parenthesis change the priority of the operations.
The parenthesis play the same concept than in the following elementary mathematic equations (1 + 2) * 3 = 3 * 3 = 9 but 1 + 2 * 3 = 1 + 6 = 7.

Let's start by exploring the XOR logic table:

Left	Right	C#	English	Result
`true`	`true`	`true ^ true`	`true` OR `true`	`false`
`true`	`false`	`true ^ false`	`true` OR `false`	`true`
`false`	`true`	`false ^ true`	`false` OR `true`	`true`
`false`	`false`	`false ^ false`	`false` OR `false`	`false`

As you may have noticed, the XOR logic table is the same as the OR table, but the result is false when both operands are true (first row). This is what differentiates OR and XOR: the result is true if one operand is true but not both.

In code, XOR looks like this:

var leftOperand = true;
var rightOperand = false;
var result = leftOperand ^ rightOperand; // true
Console.WriteLine($"Result: {result}");

When executing the preceding code, we get Result: True as the console output because one of the operands is true but not both.

Note: based on my personal experiences, this operator is not used very often.
Nevertheless, I think it is worth knowing of its existence, for those few times.

Next, that's your turn to practice what we just covered.

Exercise

The exercise will focus on the logic part and not on the code part. We will use this knowledge in the next installment, where we will learn to write conditional code based on boolean logic. For now, try to answer the following questions without consulting the logic tables.

What is the result of:

true && true
true || true
!true && true
true || !true
true ^ true

Once you are done, compare your results with the answers below:

Answers

true
true
false
true
false

Good job! You completed another small chapter of your programming journey.

Conclusion

In this article, we explored the three basic operations of Boolean algebra: AND, OR, and NOT. Each of them has a logical table that lists the expected output based on the inputs. For example, AND returns true only when both operands are true, while OR returns false only when both operands are false.

Then we looked at the compound operator XOR (exclusive OR). That operator helps simplify certain scenarios where you want a result of true when only one of the two operands is true but not both.

This is very important and will be used in subsequent articles to learn to use boolean algebra to write conditional logic. We will also explore more complex scenarios and some laws to help you simplify your conditional logic. This was a theoretical article that we will practice in the next one of the series.

All in all, Boolean algebra is one of the bases of programming that you can't escape. Please leave a comment below if you have questions or comments.

Next step

It is now time to move to the next article: Writing conditional code blocks with if-else selection statements which is coming soon. Stay tuned by following me on dev.to, Twitter, or other places you can find me.
You can look at my blog for more info.

Escaping characters in C# strings

Carl-Hugo Marcotte — Sun, 18 Apr 2021 18:44:18 +0000

In this article, we look at escaping characters in C# strings.
But what is escaping, you may wonder?
That's how we write special characters or characters that would otherwise be impossible to include in a string, like ".

This article is part of a sub-series, starting with Introduction to string concatenation.
It is not mandatory to read all articles in order, but I strongly recommend it, especially if you are a beginner.
If you are already reading the whole series in order, please discard this word of advice.

Escaping characters

As mentioned in the introduction, the action of escaping characters means you write an "escape sequence" to represent specific characters.
An escape sequence starts with a \. It is followed by a character or a series of numbers representing the Unicode character code.

Here are a few examples:

using System;

var quotes = "Wrap \"a few words\" with quotes.";
var newLine = "Add a\nnew line.";
var tab = "\tAdd a tab at the begining of the string.";
var e = "This is the letter e: \u0065";

Console.WriteLine(quotes);
Console.WriteLine(newLine);
Console.WriteLine(tab);
Console.WriteLine(e);

When we run the previous code, we obtain the following result:

If we take a closer look:

We can write \" to insert a " character inside a string, which would be impossible otherwise.
We can use the special \n to insert a new line (see below for more special characters).
We can use the special \t to insert a horizontal tab (see below for more special characters).
We can use the Unicode representation of a character, prefixed by \u, to insert that character into a string (UTF-16 or UTF-32).

In my opinion, the most helpful special characters are:

Escape sequence	Character name	Example
`\'`	Single quote	Not related to `string` but to `char`, like `var q = '\'';` (not covered yet).
`\"`	Double quote	See preceding example.
`\\`	Backslash	`var s = "c:\\folder\\some-file.ext";`
`\n`	New line	See preceding example.
`\r`	Carriage return	Read the OS specific line break section
`\t`	Horizontal tab	See preceding example.
`\u0000`	Unicode escape sequence (UTF-16)	To write the character `e`: `\u0065`
`\U00000000`	Unicode escape sequence (UTF-32)	To write the character `e`: `\U00000065`
`\x0[0][0][0]`	Unicode escape sequence (UTF-16) with variable length	To write the character `e`: `\x65`

See String Escape Sequences for some more characters.

Next, we explore line break.

Platforms-specific line break

In case you did not know, Windows line breaks are different from Unix-based platforms.
Windows uses a sequence of both carriage return and new line (\r\n) while Unix uses only a new line (\n).
Windows is pretty forgiving and will most likely understand \n.
Nevertheless, in a cross-platform app targeting both Windows and Unix (e.g., Linux and Mac), do you really want to leave line breaks to chance?
To save the day, we can use the Environment.NewLine property instead, which adapts to the current OS.

Here is an example (same output as the newLine variable of the preceding example):

using System;
Console.WriteLine($"Add a{Environment.NewLine}new line."); // We leveraged interpolation here

If we have many line breaks, this can become tedious.
Hopefully, we can simplify this by leveraging the string.Format method we cover next.

string.Format

We can use the string.Format method to format a string.
It is similar to interpolation, but instead of inserting the variables directly, we need to define numerical tokens, like {0}, {1}, {2}, and so forth.
Then, we pass arguments that match those tokens in the correct order to get the final result.

Many other .NET methods allow such a construct, including Console.WriteLine.
Here is an example of both string.Format and Console.WriteLine:

using System;
var newLine = string.Format("Add a{0}new line.", Environment.NewLine);
Console.WriteLine(newLine);
Console.WriteLine("Add a{0}new line.", Environment.NewLine);

When running the code, both Console.WriteLine output the same result.
The advantage here is writing {0} every time we need a line break.
Of course, we could use interpolation with {Environment.NewLine} directly, but it makes the string longer.
Even worst, we could use concatenation like "Add a" + Environment.NewLine + "new line."; I find this to be the hardest code to read, making the string even longer.

But how does that work?
In the background, the framework replaces the numerical tokens with the specified arguments.

There are more to string.Format, including the possibility to format your values, but that's getting more and more out of the scope of our main subject.
Next, we look at escaping characters in interpolated strings.

Interpolation-specific escaping

In an interpolated string, we use the characters { and } to wrap the element to insert, like a variable.
What if we want to write those characters?
It is as easy as doubling them.
For {, we write {{.
For }, we write }}.

Here is an example:

var name = "Darth Vader";
var greetings = $"{{Hello {name}}}";
Console.WriteLine(greetings);

As simple as that, the preceding code will output {Hello Darth Vader}.
Next, let's have a look at the verbatim identifier (a.k.a. multiline strings).

The verbatim identifier

The verbatim identifier (@) allows us to write multiline strings, but it's not all.
It also disables the escaping of characters, which can be very handy when writing file paths (amongst other things).
In other words, a backslash is just a backslash, not a special character that starts an escape sequence.
For example, it is more convenient to write var path = @"c:\folder\some-file.ext"; than var path = "c:\\folder\\some-file.ext"; (simple vs double backslash).

Since \[character] does not work, how can we escape "?
Like with interpolation, we only have to double it, like var v = @"Some ""quoted words"" here.";

The verbatim identifier can also be used to escape reserved keywords, like if, for, public, etc.
For example, if you'd like to create a variable named public, you can't write var public = "some value"; because this won't compile.
However, you could prefix your variable name with @ to make it work, like this: var @public = "some value";.
Using this makes your code a little harder to read, but that's a trick that can come in very handy sometimes.

More info: one place where it was handy was to create class attributes in an old ASP.NET MVC version because class is a reserved keyword: we had to escape it using the verbatim identifier.

Reference: if you want to know more about reserved keywords, please visit the C# Keywords page in the official documentation.

Next, it's your turn to try it out.

Exercise

In this exercise, you will write a program that writes code.

Unfortunately, I was not able to recreate the exercise on this platform, so please look at the exercise on the original post on my blog. I'm sorry for the inconvenience.

Conclusion

In this article, we explored the string type a little more.
We discovered that the backslash character (\) is used to escape characters or to create special characters like tabs (\t) and line breaks (\r and \n).
We then learned about the Environment.NewLine property that gives us the correct platforms-specific line break.
We also peaked at string.Format to format strings using numerical tokens instead of interpolation.

Afterward, we explored some edge cases to escape { and } in interpolated strings and " in multiline strings.
The solution was to double the characters; a.k.a. write "" to obtain ".
We saw that in @"..." strings, the escape character (\) does not work, which is an advantage that can become a disadvantage.
We finally learned to use the verbatim identifier (@) to bypass the reserved keywords limitation and use it as an escape character for identifiers.

All in all, that's a lot of new content that concludes our introduction to strings mini-sub-series.

Next step

It is now time to move to the next article: Introduction to boolean algebra which is coming soon. Stay tuned by following me on dev.to, Twitter, or other places you can find me.
You can look at my blog contact page for more info.

Introduction to string interpolation

Carl-Hugo Marcotte — Sun, 28 Mar 2021 14:57:20 +0000

In this article, we continue to explore string manipulations by focusing on interpolation.
Instead of concatenating many pieces together, interpolation allows us to insert special tokens inside a string.
A value then replaces those tokens.
Interpolation and concatenation play the same role, but often one ends up being more elegant than the other and makes the code easier to maintain.

This article is part of a sub-series, starting with Introduction to string concatenation.
It is not mandatory to read all articles in order, but I strongly recommend it, especially if you are a beginner.
If you are already reading the whole series in order, please discard this word of advice.

Interpolation

The definition of interpolation, from Oxford Languages (Google search), is:

The insertion of something of a different nature into something else.

In C#, we must prefix the string with the $ character if we want to use interpolation.
Then, we can insert the value of an expression in that string by wrapping it with { and }, like this:

var name = "Joe";
var result = $"Hello {name}!";
Console.WriteLine(result);

Executing the preceding code should write Hello Joe! in the terminal.
I find $"Hello {name}!" to be more elegant than "Hello " + name + "!" and way easier to read, especially for a neophyte.

Next, we explore how to use interpolation in a multiline string.

Multiline string interpolation

If you wondered why I talked about multiline strings in the previous article, I planned this section.
We can use both $ and @ to mix interpolation and multiline string, like this:

var name = "Joe";
var result = $@"Hello {name}!
What's up?";
Console.WriteLine(result);

In the preceding code, we used interpolation in a multiline string by chaining both $ and @ (in this order).
As easy as that!

Note: the order is important. If you inverse the symbols order (@$"..." instead of $@"..."), the code will not compile.

Next, it is your turn to try it out!

Exercise

To practice interpolation, we will replace concatenation with interpolation in the code from the previous article's exercise.

Here is the previous solution as a reference:

using System;

Console.Title = "IntroToDotNet";

Console.Write("What is your first name? ");
var firstName = Console.ReadLine();
Console.Clear();

Console.Write("What is your last name? ");
var lastName = Console.ReadLine();
Console.Clear();

var greetings = "Greetings " + firstName + " " + lastName + "!";
Console.WriteLine(greetings);

Unfortunately, I was not able to recreate the exercise on this platform, so please look at the exercise on the original post on my blog. I'm sorry for the inconvenience.

Conclusion

In this article, we explored interpolation as a way to replace concatenation in certain scenarios.
At this point, using one or the other is only a matter of taste.

To use interpolation, we need to prefix a string with $.
Inside that string, we can then wrap an expression, like a variable, with { and }.
The program will replace that token at runtime with the expression's value.

We also saw that we could use interpolation with multiline strings by prefixing the string with both special characters, like this: $@"...".

Next step

It is now time to move to the next article: Escaping characters in C# strings which is coming soon. Stay tuned by following me on dev.to, Twitter, or other places you can find me.
You can look at my blog contact page for more info.

Introduction to string concatenation

Carl-Hugo Marcotte — Fri, 26 Mar 2021 02:07:41 +0000

In this article, we dig a little more into the string type.
We also explore how to concatenate (combine) strings.
As a programmer, you will often need to manipulate strings, concatenation and interpolation being two recurring themes.
We will cover interpolation in the next installment.

This article is part of a learn programming series where you need no prior knowledge of programming. If you want to learn how to program and want to learn it using .NET/C#, this is the right place. I suggest reading the whole series in order, starting with Creating your first .NET/C# program, but that's not mandatory.

Strings

In C#, a string is a sequence of characters delimited by quotes (").
We used strings in previous articles to write text to the console.

As a reminder, here is how to create a string variable:

var name = "Superman";

We already used strings, so no need to linger too long here.
Next, we explore some new content: multiline strings.

Multiline strings

In C#, we can create multiline strings by prefixing the string with the @ character.
As the name implies, the only difference is the possibility to set the content of the string over multiple lines.

Here is an example of a multiline string:

var name = @"This
is
a
multiline
string!";
// More code here...

But keep an eye open for details.
For example, in the following code, the first and last characters are a new line, which may not be what you expected to write.

var name = @"
This
is
a
multiline
string!
";
// More code here...

Multiline strings are handy in different scenarios where you don't want to use concatenation.
As an introduction to strings, I will not get into too many more details.
However, there are many methods to manipulate strings, compare them, or optimize their usage.

Next, we look into the main subject: concatenation.

Concatenation

Concatenation is the action of piecing multiple strings together to make a new one; combining strings if you wish.
In C#, the concatenation operator is the + symbol.
The + operator combines both string operands (the values on the left and right sides) into a new string.
Let's look into an example to make learning easier:

var concatenatedString = "Greetings " + "from .NET!";
Console.WriteLine(concatenatedString);

The preceding code combines the strings "Greetings " and "from .NET!" into "Greetings from .NET!".

Note the space after the word Greetings. Without it, the combined string would have been "Greetingsfrom .NET!".

Another way to do it, which is more likely to happen than what we just did, is assigning a value to a variable and then updating that value.
Here is an example of that:

var concatenatedString = "Greetings ";
concatenatedString = concatenatedString + "from .NET!";
Console.WriteLine(concatenatedString);

The preceding code does the same as "Greetings " + "from .NET!", but in two steps (bullets 1 and 2):

The value "Greetings " is assigned to the concatenatedString variable.
The value "from .NET!" is added at the end of the concatenatedString variable, then reassigned to it.
The program writes "Greetings from .NET!" to the console.

Let's look more into the line concatenatedString = concatenatedString + "from .NET!"; as it may be harder to understand at first.

Reminder: the assignation operator (=) has the lowest priority, so the code on the right (the right-hand operand) is processed first.

Here is an image to help analyze the code:

The program ready the literal string "Greetings " for step 2.
The program assigns the value of the right-hand operand ("Greetings ") to the concatenatedString variable.
The program ready the current value of the concatenatedString variable for step 5 ("Greetings ").
The program ready the literal string "from .NET!" for step 5.
The program concatenates (combines) the two strings into a new one.
The program assigns the value of the right-hand operand ("Greetings from .NET!") to the concatenatedString variable, replacing its value.

Note: You can see steps 3 to 5 as evaluated first, like one big step, then the program continues at step 6.

Now that we covered that, there is a shortcut to this process: the += operator.
You can see the += operator as a combination of both concatenation (+) and assignation (=).
The previous example, using the += operator, would look like this:

var concatenatedString = "Greetings ";
concatenatedString += "from .NET!";
Console.WriteLine(concatenatedString);

The second line of code is simplified compared to the previous bloc.
It does the same, without the need to specify that concatenatedString = concatenatedString + [something else].
This new syntax removes unneeded pieces, reducing the length of the line of code, most likely even making it easier to read.

Enough theory; next, it's your turn to try it out.

Exercise

To practice concatenation, we will update the code from the previous article's exercise, but with a twist.

Unfortunately, I was not able to recreate the exercise on this platform, so please look at the exercise on the original post on my blog. I'm sorry for the inconvenience.

Conclusion

In this article, we learned that we could write multiline strings if we need to.
We also learned about concatenation, which combines multiple strings into a new one.
The concatenation operator is the symbol +.
We also look at the += operator. += allows us to combine both the concatenation and assignation operators. Using it can simplify our code and remove a step.
In programs, concatenation is often used, which makes it an essential piece of knowledge to have.

Next step

It is now time to move to the next article: Introduction to string interpolation which is coming soon. Stay tuned by following me on dev.to, Twitter, or other places you can find me.
You can look at my blog contact page for more info.

How to read user inputs from a console

Carl-Hugo Marcotte — Sun, 14 Mar 2021 15:40:22 +0000

In this article, we explore how to read user inputs from the console.
This article is the foundation of more dynamic notions enabling our programs to change based on user interactions and react to them.
We also learn how to change the title of the console and how to delete its content.

User input

So far, we used the Console.Write and Console.WriteLine methods to write to the console.
We also created variables and constants to hold and reuse some text.
However, we don't know how to interact with the user yet.

There are multiple types of applications, like web apps, mobile apps, and Windows apps.
In our case, we will continue to use console applications because they are the simplest.
We don't need to bother with complex user interfaces, animation, or interaction, and we can focus on learning to program.

Console apps may feel less exciting, but that allows us to focus on only one subject at a time.
Remember that every piece of knowledge that you are acquiring is like a new LEGO^® block that you'll be able to piece with the others later.
Moreover, what you are learning in this series is reusable in most, if not all, other types of apps.

The Console class offers three methods to read user inputs, Read, ReadKey, and ReadLine.
We can use the first two for more complex scenarios.
The third one is very straightforward and is the method we are focusing on in this article.

As its name implies, Console.ReadLine reads the line entered by the user.
It is simple and gives us the power to accomplish what we need, to learn the basic programming concepts.

Reading a line entered by a user

The Console.ReadLine method returns a string, representing the line written in the console by the user.
Here is an example:

using System;

Console.Write("Please enter a greeting message, then press ENTER: ");
var hello = Console.ReadLine();
Console.WriteLine(hello);

In the preceding code, we write a message to the user, then wait for an input.
The program will block its execution there until the user hits the <ENTER> key.
At this point, it will resume and continue, then write the read line back to the console.

Here is the console content when running the program and entering Hello Amigo!<ENTER>:

Please enter a greeting message, then press ENTER: Hello Amigo!
Hello Amigo!

More info: it is important to note that the new line character (the <ENTER>) is not part of the line (not saved in the hello variable).

Now that we saw an example, let's explore the flow of execution of the program.

Flow of execution

The program flow, or flow of execution, represents the order in which the program executes the instructions (lines of code).
In our case, the code is linear; it starts at the top and ends at the bottom of the Program.cs file.
Nevertheless, the Console.ReadLine() method blocks the program, waiting for a user input, which disturbs the flow.

Here is what happens:

The program writes the question to the console.
The program executes the right-end of the assignation operator (=), the Console.ReadLine() method, which waits for the user to hit the <ENTER> key. > More info: The assignation operator = is always the last to be executed; it has the lowest priority.
The user types Hello Amigo! then hit <ENTER>.
The program then resumes and assigns the user-entered value to the hello variable.
The program writes that input back to the console.

Here is a second way to visualize this flow:

In this case, the Console.ReadLine() method manages the bifurcation even if code-wise, the flow is linear.

Note: We will learn ways to control a program's flow in future articles.

Next, it is your turn to try this out.

Exercise

To practice all that we explored so far, including user-inputs, you must write a program that asks the following two questions to the user:

What is your first name?
What is your last name?

Then, the program must greet that user using the following format: Greetings {first name} {last name}!.

Example: Assuming the user entered Carl-Hugo as the first name and Marcotte as the last name, the greeting message would read Greetings Carl-Hugo Marcotte!.

Unfortunately, I was not able to recreate the whole exercise on this platform, so please look at the exercise on the original post on my blog. I'm sorry for the inconvenience.

Bonus information

In this short section, we explore two more manipulations of the console:

How to set its title.
How to clear what is written in it.

The block of code at the end of this section contains the preceding exercise's solution; please be advised.

Setting a custom console title

If you want to change the console title, you can set the Console.Title property to the string of your choice, like this:

Console.Title = "IntroToDotNet";

Pretty straightforward, isn't it?
Next, let's see how to clear the text from the console.

Clearing the console

One last bit of knowledge here: we can clear the console using the Console.Clear() method.
So instead of the following output:

What is your first name? Carl-Hugo
What is your last name? Marcotte
Greetings Carl-Hugo Marcotte!

We could clear the console between each question to obtain the following flow:

Here is the code to achieve that result:

Program.cs

using System;

Console.Title = "IntroToDotNet"; // Custom title

Console.Write("What is your first name? ");
var firstName = Console.ReadLine();
Console.Clear(); // Clear after the first question

Console.Write("What is your last name? ");
var lastName = Console.ReadLine();
Console.Clear(); // Clear after the second question

Console.Write("Greetings ");
Console.Write(firstName);
Console.Write(" ");
Console.Write(lastName);
Console.WriteLine("!");

And that's it for this article.

Conclusion

In this article, we explored how to read user inputs from the console.
We used the ReadLine method to acquire the value a user wrote before hitting the <ENTER> key.
Interacting with the user is the foundation of the next many articles where we will use this to acquire and manipulate data typed by the user.

We also looked at how to change the title of the terminal Window because why not, right?
Finally, we explored how to clear the text to reset the console to an empty state.
This second interlude can be very handy at crafting a better user experience (UX).

Next step

It is now time to move to the next article: Introduction to string concatenation and interpolation which is coming soon. Stay tuned by following me on dev.to, Twitter, or other places you can find me.
You can look at my blog contact page for more info.

Introduction to C# comments

Carl-Hugo Marcotte — Sun, 07 Mar 2021 16:19:31 +0000

In this article, we explore how to write comments.
Comments are simply human-readable pieces of text that are not compiled nor interpreted.
A comment is usually a note that we can leave in the code for the next programmer to get into that code or for us.
I left a few comments in preceding installments; did you noticed them?

Comments

There are three types of comments in C#:

Single-line
Multiline
XML documentation comments, also known as triple-slash comments.

In this article, we will only explore the first two.
We can use the third style to document our code, but we don't know how to create such code; yet.

We can use comments to leave notes in the source code.
As a beginner, comments can be handy.
The more you progress, the clearer your code will become and the less needed the comments are gonna be.

More info: I usually recommend to intermediate developers to write as close to zero comments as possible in their code.
Comments too often become outdated and forgotten.

For example, the code change, but the comment remain the same.
In that case, the comment describes the first version of the code, but the second version does something else.
This is the kind of situation that can lead a third developer in the wrong direction.
Both the code and the comment can contradict themselves.

On the other hand, comments can be useful to lay out ideas and algorithms, especially as a beginner.
They can also be an excellent tool to reorganize logic into cohesive units.
We can also use comments to diagnose and debug a feature.
Enough of that; I'll most likely talk about that in future articles, in a more exciting context.

Next, let's have a look at the first style that we are covering in this article.

Single-line comments

We can write a single-line comment by writing //.
Everything that is written afterward, on the same line, becomes a comment that does nothing.

Here are some examples:

const string tmp = "SOME TEXT"; // This is a comment that could describe this statement

// This is a comment that could describe the following code block
Console.WriteLine("=====================");
Console.Write("===== ");
Console.Write(tmp);
Console.WriteLine(" =====");
Console.WriteLine("=====================");

If we run the code, we get the following output:

=====================
===== SOME TEXT =====
=====================

As you can see, the comments are not executed or outputted. They are there only to inform the programmer about the code.

Next, let's look at multiline comments.

Multiline comments

Multiline comments are like their name implies: they can cover multiple lines.
Unlike single-line comments, multiline comments have an opening and a closing sequence of characters.
Everything in between those two tokens is a comment.
We can open a multiline comment with /* and close it with */ (same characters in the inverted order).

Hint: The numpad of a standard keyboard makes it very easy to open and close a multiline comment in a smooth sequence of keystrokes: / -> * -> * -> / -> move your arrow between the two *, hit enter or write your comment.

Here are a few examples:

/* This is a multiline comment, but only on one line; please don't do what I did with the following line in your code, it is just an example. */
const/* This */string/* can */tmp/* be */=/* almost */"SOME TEXT"/* anywhere, */;/* as long as you don't break any token */
//
// We can also use single-line comments; one does not block the usage of the other.
//
Console.WriteLine("=====================");
/*
We can also
use multiline
comments to
write longer
sequence of
text divided
onto multiple
lines.
*/
Console.Write("===== ");
Console.Write(tmp);
Console.WriteLine(" =====");
Console.WriteLine("=====================");

If we run the code, we get the following output:

=====================
===== SOME TEXT =====
=====================

Once again, the comments are not executed or outputted. They are there only to inform the programmer about the code.
Moreover, as you may have noticed, multiline comments don't have to cover multiple lines.
Unlike the single-line comments that start from //, commenting the text until the end of that line, we can use multiline comments to comment out only a part of a line.

And voilà! You have made another step toward learning to program.

Conclusion

Comments are a tool to annotate and leave notes inside the code.
We can write single-line comments beginning with //, and we can write multiline comments between /* and */.

One essential thing to understand about comments is to use them to describe the functionally, not the code itself.
For example, explaining to a C# programmer using a comment that var text = "whatever"; creates a variable named text is not helpful.
But explaining that the following block of code is an implementation of the XYZ algorithm could be.
As I mentioned, at some point, you want to aim at writing clear enough code that you don't need to explain it.
That said, as a beginner, please leverage comments to help you out.
You can describe your code if that helps you remember or understand for example.
Everyone learns differently.
There is no wrong with how to learn, so if using comments helps you, please do!
If you don't know, experiment with techniques and keep what works best for you, only you can find this part out.

Next step

It is now time to move to the next article: Introduction to user inputs which is coming soon. Stay tuned by following me on dev.to, Twitter, or other places you can find me.
You can look at my blog contact page for more info.

Introduction to C# constants

Carl-Hugo Marcotte — Sun, 28 Feb 2021 14:01:21 +0000

In this article, we explore constants.
A constant is a special kind of variable.
The kind that does not vary; they are immutable.

Immutable means that it cannot change.

Definition of a constant

Besides knowing that a constant's value cannot change, its value is replaced at compile-time.

On the contrary, variables are evaluated at runtime. Therefore, the program uses the value they hold at the time of their usage during the execution.

To define a constant, we use the const modifier in front of its type, followed by an identifier, an assignment operator, then its value; like this:

const string greetings = "Hello .NET Ninja!";
const int age = 102;

Note: we can't use the var keyword for constants.

Let's look at two use-cases, one using a variable and one using a constant.

Variable flow

In the following code, the value of the greetings variable is transferred to the WriteLine method. It is then written to the console at runtime.

var greetings = "Hello .NET Ninja!";
Console.WriteLine(greetings);

So if we change the value of the variable along the way, the output will be different; like this:

var greetings = "Hello .NET Ninja!";
Console.WriteLine(greetings);
greetings = "This is new!"
Console.WriteLine(greetings);

When executing the preceding code, the program will write two lines to the console, Hello .NET Ninja! and This is new!.
That's because the evaluation is done at runtime.

Next, we look at constants.

Constant flow

In the case of a constant, its value is replaced at compile-time.
Let's take the following code as an example:

const string greetings = "Hello .NET Ninja!";
Console.WriteLine(greetings);

During the compilation phase, the compiler replaces the identifier of the constant by its value.
In our case, we end up with the following code:

Console.WriteLine("Hello .NET Ninja!");

When executing the program, the result is the same as if we wrote the preceding code ourselves.
The only difference is that the compiler did the job of replacing the value for us.

Next, we look at what we can do with this.

What to do with constants?

As a neophyte, this may sound useless, but as your level of knowledge grows, it becomes more relevant.
In general, constants are used to make your program easier to maintain.
Here are a few examples:

Case 1: you do not want hard-coded values spread throughout your program.
Doing so makes the program harder to maintain when you need to change one of those hard-coded values.
You can also make a typo when typing the value manually.
For example, you need to find the values, make sure you don't forget any, replace them, etc., leading to more risks of making a mistake in the process.
To fix that issue, you can use constants to centralize all of those values in one place, making the program easier to maintain without impact on runtime performance because the constants are replaced at compile-time.

Case 2: you want to reuse a specific value at multiple places in the code as a way to identify something (an identifier, a key, an index, a URL).
Instead of duplicating that literal value, you can use a constant, which removes the duplication by depending only on the constant.
If you need to change the value, you can update the constant, recompile, and voilà; all references to that constant now use the new updated value.

More info: There is a downside to constants, which can happen in a more advanced scenario.
When creating a project⁽¹⁾ that depends on a constant from another project⁽²⁾, if the author of project⁽²⁾ changes the value of a constant that project⁽¹⁾ depends on, project⁽¹⁾ needs to be recompiled for the change to be applied.
This could, on rare occasions, have unintended consequences, where different values are used, leading to inconsistent states.

Feel free to return to this note later as it is for more advanced scenarios.
Maybe some or all of this makes no sense to you yet, which is normal.
I decided to leave the note anyway because it is constant-related and important to know.

Exercise

Unfortunately, I was not able to recreate the exercise on this platform, so please look at the exercise on the original post on my blog. I'm sorry for the inconvenience.

Conclusion

In this article, we learned the constants' syntax.
We covered how to create a constant and how to assign it a value.
Like declaring a variable using the var keyword, we must assign it a value when declaring it.
We cannot use the var keyword for constant and must specify its type instead.
Unlike variables, once the constant is declared, we cannot change its value.

The value of a constant is evaluated and replaced at compile-time, making it a great candidate to improve maintainability while keeping performance the same.
As a reference, variables are evaluated at runtime.

Next step

It is now time to move to the next article: Introduction to C# comments which is coming soon. Stay tuned by following me on dev.to, Twitter, or other places you can find me. You can look at my blog contact page for more info.

Forem: Carl-Hugo Marcotte

Architecting ASP.NET Core Applications—Unveiling the Third Edition

Backend Design Like You've Never Seen Before

What is a Modular Monolith?

What's new in the third edition?

What is Microservices Architecture?

Your ASP.NET Core Development Companion

Embrace The Journey of Backend Mastery

Definition of terms and acronyms

Implementing Microservices Architectures

What are microservices?

Cohesive unit of business

Ownership of data

Microservice independence

An introduction to event-driven architecture

Domain events

Integration events

Application events

Enterprise events

Conclusion

Summary

Boolean algebra laws with C#

Absorption Law

Annulment Law

Associative Law

Complement Law

Commutative Law

Consensus Law

De Morgan's laws

Distributive Law

Double negation law

Identity Law

Idempotent Law

Redundancy Law

Conclusion

Next step

Using the switch selection statement to simplify conditional statements blocks

The Switch

Flow of the program

Exercise

Conclusion

Next step

Using if-else selection statements to write conditional code blocks

Conditional execution flow

Equality operators

Equality operator ==

Inequality operator !=

if-else selection statements

Statements block

Indentation

The if statement

The else statement

The else if statement

Exercise

Conclusion

Next step

Introduction to Boolean algebra and logical operators

Boolean type

Basic operations

Logical operator NOT

Conditional logical operator AND

Conditional logical operator OR

Logical exclusive OR operator (XOR)

Exercise

Conclusion

Next step

Escaping characters in C# strings

Escaping characters

Platforms-specific line break

string.Format

Interpolation-specific escaping

The verbatim identifier

Exercise

Conclusion

Next step

Introduction to string interpolation

Interpolation

Multiline string interpolation

Exercise

Conclusion

The `if` statement

The `else` statement

The `else if` statement