This is part 3 of my guide to writing better code

This is the inverse of Hazard 2: "But I've always done it that way". You learn about a new approach to solving a problem and you get excited about the possibilities.

Warning signs

You have become stuck in this hazard if you're learning about a new programming practice/approach and you:

• Rush to implement it everywhere
• Don't consider where or even if it is applicable
• Get blinded by the novelty and fail to see any potential downsides of the approach

...everything is a nail

If you've been doing something the same way for a few years and someone links you to an article about a different approach it's easier to quickly see the benefits than the drawbacks: I can put my configuration in comments rather than XML Files? COOL!.

In fact, it's usually not until you've tried something for yourself that you fully understand it and run into problems the approach causes. How long were you using global variables for before you encountered the issues they cause?

I'm not trying to dissuade you from trying new things, after all, it's the best way to learn. But don't get enamoured a fancy new approach, it is likely to come back and bite you on the ass unless you've done your research. Annotations, Static Methods, Singltons. All these things look exciting when you first come across them, it doesn't take long to realise they're not as wonderful as you first thought.

When you learn about a new practice you inevitably look for places to try it out. The saying "when all you have is a hammer everything looks like a nail" comes to mind.

When marking students' work I can tell if they just learned about something new. If I see an assignment full of static methods, I know the student just learned about them. Full of singletons? The student just learned about them. Every if statement has been replaced with a ternary operator? Yep, the student just discovered it.

Any time I see a practice used everywhere I know that the developer just learned a fancy new tool and wanted to try it out. Code can read comments? COOL! Don't get caught up in the excitement of learning a new practice. Often these practices are shortcuts which actually make your code worse in the long run.

This is probably the trickiest hazard to avoid because it's very difficult to see whether a new approach is beneficial or detrimental until you try it and have to maintain the code using the approach.

Conclusion

Remember the 90% of everything is crap hazard and look into the pros and cons of practices before you implement them.

Always be skeptical of practices that look exciting to start with, they'll often come back to haunt you.