Programming antipatterns

 

Did you ever do a code review where you recorded an extremely high amount of WTF/m? And did you ever wonder what the cause of all this bad code is? Most of the time cause number 1 are the use of design and coding antipatterns.

If you like definitions, here is one: An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences. The AntiPattern may be the result of a manager or developer not knowing any better, not having sufficient knowledge or experience in solving a particular type of problem, or having applied a perfectly good pattern in the wrong context.

Reinventing the wheel

IMO an antipattern of frequent occurrence is the lack of knowing the existence of some useful frameworks/libraries. Apache commons lang and commons collections are dependencies that should be present in every Java project.

You can write your own fancy for loop for filtering or selecting some objects in a collection or you can use CollectionUtils.select(…) or CollectionUtils.filter(…).

You can do some fancy not null checks ending up with a huge if-else construction or you can use StringUtils.isNotBlank(…). It’s up to you.

A general rule is not trying to reinvent the wheel. Some people like to write their own Reflection utils while Apache commons beanutils, Spring’s BeanUtils and BeanWrapper will do the trick.

Cargo cult programming

Cargo cult programming is a style of programming in which patterns and methods are used without understanding why. The term “cargo cult”, originally referred to aboriginal religions which grew up in the South Pacific after World War II. The practices of these groups centered on building elaborate mock-ups of airplanes and military landing strips in the hope of summoning the god-like airplanes that had brought marvelous cargo during the war.

Most of the time this way of programming is used by unskilled or unexperienced programmers that copy-paste some code from somewhere else.
Examples:
– adding unnecessary comments to self-explanatory code
– adding deletion code for objects that garbage would have collected automatically with no problem
– creating factories to build simple objects

Coding by exception/Expection handling

Instead of checking for some specific corner case values like null values, some people like to catch a NullPointerException and do some logic in the catch block. This way of coding is called expection handling because the exception is expected to happen.

Exceptions are invented to inform you of the fact that something really bad happened but they’re not meant to be thrown often. That’s why they are called ‘exceptions’. If they occur, please handle them carefully but never abuse them to execute some logic that could have been implemented with a simple if-else check.

Avoiding/swallowing exceptions

Referring to the previous antipattern, when an exception is thrown that means that something unexpected happened. The last thing you should do is swallow these exceptions instead of processing its useful information.

For example, if you have a method that should only return 1 object because you expect it be unique, perfoming a DB query that returns a list of results, checking if the list’s size equals 1 and then performing a query that can only return 1 unique result (if not an exception is thrown). If you’re implementing something like that, it means that it could be possible that the expected object is not unique which means that implementation differs from what the analysis says.

Inheritance hell

Inheritance should be handled with care. It’s very useful but you should only use it what it’s intended for. If the inheritance tree becomes to bloated, something is wrong. Do not write abstract classes for 1 specific case. Use composition instead. The strategy pattern can come in handy here.

For example if your JSF managed bean ‘EditUserManagedBean’ extends AbstractEditingManagedBean which extends AbstractSelectionManagedBean which extends AsbtractParentDetailManagedBean which extends AbstractManagedBean you should know that something is wrong and that there should be other ways to implement this behaviour ;-)

Gold plating & Premature optimization

Some people like to enhance their code by continuing to work on it well past the point where the extra effort is adding some value instead of sticking to the requirements. The mistake made here is thinking the end user would be much more delighted to see the additional or enhanced features in the product, than what the user asked for or expected. The user might be disappointed in the results, and the extra effort by the developer might be futile. This process is referred to as gold plating.

Gold plating is related to premature optimization. Premature optimization refers to thinking about possible issues that could arise in the future but that are not the case at this moment. You should only think about what is asked and what is required, not about what eventually could be useful for future purposes. A frequent occuring premature optimization is the premature performance optimization. If there are no preformance issues at this moment, do not try to handle them, handle them when they happen.

References 

 

Related Articles :

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

2 Responses to "Programming antipatterns"

  1. chris says:

    Thank you for demonstrating why reinventing the wheel isn’t such a bad thing.

  2. Husoski says:

    My $0.02 on so-called “Gold Plating” is that it sounds better when you call it “flexibility”, and it works better when it’s done well and software costs are measured over the lifetime of an application.

    The practice of only considering immediate requirements with no thought to the future leads to brittle code that is hard to maintain (and was the bane of my junior programming years, spent modifying code that wasn’t written to be modified!)

    Single-purpose code should be the product of optimization. I’m all in favor of throwaway code there, with a general “reference implementation” that the optimized code should match within limits of the requirements. Then, custom solutions for filters and such aren’t such a bad idea. If it’s a killer to revert to the “reference implementation” upon change of requirements, then the optimized implementation was probably a Good Idea.

    OOP adds really nice tools for doing this without going crazy, but the ideas are more fundamental, going back to pre-structured days and tested in both applications in nice compiled languages to assembly for OS components and tightly-constrained embedded apps.

Leave a Reply


seven − = 3



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close