Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Programming Mistakes To Avoid
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:

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 anymore, 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. 

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 8 years ago, as a relatively inexperienced programmer (although I’d already been programming for 4 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. Another 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!)

It takes so long to learn simplicity.
[-] The following 2 users Like dealwap's post:
  • Aaron, jonath45
wow ... What an interesting read
good thing I am guilty of just few of those especially 1 & 9
I am a proud member of NIgerian Coders Team
[-] The following 1 user Likes abcheats's post:
  • dealwap
Wonderful write up sir, coding for thirteen years! amazing I've only just started, and I find myself guilty of No 08, guess I'll have to start reading then Big Grin
CEO of Forgenest Inc.
nice article i just found out am guilty of that ''thinking you know all'' nice one boss i will definately follow your instructions
I am a proud member of NIgerian Coders Team
[-] The following 1 user Likes Lawal Israel Oluwasegun's post:
  • dealwap
I love this..
[-] The following 1 user Likes Deelino's post:
  • dealwap
if you looking for me ehn... just check out 1 and 5, you have seen me....

i am actually trying to overcome 1 by building a big personal project
let me add 

12. Choosing a path
As a programmer choosing a path and sticking to it is very necessary, you choose to be a web developer, mobile developer and so on, it is important you choose one out of them and do it full time. Even in web developing, you can choose to be a front-end developer and make good career out of it. It is not compulsory you must both front-end and back-end, most companies don't even need people that knows both, they look for someone that specialize in one... The greatest mistake you will ever make is choosing to be a web developer and mobile developer because you won't be able to balance the two and you will end up knowing nothing in both..... I am a victim but when i realized it, i choose a path and that is mobile developer which i am doing full time. I must say i have made drastic improvement in learning and understanding mobile and i can proudly say i'm a mobile developer unlike before where i learn php today and learn kotlin or java tomorrow.
[-] The following 1 user Likes Cavdy's post:
  • dealwap

Possibly Related Threads...
Thread Author Replies Views Last Post
  [quiz 1]: Who Is In For Programming Quiz? dealwap 15 320 10-24-2018, 06:13 PM
Last Post: oliakuk
  ALERT:  Machine Language Vs Programming Language jonath45 7 231 06-22-2018, 08:08 AM
Last Post: iamdannyfc
  ALERT:  The Downturn Of Coldfusion Programming jonath45 6 189 06-21-2018, 02:36 PM
Last Post: jonath45
  FUN: Share Your Experience (journey) Into The Programming World abcheats 15 700 05-06-2018, 06:35 AM
Last Post: abcheats
  R Programming Language Cavdy 2 207 05-05-2018, 10:45 PM
Last Post: oliakuk
  An Introduction To Kotlin Programming Language cheatex 0 113 11-20-2017, 12:59 PM
Last Post: cheatex
  Some Good Projects For Students To Improve Programming Skills dealwap 12 520 11-11-2017, 11:01 AM
Last Post: iamdannyfc
  Some Programming Languages And Their Applications - Programming 101 abcheats 5 343 09-07-2017, 07:56 PM
Last Post: abcheats
  Words And Symbols Associated With Programming abcheats 2 236 09-05-2017, 06:29 PM
Last Post: Dynamo
  Getting Started With Programming abcheats 5 320 09-02-2017, 11:11 AM
Last Post: abcheats

Users browsing this thread: 1 Guest(s)

About Nigeria's Creative Talents

Nigeria's Creative Talents is an online community where every creative Nigerians can share ideas with themselves.

For any more information, please use our contact form.

              User Links