Programming Mistakes To Avoid

snydeq writes "InfoWorld's Peter Wayner outlines some of the most common programming mistakes and how to avoid them. 'Certain programming practices send the majority of developers reaching for their hair upon opening a file that has been exhibiting too much "character." Spend some time in a bar near any tech company, and you'll hear the howls: Why did the programmer use that antiquated structure? Where was the mechanism for defending against attacks from the Web? Wasn't any thought given to what a noob would do with the program?' Wayner writes. From playing it fast and loose, to delegating too much to frameworks, to relying too heavily on magic boxes, to overdetermining the user experience — each programming pitfall is accompanied by its opposing pair, lending further proof that 'programming may in fact be transforming into an art, one that requires a skilled hand and a creative mind to achieve a happy medium between problematic extremes.'" What common mistakes do you frequently have to deal with?

Comments

Tests, Manual, Support by programmer.

[Barryke]

What common mistakes do you frequently have to deal with?
- Software only tested by programmer.
- Manual only written by programmer.
- Support can't do a day without programmer.

A good programmer should know when to delegate. Or their boss should. Depends on office culture perhaps.

Missing from the article

[eagleyes]

The most common programming mistake to avoid: Reading badly written articles about "what programming mistakes to avoid".

Re:do x but not too much!

[Chrisq]

Doesn't mistake number 2 contradict number 1? Or am I missing something?

The whole lot is full of contradictions:

4: Delegating too much to frameworks 8: Reinventing the wheel
9: Opening up too much to the user 10: Overdetermining the user experience
5: Trusting the client 6: Not trusting the client enough

I think that there is a meta-message, akin to Buddha's middle way. Don't take any rule to extremes.

Re:Programming Mistake #0

[digitig]

True enough. And since every rule has to have a complement, 0a: Assuming that you don't need to learn any of that theory: algorithms, data structures, normalisation and so on

Re:Maintaining code by others are always a nightma

[BiggerIsBetter]

There will however always be BAD code by bad programmers. I've taken over Java progress where everything was OOP'ed into hell (as in a bazillion classes more than was needed for the application) and PHP projects which should be OOP'ed but consisted of about 500 files that included each other in a huge confusing net.

I see this one as a lack-of-experience problem. People have good intentions and want to build scalable, extensible, maintainable code. This is good. Unfortunately however, they're wrong. The apps they're building are small irregardless of the amount of thought they put into them, and they won't have to scale and extend the way they think they might - you don't need interfaces and impls and arbitrary inheritance for everything when the webapp is 4 screens of Spring WebFlow! Sure, if you're building something that warrants it, this is the way to go, but most of aren't building apps that big or flexible. It seems to take time to learn this, and to know when to apply the patterns and when to just build it.

As a smarter man than I once said, Make things as simple as possible, but no simpler. If you do that, your code will work, it'll be understandable by the next guy, and you'll have a fighting chance of meeting your deadlines.

Don't get me started

[mrjb]

Don't get me started on preventing programming mistakes. If I'd address the most common programming mistakes that I've ran into in the wild and write an article about each of those mistakes at a time, I would end up with a whole book on the matter and would probably call it "Growing Better Software".

I find the given top 12 list of mistakes a bit weak- I'd be able to avoid all of these and yet write horrible code. My personal recommendation for a top 12 of programming mistakes to avoid would be:

1. Failing to check function parameters before using them: null pointers, limits, lengths, etc. This will make your program unstable and/or unpredictable.

2. Spending too little time thinking about and designing the data structure of the application. This will make you get stuck when maintaining/extending your application.

3. Following every market hype - When the marketing bubble bursts, you'll have to start over again.

4. Designing user interfaces without actually involving users - You'll be surprised how easy it is to confuse users.

5. Infinitely deeply nested if/else statements - This will make code absolutely unreadable.

6. No documentation whatsoever - Who's going to maintain your code after you change jobs?

7. Ignoring existing, universally accepted standards - so you'll cause interoperability issues or be doomed to either reinvent the wheel.

8. Hard-coded values/magic numbers - as a result, any change must be made in code rather than allowing power users to configure their own system.

9. Littering code with global variables - this implies statefulness of code, making it pretty near impossible to predict how a function will behave next time it is called.

10. Being unaware of the "Big O" order of your algorithms, causing code to be unnecessarily inefficient.

11. Strong platform dependency: This can shorten the lifetime of your application to whenever the next platform upgrade takes place, or keep you stuck at the current version of the current platform forever.

12. Thinking you can figure out everything by yourself - In learning by doing, experience can only follow from making mistakes. By getting yourself a mentor or an education, you can actually learn from the mistakes that thousands have made before you.

13. Stopping at 12.