Home > Learning To Code > Learn To Program 2: Ground Rules

Learn To Program 2: Ground Rules


Learn the tricks of error messages

It’s perfectly normal when programming for your code to fail with an error. Fix-test-fix-test and repeat is standard programming practice. Getting an error message does not mean you have failed, it is just part of the process.

Some error messages are easy to understand. Others will seem very cryptic. Sometimes you will make a simple typing mistake and the compiler will get really confused and give a crazy error message that seems like it has nothing to do with what is actually wrong. Here are a couple of tips if the error doesn’t seem to be on the line number that the compiler tells you:

  • Check the first non-blank lines immediately above and below the error line – did you miss a semi-colon (;), a closing brace (}) or a quote mark (“)? This is really common, expert programmers do this all the time too, so it’s standard to check the code around the error line, not just the error line itself
  • Is the error on a function call? – check the definition of the function to make sure you have used the right number and types of arguments / parameters
  • Is the error on the declaration (first line) of a function? – check all the places where you call the function to make sure they use the right number and types of arguments / parameters
  • Is the error at or soon after the end of a struct or class definition (C, C++)? – there must be a semi-colon after the closing brace on these definitions
  • Does the error happen when reading a file or other resource? – check that the file or resource is in the location that it should be, has the right name, and that your program is in fact running in the directory you think it should be

Of course, errors can occur for an almost infinite number of reasons, but these are some of the most common mistakes made by beginners and experts alike.

Learn a good coding style and stick to it

What does good coding style mean? Generally, it means making your code easy to read and understand, both for yourself at a later date when you come back to re-visit old code, and for others. This last part is important even if you never intend for anyone else to see your code: if other people can understand it, so can you when you return 6 months later having completely forgotten what you did. This scenario is more common than you may think. Here are a few tips:

  • Learn to indent properly – every time you create a new code block (typically inside {…} in many languages), indent all the code inside it by one tab level (if you have made a mess, you can use the keyboard shortcuts for selecting and tabbing mentioned earlier to get the indentation right). This doesn’t seem so important in small programs, but in large programs with many nested blocks of code, the flow of the program can become quickly impossible to follow by a human reader if it is not indented. Get into the habit of indenting even your small programs, it well help you follow what is happening better.
  • Comment your code – most languages allow you to add comments to your code. Comments are your own notes and writing that are ignored by the computer when compiling or running the program. Particularly, comment sections of code that seem tricky to understand so that you know how it works when you re-read it later. Notice that comments should be used to augment your code, not just repeat it. For example if you have a line “rolls = 0”, don’t write a comment like “// set rolls to zero”. This tells you what you already know. Instead, write something descriptive that describes the meaning of the action, for example “// sets the number of dice rolls to zero because we haven’t rolled the dice yet”.
  • Name your variables descriptively – In most programming languages you are relatively free to choose how you name variables, functions, classes and so on. There are many standard notations defined for this which you can search for on the internet – for example camelCaps and Hungarian notation. However, the most important thing is to pick one style and stick with it. It is usually a good idea to use descriptive names for variables that have a relatively long lifespan in your program, but short throw-away names (like or x) for quick calculations and loop counters that will be discarded immediately after use. Find a balance though: a 40-character descriptive name is overkill and can make your code harder to read, but using 1 or 2 characters for everything will also make it cryptic. Try to find a happy medium between overly long and overly short. Secondly, it can be useful to differentiate variable names from function and class names, for clarity in larger programs. Again there are many ways to do this: I tend to give all my variable names a lowercase first letter and my class names an uppercase first letter, so count would refer to a variable and Count would refer to a class. I recommend reading further on the internet about this; the best notation is widely debated and you will learn what experienced programmers use. Once again though, the important factor is to be consistent so that you understand what is what in your programs.

Pages: 1 2 3 4

  1. cheeseater
    March 15, 2015 at 20:20

    Thank you for this post, it is very useful.

  2. April 18, 2015 at 01:34

    To put in 0.02 cents from an old programming fart…

    I would add, be sure to have fun…try to find some small thing to start with, and ‘play’. Start with the old ‘Hello World’ in the language of your choice.
    DONT treat learning to code as ‘important’, its a hobby, enjoy it…its hard, but rewarding.

    Learning programming is just like learning anything else, its always ‘Hard’ at the start, then, IF you don’t give up, it gets easier, and when it gets easier, it gets funner, fun makes you want to do it more (called practice), doing it more makes you better, which makes it funner, recurse and before you know it your a programmer.

    Find a friend who also wants to learn and bounce little programs back and forth, always
    better to suffer with friends….and eventuallyl you’ll get good and its nice to not suffer with friends too.

    OH, and after your done and find it a little fun, look up Data Structures right away, they matter, and you really need to get those to do big stuff…and they are fun in their own right.

    All programmers look at existing code to learn stuff, I’ve been programming professionally for 35 years and I still look at others code (thats what drew me to this site btw good job Katy!) We all stand on each others shoulders, NO one is born knowing anything except how to eat poop and cry, we ALL have to learn everything we know, don’t get discouraged when you see someone who’s a ‘great’ coder, remember, they suffered too, and you’ll get there if you persist in your efforts.

    But most of all do it for fun, don’t waste your life trying to chase doing things for $$$…money will come if you just do what you enjoy.

    OH, remember, artists, good ones, make art for ‘fun’ its what they ARE artists. Programmers program for fun, because, well, its what we ARE, we do it for work, but we do it for fun, at least the good ones do.

  1. No trackbacks yet.

Share your thoughts! Note: to post source code, enclose it in [code lang=...] [/code] tags. Valid values for 'lang' are cpp, csharp, xml, javascript, php etc. To post compiler errors or other text that is best read monospaced, use 'text' as the value for lang.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: