My first C# program

Console output

Introduction to variables and int type

String type introduction

Brave new world

Computer hardware introduction

C# naming convention

Comments in C#

C# problems practice

The Mission

C# program structure

If statement

Visual Studio extension

Back to the streets

Bool type introduction

Console readline

Who is who

C# compilation process

Introduction to for loop

Find the basement

Introduction to double type

Introduction to char type

Talk in the big kitchen

Introduction to while loop

Introduction to methods

Repairing Noname

Introduction to arrays in C#

Lists

Introduction to scopes

Victory is close

Constants in C#

Wonderland

Input validation

Modulo operation

Career raise opportunity

Type conversion

Passing parameters to functions

Infinity

Switch statement

C# test

The truth

Programming 1 - C#

"Join CodeEasy's Programming 1 - C# course and master the fundamentals of C#. Perfect for beginners, this course offers interactive lessons and hands-on coding practice."

Programming 1 - C# Course | Learn C# Fundamentals with CodeEasy

I found myself with a little free time in between Ritchie's lectures and managed to sneak back down to the basement to see how Noname was doing. 
It turned out that Noname had been busy at the time I'd been gone! Four of his eight displays were on and showing command prompts, each with a continuous cascade of code and commands flying down the screen. The entire basement even looked brighter maybe Noname had revived enough processing power to use some for nonessential purposes. This was definitely 

 the dying machine that I found here a month ago.

"Hi, Teo! This is the first time you've come to see me without me calling for you. Nice to see you!" 
"You look great, Noname! Are you up to full speed now?" I replied. 
"Yes... and no. I've repaired all of my internal modules, but there's still some work to do. Now I need an input validation system; otherwise, if I expect an 

I had never heard of a validation system, but Noname's explanation made perfect sense. I was actually a little surprised that I had never thought to question what 

 happen if the user entered a type that my code wasn't expecting. In all my programs thus far, I had assumed that when I asked for an integer, the user would input an integer. But what if the user input the wrong type, either by mistake or intentionally? Feeling sheepish that I'd overlooked something so important, I said goodbye to Noname and went to seek out Ritchie for an immediate lesson.

When I asked Ritchie to show me how to prevent a user from inputting the wrong data, his answer was in typical Ritchie fashion. 
"Impossible." Ritchie said. "You can't prevent a user from doing anything because a user controls their own hardware." 
"Hardware?" I said, "I was talking about coding. What do you mean?" 
"Exactly what I said, Teo. If a user has physical access to the computer, you can't prevent her from doing anything. She can open the computer directly and access all of the inner parts like memory, processor, anything! I know you asked about coding, but you need to understand that good and even bad hackers will find a way to bypass any protection you put in your program."

"So you're saying that there's nothing I can do to keep a user from misusing my programs?" I asked. 
A grin appeared on Ritchie's face. "No, no," he said, "I'm just messing with you. I need to know that I can still fool you every now and then! There is a way to secure your program a bit, but remember, hackers will still break it if they want. The typical user, not so much."

Like I said, typical Ritchie. As with so many odd things I had heard from Ritchie, I hoped he 

 actually joking, but I was pretty sure that he wasn't. "Ha, okay." I replied, trying to keep the agitation out of my voice. "Tell me how to secure my program, Ritchie."

" Ritchie said. "Listen carefully, this is very important. 

The user can input the wrong data, however, and whenever, she wants.

 ?" I asked. 
"Those are just two possibilities, along with a host of others: an image instead of a video, a short password instead of a long one, a date in a month that is bigger than 31, or even a negative number of daughters. Your basic strategy to counter this is to 

continuously ask a user to input valid data until he does it

Let's start with a simple example. Here's a program that reads the user's name."

"But what if the user just pressed Enter without typing anything?" Ritchie continued. "The string 

 would be empty. In this next code, we'll add a check to see if the user actually entered a string, and if not, we'll ask for the name again."

is empty. Try to use it in a similar way just now," Ritchie said and turned the screen of his computer in my direction, pointing to the keyboard.

"Looks simple, Ritchie," I said, "but almost too simple. What happens if the user inputs an empty string 

 ?" 
"Good catch Teo! I did that to get you thinking. That's why 

you need to check for a valid entry at each iteration and keep asking the user to put in a valid entry 

 until you get the type you're looking for!

In this final version, we'll add a while loop to ask for a name until a valid entry is given." 

"Aha, that's the piece that was missing." I said. "The while loop does exactly what we're looking for here!" 
"Exactly right Teo. As you continue learning, never forget your earlier lessons. Even simple concepts like a loop can be used as a building block for more complex code. Now, let's have you practice some validation on your own."

"Got it, Ritchie. What about preventing a more complicated problem, like expecting an int and getting a string? Say I ask for an int, and a user gives me 'Banana'?" 
"To detect an error while you are parsing an int, you can use the 

 that you want to convert (or parse) to an 

 keyword in our example means that the result of this method will be written to the second method parameter which we called 

. The output of the method is a bool value that indicates whether it was possible to parse the input as an 

 to show you a specific output type. Here's a shortened version:"

"Do you follow, Teo?" Ritchie asked. 
"Can we revisit the 

means that the value of the variable that it introduces will be changed inside the method. Actually, out 

 that the value of this variable will be changed.

In the example above, if int.TryParse(someString, out result) returns true, the function will return a value in the result variable." 

"Ok, I understand that part," I said. "And do I really need to use 

?" 
"Well, it depends on what you are writing," Ritchie replied. "If it's a sample application just for training, you can use 

 to make the code shorter. If you write real production code that may be run somewhere that you have no control over, consider using 

 to check for input errors, or try to catch exceptions from 

Of course, more new terms. "And what is an exception?" I asked. 
"We'll go over that later," Ritchie said. "For now, just remember: 

if otherwise specified, you can use any of the methods that you want. If a task's conditions require you to check different user inputs, use 

Here's an example that iterates until the user inputs a number as an age:" 

, and others. They all work the same as the int version, just with different types:

Discover how to perform validation in C Sharp applications to prevent a user from inputting wrong data at our interactive tutorial.

6 / 6