In my time programming and helping others with their programming I've noticed a number of very common mistakes. Hopefully some of you will keep this short list in mind the next time you're having trouble with your program.

1. Code Readability
The first thing on this list is not so much a mistake, but an example of poor form that can make your code very difficult to read and debug: not indenting and commenting your code. Indents make code much easier to read (and therefore easier to debug), especially when it is being read by someone else.

Comments can make your program easier to understand. It is very common for amateur programmers to write out a program, and then later on, they have forgotten what their thought process was or how the code works. In short, good form saves time.

Even more useful than comments is what I call "self-documenting code". Your code should be clear and understandable based just on the variable and function names. Bad code:

int i, ps, kl, tx;
double df, ef, twf;
kl = dp_ti();

Good code:

int positionX, positionY, maxX, maxY;
float velocityX, velocityY;
velocityX = calculateVelocityX();

2. Not modularizing code
So many people just throw everything into the main function and end up repeating the same code again and again. Instead, it is best to break your code up into small, simple functions that can be called up anytime that bit of work needs to be done. There is emphasis on 'simple'; these functions should do exactly what is intended and nothing more or less. A nice rule of thumb when writing code is that if you need to scroll down to see the bottom of a function, it's probably too long.

3. Misunderstanding Equal Signs
It may sound minor and obvious to more expierenced programmers, but it's quote common for beginners to mix up '==' and '='. I'm amazed at how often people make this mistake. For the record, '=' is the assignment operator used to assign a value to a variable, and '==' is the is-equal-to operator used for comparisons. This is the case for most common programming languages (but not all).

4. Common String Mistakes
a. Comparisons
Many languages do not allow strings to be compared with the '==' operator. For languages such as C, C++, Java, and some others you have to use a compare method built into the string class or some other method intended for comparing objects (because for those of you who don't know, strings are not primitive data types, they are objects).

b. Null Terminating
This doesn't apply to all languages, but in C you have to remember to null terminate your strings. In C, strings must end with a null character ('\0'). This is particularly important if you intend to print the value of the string. When printing, C begins at first element of the character array and then continues to print until it reaches the null character, and so if there is no null character it will be stuck in an infinite loop and die.

On a related note, you need to remember to leave enough space for a null character. For example:

char exampleString[10];

The string exampleString only has room for 9 characters (not 10) because the final character must be the null character.

5. Using 'Bad' Functions
There are many functions out there that are insecure and poor form, and these should be avoided. For example, everyone knows about the infamous goto statement. There is a religious battle amongst programmers about whether or not it's okay to use the goto statement, but in general, it is seen as poor form and it is unnecessary. There are a number of other bad functions such as the gets() function in C for string input. Here is a demonstration of why the gets() function is bad: Here. If you enter a long string for the variable 'foo', it will overwrite the data stored in 'bar'. When I ran it, it took 17 characters to overwrite the data in 'bar'.

6. Integer vs. Float Division
This one is a very common mistake made by beginners. When dividing two numbers, if both operands are integers, then integer division is used, else real (i.e. decimal) division is used. For example: 1/2 would output 0, but 1.0/2 would output 0.5 because of the concept of type promotion. Integer division can cause data loss sometimes if you're trying to store values into a variable.

7. Array Indices
This is almost as basic as #3. Beginners very commonly assume arrays start their incides with 1 instead of 0. An array of length 10 goes from 0 to 9, not 1 to 10 (unless you're using matlab).

8. Optimization Errors
Many of these optimizations work perfectly fine, but only if you are sure of what data will be passed into the function. These are optimizations that the compiler would never decide to do because it runs the risk of altering the result.
a. Aliasing - Using pointers that could reference same memory
For example:

void func(int *a, int *b)
{
    *a+=*b;
    *a+=*b;
}
void optimizedFunc(int *a, int *b)
{
    *a+=2* *b;
}

The result of the optimized function could be altered if *a and *b are both pointing to the same thing. In that case, func would be doing the same as a+=3a, whereas optimizedFunc does a+=2a.

b. Function Calls - Combining function calls
For example:

int f(int); //just some function that takes an integer as a parameter
int func1(x)
{
    return f(x)+f(x)+f(x)+f(x);
}
int func2(x)
{
    return 4*f(x);
}

The result of func2 could be different because the function f could be changing the local variable x or it could be changing the global state or creating some other side effects.

9. Using Functions in Conditionals
It's very common to see function calls in a condition such as a for loop or while loop. For example:

for(x=0; x<array.length(); x++) { 
  blah blah blah; 
}

This code is not wrong, but it's also not optimal. This slows things down a bit because the length() method has to be called after each iteration of the loop, but the array has a fixed length, so that value wont change. So instead, declare a variable: int len=array.length(), and then you can say x<len. It may make minimal difference in your code's execution time, but it's still a good habit to get into for future programs where performance is extremely important.

10. Finally, and most importantly
TEST YOUR CODE BEFORE ASKING FOR HELP!
So many people have PM'd me asking "Does this work?", and though I usually reply nicely, I'm always thinking, "What the hell, you're sitting in front of a computer with a compiler, what are you asking me for?" Remember, compilers are your friends and they can answer difficult questions like "does this work" pretty easily.

So in summary: make your code neat, organized, and well labeled; watch out for syntax errors; beware of depreciated functions; keep your variables' data types in mind; be careful about combining pointer and function arithmetic; and utilize your tools (i.e. compiler, debugger, IDE, etc.).