Programming Mistakes to Avoid

Discussion in 'Web Development and Programming' started by Monster, Dec 7, 2010.

  1. Monster

    Monster Admin Talk Staff

    Joined:
    Apr 24, 2004
    Messages:
    515
    Likes Received:
    82
    Location:
    Germany
    Slashdot has a thread about an InfoWorld article (print version) about common programming mistakes and how to avoid them.

    The article is written from a journalist point of view, but does contain some valuable information.

    Perhaps we can make this a thread to collect information about programming mistakes and how to avoid them.

    I'll begin with a list of my own:
    • In procedural programming, make sure that every return value from every function call is checked.
    • In object-oriented programming, throw exceptions for serious errors, but use return values for errors that occur frequently. Exception handling does come with a performance hit, and is intended mainly for serious errors.
    • In object-oriented programming, make sure that each class does only one thing. Avoid tangled objects, b/c that'll make your code look like a ball of wool.
    • In object-oriented programming, if you use design patterns, make sure you understand what's happening underneath.
    • Check all function arguments for validity.
    • In C++, use the automatic cleanup feature by encapsulating objects and instantiating them on the stack. This is especially handy when exceptions occur.
    • In object-oriented programming, avoid null references or null pointers, or you'll have to deal with extra checks.
    • Make sure instances of container classes contain valid objects.
    • Define interfaces well, and provide a way for expansion that doesn't need additional function arguments, or you might end up having to modify your code in many places. An ill-designed interface can break client code that calls it when something is modified.
    • Don't debug into the code of hash table implementations when you don't know what a hash table is. Once I read an interesting article that this is the most time-consuming problem in Java development: N00b programmers that think Java's hash table implementation is broken, then introducing bugs in the code b/c they don't understand it.
    • If you're reinventing the wheel, make sure yours is better and works as designed.
    • For [****][****][****][****]'s sake, read the [****][****][****][****]ing documentation of the libraries you're using if you don't want to look like a complete moron. Often, the documentation will contain valuable information. You'll save yourself countless hours of pointless debugging and bugfixing.
    • Don't rule out compiler bugs. I've heard many an idiot say "there's no such thing as compiler bugs" or "the compiler has been used everywhere, it must be bug-free". In reality, almost all compilers do have bugs, and lots of them. If you encounter a strange problem, look at the assembly code generated by the compiler. Most programmers don't notice these problems at all, b/c they simple rework the code until it magically starts working.
    • Don't use C++ if you're unaware of the implications: C++ is a large, complex language (in fact, the most large, most complex language there is), and hence C++ compilers tend to have many bugs, subtle incompatibilities and other funstuffs you'll discover as soon as you try to move your code between platforms, compilers or to a new compiler version. There's a good reason why most open-source code (for Linux etc.) is written in C, not C++.
    • C++ integrates the C standard. It is a common misconception that you must write object-oriented programs when using C++. Programmers that are indoctrinated such are in for a surprise when they have to deal with less academic, more real-world code. This is also a source of countless bugs, coming from programmers that are familiar with the C++ aspects but not the C aspects of the C++ language.
    • Always try to document and comment your code already during programming. Oftentimes, you'll discover that your idea of a concept and your implementation of it differ. If source code isn't documented, it is often a sign of the code quality. People saying the source is the documentation are morons that should be replaced. Code they've written most likely has to be rewritten as soon as they leave.
    • If you're in a hurry, don't introduce warts into the code. If you absolutely have to, make sure you remove them later on if you find the time. But this is the source of most of the worst spaghetti code.
     
  2. Brandon

    Brandon Regular Member

    Joined:
    Jun 1, 2009
    Messages:
    6,602
    Likes Received:
    1,706
    Location:
    Topeka, Kansas
    First Name:
    Brandon
    great list and great advice

    I'm guilty of not documenting my work all the time :(
     
  3. Cerberus

    Cerberus Admin Talk Staff

    Joined:
    May 3, 2009
    Messages:
    1,031
    Likes Received:
    500
    I am the same way..I never document anything I do..I really should make that a habit..Though I have been using C# mostly lately trying to learn its not going well, but nice list.
     

Share This Page