New Life

That same evening Ritchie explained the situation. Everyone in the resistance camp works for him. The primary currency is viruses. To pay for my keep, I need to perform tasks that Ritchie gives me. Unfortunately, this is what life in the future has boiled down to.

He let on that no one actually believes that the machines can be stopped. Those who have joined the resistance are resigned to simply surviving. Every now and then, the machines hunt and capture members of the resistance, and that's why Ritchie needs to import people from the past to now, year 2113.

Richie was watching me intently and could tell by the look on my face when I was ready to learn more about my situation. "I know you're new here and a lot of this is probably a shock to your system. Before you're ready to go on missions, you'll need to start with the basics and work your way up from there. Go and meet Sara - she'll teach you how to structure C#."
Preferring having something to do over standing on the outskirts of camp with a Will Work for Food sign, I set off toward my new assignment.

The Structure

I met Sara in her room on the second floor of the resistance headquarters building (if you can still call a concrete husk with nearly as many holes as not a 'building').
"Hi Teo, I'm Sara. Let's start with the structure of C# program today. Are you ready?"
"I sure am!" I said enthusiastically, hoping I sounded confident.

"Here's what structure in architecture looks like," she said, handing me an old and tattered paper. "I pulled this from a textbook in the old library."

As I looked at all of the intricate pieces that melded together to form the inside of what appeared to be a cathedral, Sara gestured at the dusty computer screen on the corner of her desk. "And this is what a structure in C# looks like."

"Here, I highlighted some code structures that you need to know about. See that code on the top line there?"

using System;

I nodded, setting the picture down gently.

"This line adds additional namespaces that you'll use in the program. In this current program, we use only one - System. For now, we'll supply the additional namespaces. You won't have to worry about these until later. But pay attention to the syntax of this command - at the end of using, you have a semicolon (;)."

"I see that it's repeated a couple times elsewhere in the program," I said.

"Good eye," Sara replied, "any line that serves as a command will end in a semicolon."

After a few brief demonstrations of output, Sara said it was time to dive deeper into our program. We defined a namespace by using the following code:

namespace MyNamespace
{
 // A lot of code
}

In the definition of the namespace you need to specify its name, then surround all of that namespace's content with the curly brackets . In our example, we used the name MyNamespace. Sara explained that we were using upper camel case to name the namespaces, in the same way that we name local variables but with one exception: the first letter is capitalized. Namespaces can be empty as well, like this:

namespace SomeEmptyNamespace
{
}

They can also contain classes:

namespace NotEmptyNamespace
{
    class Program
    {
        // Some code
    }
  
    class AngryMonkey
    {
        // Some code
    }
}

Starting to see a pattern develop, I asked, "Does this mean that namespaces are wrapping classes, and classes are 'living' inside the namespace?"

"Exactly!" she exclaimed, before adding ruefully, "as much as any of us are living any more."

You can think about namespaces as cities, and classes as houses. In any given city, there are a lot of houses. But any given house only exists in one particular city.

I was beginning to understand how the pieces of the program come together, but was still a bit foggy on the individual components. "I get that a namespace can contain many classes. But what exactly is a class?" I asked.

"A class is a logical unit that declares data and methods to work with this data ," Sara answered, and after clearly seeing my reaction, added "Is that clear?"
"Erm..." I began, still trying to figure out what a logical unit was.
"Ok, let's try again in simpler terms." Sara said. "A class is a box of code that starts with keyword class , followed by its name and then its content within the curly brackets."

class Program
{
    // Class content
}

Still fighting my way through confusion, I asked Sara why a program even needed something as complicated as classes and namespaces. My tired and now overworked brain was envisioning a program as in the Matrix, with an endless line of commands and code running down the screen. In hindsight, I should have known that if she was teaching me about classes, then they probably played an important role in the programming I'd need to learn.

Luckily, Sara was in an understanding mood. "I know it looks like it increases complexity at first glance," she said, "but C# was built this way to make support of big programs as simple as possible. If your program consists of ten lines of code - no problem, you could write them one by one and it would be easy for someone else to make sense of it. But imagine a program with 10,000 lines. If you don't divide it into parts with different names/responsibilities, you'll end up with an indecipherable mess. That's why we bunch similar code into namespaces and classes.

"I think I understand," I said. "Classes and namespaces are there to add order to my program."

"Exactly! Now let's take a closer look at classes."

class MyClass
{
    static void Main(string[] args)
    {
        Console.WriteLine($"Die, stupid machine! {myName} tells you!");
    }
    static int Add(int a, int b)
    {
        return a + b;
    }
}

"First of all," Sara said, "let's agree to name classes in upper camel case . Starting with a letter - no crazy things like this, okay?" She held down the Shift key and banged out some symbols, resulting in #$%^MyClass .
Although my juvenile mind was silently thinking up all sorts of words those symbols could denote, I agreed that we could settle on upper camel case letters.

Sara pointed out the next level of structure, the Method. Our program had two, one being 'Main' and the other 'Add'. As with the code for namespaces and classes, all the code for a method should also be between " { " and " } ".

"I've seen code with a 'Main' task somewhere before," I said, "in the past. It seemed to always appear alone. Is there something special about that method?"

Continuing with her previous house metaphor, Sara asked "If you want to get inside of a house, how would you do it?"

"Well," I thought, searching my mind for a time when all the buildings in sight didn't have gaping holes in the walls from war. "I would find a door and open it."

"Yes, and if the computer needs to execute your program, where does it start?"

Losing her line of reasoning, I mumbled, "I have no idea. In the beginning..."

Sara explained that it starts to run commands from your Main method. It's kind of self-explanatory - 'Main'. Note to self - remember that you should always have a Main method inside your program. In addition, case matters: it must be called 'Main', not 'main' or 'mAIn'.

At that point there were still a few parts of the program we hadn't gone over, and I asked Sara to explain the static void and string[] args code. "It's getting late," she replied, adding "and I need to send Ritchie a report about my antivirus software. Let's pick this back up another time. For now just write all your code in the Main method, ok?" She stood up and began to gather her papers from the table.

Not ready to end the lesson yet, I said "Wait! I've got the basics down. What does static mean, how do I create my own methods..." and, perhaps a bit overconfident at that point, added "This lesson was so basic!"

Sara clearly had experience working with overenthusiastic pupils. "Basic, you say? Ok, let's see how fast you can manage completing these tasks." she said, pointing to a list of assignments on the screen. I remember thinking that I'd have them done in no time, even as I was beginning to regret immediately begging for more work.