What are common mistakes in coding? [closed]

Question

For example, a common error in C/C++ is to use the assignment operator = instead of the comparison operator ==.

Answer 1

Off-by-one errors

Iterating through a loop either once too often or one time less than intended, e.g.

for($i = 1; $i < $number_of_times_to_loop; $i++)

will go through a loop once less than intended. Changing the < to <= would get the above loop to cycle $number_of_times_to_loop as intended.

Another type of this error is the Fencepost error, so-called due to the following illustrative example:

Given a 100m stretch of land, how many fence posts do you need to dividie it in to 10 equal sections? Typical answer is 10 (100/10), forgetting the extra post needed for the outer boundary.

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | <-- divisions

1---2---3---4---5---6---7---8---9---10---11 <-- posts required

Answer 2

Forgetting the ; is probably the most common mistake in C-family languages. Failing to check the bounds of an array is probably another very common mistake in languages that allow you to make it...

Answer 3

In C#, using throw ex instead of throw inside of a catch block. The former will reset the stack trace.

Answer 4

I saw quite a few errors with missing break in switch statements (C++, Java). Fortunately C# forbid this practice.

switch (var) {
    case 1:
        //do something
    case 2:
        //do something else
}

Answer 5

In languages like C#, changing the value of a parameter passed in to a method and then wondering why it's not updated in the calling code.

Answer 6

• Memory leak in C or C++. Using the RAII idiom in C++ is very helpful.
• Another memory error is double free in C and C++, which can be disastrous as well.

Answer 7

Misplaced semicolon C/C++ and/or alignment:

if(x == 5);  
  doSomething();  

doSomething() is always called even when x is not 5.

Obviously you know not to put a semicolon at the end of the if but sometimes it can be an overlooked typo.

Answer 8

Doing this in C/C++ :

#define VALUE 5;

It will cause compilation error elsewhere in your code.

Answer 9

Writing

if (x > 5) return true;
else return false;

instead of

return (x > 5);

Answer 10

Forgetting to close connections. (HTTP, database, whatever.)

Closing the connections prematurely.

Answer 11

Null References.

In OOP an object has control ( or should have control ) over the attributes/data of himself.

By setting them to an usable state and controlling how those attributes are modified, the source code prevents using null references ( Initialize with valid values ).

The common mistake is to allow the modification of these attributes with a potentially null reference.

Ej. in Java:

class Customer {
    private final String name; // null at this point 
    public Customer( String named ) {
        if( named == null ) { throw IllegalArgumentException("name cannot be null"); }
        this.name = named; // no longer null and the object has a valid state 
    }

    public String getName(){
        return this.name;// ok 
    }
    public void setName( String newName ) {
        this.name = newName; // eeerh... common programming error if newName = null 
    }
    public int someCalculation() {
        return this.name.length();// NullPointerException 
    }
}

A possible workaround is:

1.- Remove the setter

2.- Validate the setter

public void setName( String newName ) {
    if( newName == null ) { throw new NullPointerException("newName must be not null"); }
    this.name = newName;
}

That is, reject the invalid value, the let know the caller, they are using the object wrong. If the program is to fail, it is much better to fail fast.

One, mistake to try to mitigate this problem is to validate before each call:

public int someCalculation() {
    if( this.name != null ) {  
        return this.name.length();
    } else {
        return 0;
    }
 }

But, its too late, because at that point the object no longer trust its internal data, and that pattern if( x != null ){} will spread all over the place, just making things worst.

Answer 12

When switching between PHP and C♯/Java, I often forgot and write ' instead of " for string constants and end up having compiling errors.

Like:

PHP

<?php
echo 'hello'; // allowed =)

C♯

Console.Write('hello world'); // <- error!

Answer 13

I love the

a =+ 1;

believing that a will be incremented.

Answer 14

Forgetting to terminate a worker thread when a GUI app exits, so the process continues to run, out of sight.

Answer 15

For example, a common error in C/C++ is to use the assignment operator = instead of the comparison operator ==.

And in OCaml language I'm currently using, it's common to use "physical equality operator" == instead of simple "equality operator" =. Ditto for "physical" != and "usual" <>. I'm already used to writing ==, but here I have to wrire =; this is a source of numerous errors.

"Physical equality" means "these two identifiers refer to the same object", contrary to "refer to (possibly different) equal objects". It has synnonyms in other languages as well.

Answer 16

Assuming that default arguments in Python are not shared between function calls.

Answer 17

Catching exception that you don't know how to recover from, or catching a large family of exceptions (or even all exceptions) and not re-throwing when you encounter one that you don't know how to handle.

In .NET, not bothering to look up what exceptions can be thrown in the documentation (or even the intellisense tooltip) and allowing exceptions that you should have caught (and either recovered from or wrapped and thrown) be bubbled up and to a caller who neither expects them nor understands them.

Answer 18

Over reliance on refactoring tools, and code assistance tools (CodeRush / Resharper, etc).

Don't get me wrong, I love CodeRush, but they shouldn't be used solely to write the code.

In my mind a coder should be able to write code, and use them to assist where necessary.

Answer 19

One programming error I've seen a ridiculous number of times: Bad list management.
It usually looks like this:

private void TrimList( List<int> values, int garbageValue )
{
    for (int i = 0; i < values.Count; ++i)  
    {
        if (values[i] == garbageValue)
        {
            values.RemoveAt( i );
        }
    }
}

If you ever see this problem, you'll have to review the whole codebase. You're going to see flavours of this problem in multiple places.

Answer 20

Worst thing I ever saw was a fellow student who wrote something like this:

int main(){

    for(int x = 0; x < 10; x++){
        for(int y = x; y < 10; y++)
            cout << x + y << endl;
            for(int z = 0; z < y; z++){
               cout << x + y * z << endl;
            }
        }
    }

   return 0;
}

and was getting some weird weird errors.

See if you can spot the error...

Answer 21

In managed memory platforms: keeping a reference to an object for more time than it is needed causing memory to grow constantly and thinking that "the garbage collector doesn't work".

I have seen it many times while troubleshooting applications made by programmers new to .NET or Java.

Memory Leaks in Managed code

Answer 22

Directly using variables without defining it in Javascript. Hence variables will have global scope. And programmer spends whole time debugging the scripts!!

Answer 23

A misplaced semicolon beside a while loop.

    while (i < max); // <-- infinite loop
    {
        // do something
        i++;
    }
    // why isn't the code below executing?

Answer 24

Omitting the curly brackets in C#'s switch statement got me once when I first started programming:

Excerpt from Eric Lippert's blog:

Switch blocks also define their own declaration spaces, but switch sections do not:

switch(x)
{
  case OneWay:
    int y = 123;
    FindYou(ref y);
    break;
  case TheOther:
    double y = 456.7; // illegal!
    GetchaGetcha(ref y);
    break;
}

You can solve this problem in a number of ways; the easiest is probably to wrap the body of the switch section in curly braces:

switch(x)
{
  case OneWay:
  {
    int y = 123;
    FindYou(ref y);
    break;
  }
  case TheOther:
  {
    double y = 456.7; // legal!
    GetchaGetcha(ref y);
    break;
  }
}

which tells the compiler "no, really, I want these to be different declaration spaces".

Answer 25

Test using assignment = instead of comparison ==.

if( status = 10 ) {
    doSomething();
} else {
   doSomethingElse();
}

Mhh I wonder we never execute the else part

Answer 26

While taking 101, my teacher and I were combing through a student's program because it wouldn't compile. As it turns out, he used

''

instead of

"

everywhere in his program. Three hours of my life that I will never get back.

Answer 27

Recursive properties in C#:

private string foo;
public string Foo
{
   get { return Foo; }
}

Doesn't happen so often now we have auto-properties, but it's still something I wish the compiler would pick up on.

Answer 28

In .NET languages adding of event handlers multiple times.

This usually comes down to putting the code that adds them somewhere that gets called multiple times.

There are two solutions:

1. Move the code to the constructor (or somewhere where it only gets called once).

2. Remove the event handler when it's completed, as has to be done if handling the event is dynamic (e.g. it only gets added in certain circumstances).

(I am guilty of this one myself).

Answer 29

Character encoding

Working with Unicode: converting to/from/between ASCII/ISO 8859-1/Windows-1252/UTF-8 and other encodings, double encoding, not keeping track across applications, systems, protocols and file formats what encoding textual bytestrings are stored in... the list goes on. Few things are gotten wrong this often.

Very closely related: string escaping and unescaping, the bane of too many websites.

Answer 30

Typos How come no one said anything about typos Are all of them that much confiednt oops did it again