I often get WAs on problems with multiple test cases because of

• Not initialising arrays or clearing containers.
• Not doing cout << endl; after end of output for a test case.

Reading n edges instead of n-1 edges when dealing with a tree.

Not using int64_t or long long when the some variable can be more than 32 bits

Using doubles when it's possible to use long long entirely

Though non-preventable, the prime cause of WA is trying to solve problems. :P

Whiskey

missing the update of mid in binary search :

while(r  -  l > 1)

{

if(check(mid))l = mid;

else r = mid;

this part // mid = (l + r) / 2

}

not printing the answer ;p

Mixing up loop variables. I do this quite often:

for(i=0;i<n;i++)
{
 // lots of code
 for(i=0;i<x;i++);
}

forgetting to comment out the output used for debugging lol

I used to get WA due to the debug statements but now I use template code for TRACE using cerr instead of cout so there's that

Using for (int i = 0; i <= s.size() — 1; i++) instead of for (int i = 0; i < s.size(); i++)

Thanks to operator precedence I constantly got WA for typing something such as if (a & b == c) (while I was thinking of whether the value of (a & b) equals c)...

Our team has made a special list of possible reasons of getting wa: link (in russian)

I have been a victim of first one too many times and want to tell you are still wrong. Consider a case where answer can be as huge as 1e18.

#include "bits/stdc++.h"
using namespace std;
double x=123456789123456789.38438;
int main()
{
	cout<<setprecision(12)<<x;
}

• Forgot to write a piece of code that handles special cases.

• Used n instead of m and something like that.

• Forgot to add ans %= mod somewhere, getting an integer overflow.

• And the worst one: when you idea is based on some wrong assumption, and after writing many lines of code and getting WA you realize it fails and you have to rewrite everything ;(

for(int i=0;i*i<n;i++)
{
    ...
}

In case n is very large

for (int i = 2; i*i < n; i++) {

instead of

for (int i = 2; i*i <= n; i++) {

when dealing with divisors and primes and factorization

Actually I can list a lot more

• Forgetting a corner case.
• Forgetting two corner cases.
• Handling a corner case wrong.
• Handling a corner case that's actually not a corner case, and is still correct in the general case.
• rand() only gives random number up to RAND_MAX, on CF this is 32767, too small.
• size() returns an unsigned integer. Doing things such as str.size() - 2 when string size is 1 will overflow. This is especially dangerous when used in a loop.
• Quicksort.
• Semicolon instead of comma, and vice versa.

This is a mistake I've seen people make in sieve:

int sieve[n+1];
fill(sieve,sieve+n+1,1);
sieve[0] = 0, sieve[1] = 0;
for(int i=2;i<=n;++i)
    for(int j=i*i;j<=n;++j) //here we have made a mistake already, i*i can overflow, become negative and 
        sieve[j] = 0;       //give segmentation fault on this line.Use ll or start j from 2 instead.

Another mistake that I've made a couple of times is with memset:

int sieve[100000];
memset(sieve,1,sizeof sieve); //mistake made, memset operates byte-wise, you can only set to -1 or 0,

Strictly speaking you can set to other values, but you won't get the expected value. Another mistake which you may make with memset is that you should use sizeof operator only if the bounds are known at compile time.

int* sieve = (int*) malloc(4*n); 
memset(sieve,-1,sizeof sieve); //doesn't work as intended, only first element is -1 

Basic thing is that you should be aware it operates byte-wise on underlying memory, not on actual elements.

Other common mistakes include:

1.
int n;
int arr[n];
cin>>n;

2.
int a,b,c;
cin>>a>>b;
c = 1LL*a*b%50; //okay
c = a*1LL*b%50; //okay
c = a*b*1LL%50; //error

3.
//okay this is just carelessness, but it's easy to make
if( (exp)%2==1 )
//is semantically same as 
if( (exp)&1==1 )
//but practically different. % operator and & operator have different precedence, so they give different answers.

4.
//custom comparator for library-based sorting.
//the sorting function asks the question : "is element a before b in the strict-weak-ordering that you define ?"
bool comp(int a,int b)
{
   return (a<=b); //mistake, because if(a==b) then by strict ordering it is not absolutely necessary
//that a come before b, this can get very murky if you are dealing with custom objects.
//best thing to do is to return a 0 if there is no preference, if there are still errors, then you need
//to get into the details of strict-weak-ordering, which can get complicated for custom objects, but is
//essential nevertheless.
}

5.
//pow() function,seriously guys, never use pow for int^int, it's horrible and fails you silently.

int r1 = pow(5,9),r2 = 5;
for(int i=0;i<8;++i)
    r2*=5;
assert(r1==r2); 

//this code fails on my machine, i5, 8gb ram, win10, g++ version gcc 6.3.0
//the answer given by pow is off by 1, the reason is that pow returns double, so you need to use round
//you can easily overlook this and make the mistake I made above in a time-pressure setting
//but in my humble opinion its better to avoid pow altogether for integers, it can have many pitfalls,
//use fast-expo instead.

Finally, I read through all other comments so far, I have made some of the mistakes you all have mentioned and I could easily make the other ones too(Thankfully now I won't :-P). Hope to see more such posts on codeforces :-).

If a problem has multiple subtasks where the only difference between them are the constraints, and if you use fixed array sizes...

Forgetting to updated your array sizes before submitting the same solution to the larger subtask.

const int MAXN = 205; // but MAXN = 5005 in larger subtask. :(
int n, a[MAXN];

cin >> n;
for(int i = 0; i < n; i++) cin >> a[i];

Using a map<double,int> for mapping a number of the form p/q to an integer, instead of using map<pair<int,int>,int> where the key is a pair of numerator and denominator after dividing both (numerator and denominator ) by their gcd. Using double datatype as key may give precision errors.

In multiple-testcases format, sometimes there is a tricky case like "if N = 2, then output -1", ignoring the content of the array. So yeah.. next testcases will be hella messed up.

Use i += d in Java, where i has type int and d has type double.
Because in other cases you expect compile error when you data can be truncated, but in this case it is not even a warning!

Don't know if this is technically a programming bug, but misreading problem statement can be a really horrible way to get WA. With other bugs, at least you can eventually figure it out after a while of debugging. But this one could ruin your entire contest if you don't notice your misconception soon enough.

Not accounting for the N = 1 case in tree/array/graph/etc. problems. It was several days into our (sort of CC-Long-styled) olympiad eliminations, and I chuckled when I found that special case...

Also, not knowing the intricacies of your chosen input format. For instance, when to use cin.ignore(); or when to use %c%c in place of %c in scanf, how large to set a char[] for input purposes... that sort of thing.