When you're learning to program, it goes without saying that you make a lot of mistakes. The problem is, sometimes you don't know you're making them. In my work teaching first-year university students to code, I see the same errors come up over and over again, and they're the same mistakes I made when I was learning. So here's my list of the top beginner mistakes to avoid.
If you're starting out in the field, you'll also want to make sure you've fully equipped. For that, see our guides to the best laptops for programming and the best monitors for programming.
01. Fear and self-doubt
The number one mistake you can make as a beginner programmer is to think you're not good enough, not smart enough: that you have the wrong type of brain, and you'll just never get it.
I believe that anyone can learn to program to at least a basic level, if they stick with it. Code will seem like an incomprehensible wall of alien language at first. That's normal! But bit-by-bit you learn what each part does, and it's not scary any more, and then you see it's really all very logical, when you know what it means.
There's definitely an element of natural talent to programming and logical thinking, but it's massively outweighed by hard work and hours spent plugging away at your code, reading tutorials and looking-up documentation. Master your fear, or fear will be your master! Or something.
I'd advise any beginner programmer to play with the drag-and-drop visual programming tool Scratch. It's a brilliant way to learn programming concepts like loops, "if" conditionals, variables and arrays, without being put off by mistyping code. Because there's no typing! It's increasingly being used in schools to introduce programming, and I can't recommend it highly enough.
02. Messy code formatting
One way an experienced programmer can almost instantly spot code written by a beginner is messy formatting, such as not indenting code properly or having inconsistent use of new lines and white space. Many languages, such as JavaScript, don't impose many restrictions on how you format your code. The JavaScript interpreter will do its best to run code no matter how it is laid out. This can lead to beginners being somewhat haphazard with their formatting.
Get the Creative Bloq Newsletter
Daily design news, reviews, how-tos and more, as picked by the editors.
This is a mistake, because indenting code is one of the ways we show its logical structure. By tabbing or spacing code in from the edge of the window, we show where functions, loops and conditionals start and end, so we can be sure all our code is in the right place. As JavaScript lets you define functions inside other functions, it's quite easy to end up declaring a function in the wrong scope (or creating 30 functions per second on a setInterval!), if you don't watch where your curly braces start and end.
There are various conventions for how to format your code, and it doesn't really matter which you use as long as you are consistent. Another bad habit is leaving big chunks of commented-out code that you don't need any more, but you're keeping there "just in case". We all do this, but every day or so it's good to take a skim over the code and delete any commented-out sections – you're not going to need them again!
03. Inconsistent use of uppercase and lower case
Some languages are case-sensitive, others are not, but whatever language you're writing, you should be consistent in how you use uppercase and lowercase characters in your variable and function names. Beginner programmers often create a variable with one case e.g. "var Score = 5", then later on try to reference it with a different case - "if (score > 3)" - and wonder why their code doesn't run.
Additionally, some programmers move between different languages, bringing the conventions of one language to another, rather than respecting the style conventions of the new language.
In JavaScript, function and variable names should use camel case - that's starting the first word with a lower case letter and each additional word with an uppercase letter, like this: myVariableName, bestScore, winnerName. Other languages might have a convention of separating words with underscores, but when I see that used in JavaScript, it looks odd.
04. Bad variable and function names
We might laugh at Java programmers' long-winded class and variable names like the famous "AbstractSingletonProxyFactoryBean", but there is actually a really good case for writing longer, descriptive variable names instead of short abbreviations. The intent of the code becomes a lot clearer, and you're much less likely to have two different variables with the same name in different places, which can confuse you, or even break your code.
In JavaScript, where file-size is an issue, there's more of an argument for shorter variable names, but even there you shouldn't be abbreviating to the point of losing all meaning – and you can always use a minifier to get the size down. Even if you're a bit dyslexic like me, the worst crime in variable naming is to have a spelling mistake in a variable name. It's hard enough to remember your variable names without having to remember which spelling mistake you made.
Another common bad habit is making slang variable names. While researching this article I looked back over some old code wrote eight years ago, as a relatively inexperienced programmer (although I'd already been programming for four years, so probably should have known better!), and found all manner of crimes, including slang variable names like "numPlayaz" and intentionally writing "paws" instead of "pause", to entertain myself.
Why would you do that Iain, why?! These days, I have formed my own set of naming conventions. For example, whenever I'm keeping track of the number of things I have, I always write numThings, and when I'm keeping track of an index of something (e.g. its position in an array), I always use thingNum. It is little conventions like this that save you a lot of time wondering what you called things when you come back to old projects.
05. Over-commenting
I'm a big fan of self-documenting code – that's code where the variable, function and class names, and overall architecture communicate the meaning of the code to other developers (and your future self!) without the need for lengthy comments.
However, I do also see the value of commenting, especially where it flags a work-around for a specific issue that might not be obvious. What you don't need to do, however, is write comments like this: "score += 5; // adds 5 onto the score". What you would be doing there isn't documenting your own code, but explaining how programming works. This might be a useful exercise when writing your first program, but it's not something you should hang on to.
06. Not knowing the full expressive power of your language
You can't really blame beginners for this, as it only comes with experience, but once you get one or two years into programming, it's really time to start learning some of the less common operators – they're incredibly useful. For example, here are some to swat up on:
- ! - The not operator, represented by an exclamation mark, reverses the value of a Boolean. Take, for example, "x = !x". If x started out containing the value false, it will now contain true, and vice versa. You can also use it in an "if" condition like this: "if (!alive)" – this is the same as writing "if (alive == false)", but a bit less typing.
- % - Called modulo, the % operator is nothing to do with percentages. Instead, it returns the remainder you would be left with after dividing one number by another. It has a million uses, but one is to colour alternate lines in a table, for example. To do this, when looping through your data, you would say "if (i % 2 == 0) { //one colour } else {//another colour}"
- The ternary operator, represented by a "?" and a ":" allows you to perform a conditional and an assignment in a single line, like this: "var lives = isEasy ? 5 : 3;"
07. Confusion between languages, frameworks, platforms and IDEs
When starting to learn programming, especially web programming, you're bombarded with different languages, framework and IDEs, and it can be very hard to know what they all are, so let's quickly settle some of the common misconceptions.
Firstly, without wanting to be too pedantic, HTML and CSS aren't programming languages. HTML is a mark-up language and CSS is a styling language. They're great skills to have, but when you're writing HTML and CSS, you're not technically programming.
For front-end web programming, the language is JavaScript. Every lesson in the first few weeks of my university course, a student says Java when they mean JavaScript. This is understandable - the name JavaScript is an unfortunate bit of cross-promotion with Java that has caused ripples of confusion for almost two decades now!
Another common confusion, when you see $("#thing") all over example JavaScript code, is the relationship between JavaScript and jQuery. Using the jQuery library makes working with JavaScript much, much easier, but it's good to remember that it is just a library, not part of JavaScript or a language in its own right.
One further misconception is to think your HTML, CSS and JavaScript are tied to the IDE you created them in. Unless you're using something like Dreamweaver templates, whatever IDE you use, your code is just standard plain text that you can open and edit in any other IDE or text editor, even Notepad!
08. Not taking advantage of debugging tools
If you're working in a statically typed language like Java, C# or ActionScript3, you should be using the debugger. These languages give you really detailed errors, which combined with a debugger, can help you track down the bugs in your code easily. If you're working with JavaScript, while you don't have quite as much debugging power, there's still more than just "alert()" to help you. Chrome comes preinstalled with invaluable developer tools that let you see your "console.log()" output as well as detailing code errors.
09. Not backing up your work
The phrase "I just lost [X] hours work" should not be in a developer's vocabulary! There are so many good tools for automatic back-up and version control now, that there's really no excuse to lose anything, even if you have a major computer malfunction, fire, burglary or other minor disaster.
I work from my Dropbox folder, which automatically backs up my all my files, with version history – and when working with other developers or on open source projects, I also check my code into an SVN repository or Github. All these tools have free-to-use options.
10. Thinking you know it all
Here's one I was guilty of for far too long, and it's an easy mistake to make. After a lot of persistence, you finally write some code that actually works! Your confidence grows, and before too long you're teaching stuff to your friends and you feel you can take on the world!
This is awesome, and you should enjoy that feeling of finally having the computer do what you want it to. But while you're grinning your face off, banging out line after line of code, don't forget that you're still just learning.
Maybe it's time to start looking back at your old code and reflecting. Which parts of your code do you understand one hundred per cent, and where are you just copy-pasting? Maybe now's the time to delve into that function marked "DO NOT TOUCH" and work out what the heck it does. I've been coding for 13 years, and in a lot of ways I still feel I've only just scratched the surface.
11. Bonus mistake! Thinking "if" conditionals need to contain a comparison
I've left this one until last, as it's sure to rub even a few experienced programmers the wrong way. It's code like this: "if (myBoolean == true)". This is one of those mistakes that doesn't actually do any harm, but demonstrates a lack of understanding of how programming languages work.
Let's clear it up: the brackets that come after the "if" keyword must always contain a Boolean (true or false) value. We often compare two values in the brackets to get this Boolean – for example "if (x < 200)". Here "x < 200" will resolve to either true or false, depending on the value of x. But if we already have a true or false value e.g. "myBoolean" we can just write "if (myBoolean)", there's no need to write "== true". (This issue gets more complicated in JavaScript where there's a convention of using "===", but I'll leave that can of worms for another day!)
I hope you've enjoyed my list – and remember, it's okay to find programming tricky – it is tricky. Happy programming!
Words: Iain Lobb
Iain Lobb designs and develop games at our studio Lobb Games. After many successful years developing high quality games with Flash for clients such as EA, Cartoon Network and Adult Swim, they've recently switched their technology focus to Unity. Follow Iain on Twitter.
Liked this? Read these!
- How to make an app: try these great tutorials
- Check out these amazing HTML5 examples
- Free graphic design software available to you right now!
