When I was diving headlong into the world of coding and not too sure about what I would find, I knew one certainty: I enjoyed making stuff that works. And that’s good right? Well, it’s a double edged sword. When it works, it’s great, when it doesn’t, you spend hours and hours trying to figure out why.

I knew when I came across those situations that the answer had to be simple, because what I was making was simple. And they were, the problem is when you’re starting out nothing is that simple.

First, the name of my blog.

Coder coder = new Coder{}

And yes, that should be followed by a “;” really. I just didn’t think it looked as good as a title like that.

I remember going through loads of tutorials where Person person = new Person{}; was a common thing you would see. But … it was never really explained. It looked mildly amusing, and I wondered, why all the repetition? I was under the impression repetition is not something you want in your code.

To clear that up is fairly simple. It’s not repetition. As I’ve said before, every word in your code has a reason to be there. So, the first “Person”, this is the start of your variable declaration, it’s the same as the “int” in int a = 5;. It is just there to tell your computer ‘we are going to need space for an object of this type’ (more on objects later), so the computer can go and assign some memory somewhere where this is able to exist so we can make use of it. The second “person” (and starting it with a lower case letter is a convention) is simply the name. You are saying, ‘whenever I want to do something with this, I will ask for it by this name.’ It doesn’t have to be “person” at all, it can be whatever you choose to call it. So far we have instructions on what you are creating, and what you’re calling it.

So to the other side, new Person{}. Why new person? Why not just Person? Why not add the name of the person right then and there?

When declaring that you want a Person, and call it person, you haven’t yet said, will this be referring to a person that already exists, or are we waiting for a person to be retrieved and assigned to this particular “Person”? In this case we are saying, we want a person that has not been “filled in” yet. That is to say, it has whatever parameters our Person class has, but the information specific to this person hasn’t been determined yet, so I want to assign a space where I can refer to this person, but that is all I know for now.

One of the most common uses of the “new” keyword to create a new object for you to use is Lists, or other collections you might choose. So you would say, give me a new list, I don’t have what’s going in the list yet, but when I do I will need a list all ready for me to put things into. Can you add things straight away? Yes, that’s why these statements always have “{}” at the end. If you wanted to put something into your object right away, you could do that in between those curly braces. I won’t cover the syntax for that here, you’ll find that quite easily in the language documentation.

OOPs

So I said object, and I had to try really hard not to use terms like “instantiation” or “paradigm” because to be honest, if you’re just out of a few tutorials, and you’ve probably heard the term “Object Oriented Programming” or OOP, and thought you’re not ready for that yet. Well, I could argue you are, but more importantly I would urge you to be aware of it, because you are going to use it without even realising that’s what you’re doing. You might read some things that say “Everything in *insert OOP language* is an object”, and while yes, that statement may be correct, it’s not at all helpful when you’re starting out.

The first things that are 100%, definitely, absolutely, certainly objects that you code are classes. So going back to the person example, you might see this coded as

class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

How is this an object? Well when you say a person, this just outlines that when we have a person, they’re going to have two parameters: FirstName, and LastName. So far so simple, but how is it an object? Well, it’s coding so it’s best not to think of it too literally.

The Person class is just a class, don’t think of it as an object just yet. However when you say Person myPerson = new Person{} you have created an object, called “myPerson”. More importantly you’re then free to change the names, pass it around your methods, do whatever you want to do with it, but “myPerson” will be the object that you are manipulating, not the Person class. The person class just defines what a person is, in this case its an object that holds two strings. If later in the same code you say Person secondPerson = new Person{} “secondPerson” is another Person object, it is not “myPerson”, these are two objects of the Type Person. Two instances of the same class, but separate objects, hence you’ll see the term “instanciation”. You now have two Person objects. Again, do what you want with them, but now that you have two, you can compare them, you can add them to a list … whatever you want!

Hopefully that offers some clarity on what an object is, and makes Object Oriented Programming a little less scary as a concept. When you do some further reading you’re likely to come across “The Four Pillars of Object Oriented Programming” and “The SOLID principles”. And yes, do read about them, they are important when you get to doing things for real, mostly because they’re about best practice, and following best practice is a good idea in order to make your own life easier, so you’ll want to follow these principles. But when you’re learning, don’t get bogged down by it. Don’t end up not doing something because you can’t figure out how to do it following SOLID principles, because when you just need it to work, getting it to work is the important thing. You can always refactor later.

Re-what?

Edit. When programmers talk about refactoring it sounds big and scary and complicated, because they call it refactoring. It’s basically editing your code to work better. Sometimes it’s changing a line, sometimes its restructuring your whole project. When you hear refactor, think edit. Why all these complicated new terms for everything? I don’t know, but it has become standard terminology so it’s probably not going to change any time soon.

You will at first create small projects, and be happy with them, and make bigger projects, and bigger projects, and suddenly your project that’s your pride and joy looks like a big messy tangle of code that you can’t make sense of even though you wrote it yesterday. That’s not because big projects will always end up that way, it’s because when you wrote small projects, not following best practice, and not refactoring code doesn’t cause you too many problems, you can keep track of what’s going on. When you scale that up however, writing your big project the same way you wrote your small projects, it does become a problem.

The good news is the very act of refactoring – taking code you wrote that’s difficult to read, overly complicated, and unorganised, and editing it to be easy to read, simple, and laid out in a logical way – is going to be just as useful to you as writing a whole new project. The next time you approach a big project you’ll remember what mistakes you made, and what you did to fix them. You’ll soon fall into a habit of doing it the right way the first time round, and you’ll get a little better at it every time you have to go back and refactor your code.

Before I move on to the most common cause of not being able to figure out what you did wrong in your code, I want to mention Object Oriented Programming is not all there is. OOP is just one paradigm (another confusing word programmers like to use). There are others, and there is no reason you shouldn’t learn about those instead. For instance, functional programming seems to be gaining ground … maybe there’s something there you might find more appealing? I don’t know if you will, I personally don’t have much experience with other programming paradigms, so I won’t pretend I know what I’m talking about. So why is OOP everywhere when you’re trying to learn? Well, mostly, because it is everywhere; simply put, it’s the most widespread way of programming. That’s not because it’s better than other ways of programming, it’s just more commonly used, therefore more commonly understood.

the reel issue

So, you’ve written some code, you’re sure it should work, but it just wont. What’s the first thing to look for? This is a real boring one to be honest. Spelling. The very first thing you should do when you’re trying to figure out why something isn’t working is to check your spelling. It sounds obvious, and shouldn’t your code editor be flagging up when you didn’t type a method, variable, or keyword correctly? Yes and no. First, casing, if you type OneThingLikeThis (pascal case), and oneThingLikeThis (camel case), your program sees those as two completely separate things that have nothing to do with each other. Other times you need to use a string variable which then gets read and interpreted. As long as you pass a string, your editor will not pick it up. A string is a string and you won’t know theres a typo there until you run your program.

And then theres the most ‘I can’t believe I did that’ of moments. Just plain and simple using the wrong variables. Code editors are great, you get intelisense and you dont have to type the whole name in, it does it for you. Well, if you have several variables or even methods with similar names, intelisense can get it wrong, and if you forget to check it actually typed what you wanted it to type, it will assume that was right and cause an error. Once you’ve named something, avoid renaming it, otherwise you can either depend on the code editor to rename it across your program (do you really trust it that much?) or you have to go through all your code renaming every instance of that name. A good strategy for naming your variables and methods is a must, keep it consistant, and always double check what your intelisense writes for you. Also avoid copy pasting any code, and making small changes within the copies, chances are you’ll miss something.