C/C++

• Putting an extra semicolon after the heading of an if or while statement, for example

  if (x > 0);
  {
      x++;
      foo(x);
  }
  

  will result in always executing the block following the if. Something similar can be said for while statements.

• Writing if (x = 0) instead of if (x == 0). When compiled with g++ -Wall, this construction will result in a warning: 'suggest parentheses around assignment used as truth value'. The same goes for while.

• Assuming wrong precedence of operators. For example, the construct if (mask & 0x80 == 0) looks ok, but it is not, because == has a higher precedence than &. This construct is in fact equivalent to if (mask & (0x80 == 0)) and will always be false (left as an exercise for the reader). The obvious solution to this problem is to use parentheses around (complex) expressions before and after the == as in if ((mask & 0x80) == 0).

• No break at the end of a case-statement; a switch such as

      switch(value)
      {
          case 0:
              printf("value = 0\n");
          case 1:
              printf("value = 1\n");
          default:
              printf("value is not 0 or 1\n");
      }
  

  will, when value equals 0, produce

  value = 0
  value = 1
  value is not 0 or 1
  

  instead of the 'expected' output

  value = 0
  

  The compiler will not generate a warning for this, since it's perfectly legal.

• Mixing up the logical operators (&&, ||) and the bitwise operators (&, |).

• Calling a format-function with too few parameters, e.g. printf("debug: x = %d\n");. This will result in some random value printed out (depending on the contents of the stack). Fortunately, when compiling with -Wall, gcc will warn you:
  test.cc:5: warning: too few arguments for format.

• Writing if (function_name) instead of if (function_name()). The first is also legal in C/C++ and will not generate any errors or warnings.

• Spreading C-comments across multiple lines, thereby putting some statements in comment:

  int foo(int x)
  {
      int x2, y;
  
      x2 = x * 3.1415;            /* we're doing some
      y = x2 * x + x * x + 1.1;      pretty extensive
      x = abs(x2) > 1 ? 0 : 1;       calculations here */
      return y * x;
  }
  

  This looks very nicely formatted, but it won't return the correct result. It's much safer to always begin and end a comment on the same line, or use the // when programming in C++.

• Using arrays as 1-based instead of 0-based arrays: int intarray[10]; is an array that ranges from 0 to 9, not from 1 to 10. Accessing the 10th element when there is none can result in unpredictable behaviour, depending on the variables stored in memory that are immediately following that array. Possible behaviour: memory faults/segmentation violations (memory faults will happen when a program tries to read from or write to memory that does not belong to that program), runtime errors in system-functions like malloc, other variables changing values when they should not.

• Returning local arrays, for example

  char* int2string(int i)
  {
      char buffer[64];
  
      sprintf(buffer, "%d", i);
      return buffer;
  }
  

  Local arrays (in C these are called automatic variables) are allocated on the stack and are removed as soon as the function returns. The pointer (in this case buffer) will then be invalid. This will work:

  char* int2string(int i)
  {
      char* buffer;
  
      buffer = new char[64];
      sprintf(buffer, "%d", i);
      return buffer;
  }
  

• Passing a variabele to a function where an address is required, e.g. scanf("%d", value) instead of scanf("%d", &value). The first will most of the time result in a memory fault. When compiling with -Wall, gcc will give a warning:
  test.cc:8: warning: format argument is not a pointer (arg 2).