Java best practices

11 August 2007, by: Arjan Tijms

Within Mbuyu, the company I work with, one of the things I’m responsible for is guarding the quality of our code base. This job mainly involves reading through source code and marking dubious constructs and practices. In the past I’ve been doing quite similar things at other locations.

Over time I came across a number of bad practices that seem to be repeated over and over. Many of those originate from people who are just beginning their Java career; new employees, interns etc. Surprisingly, even some more experienced Java developers sometimes sin on these seemingly straightforward rules.

Of course, there is a subjective factor involved here. People actually differ on what is a best practice and what is not. Anyway, without further ado, let’s start with a list of some common bad practices:

Due to the size of the discussion, I shall discuss only the first 3 items of this list today and leave the rest to a follow-up posting.

Not using types

This may sound like a weird bad practice in Java. After all, Java is a strongly typed language, so how can we not be using types when the compiler enforces them? Actually, there are at least two ways around the type system; make everything a String or make everything an Object.

This first option is common in plain JSP programming; data enters the application from request parameters as Strings and developers simply don’t care to convert them to some data type. Instead, business logic methods are written to take Strings and layer upon layer only Strings are passed around. It seems insane to do this, but I’ve actually seen people doing stuff like this for years(!).

The second option is nowadays less common, although it sometimes shows up in JDBC programming; programmers do not exactly know what Java types correspond to SQL types so they just call getObject(); and pass the data along. Probably they’re hoping the next guy will somehow magically know to which type the Object needs to be casted.

Before the introduction of generics in Java 5, the second option was very pervasive in Java code though. At that time there simply was no way to store anything in a collection without resorting to using Object. It couldn’t however really be called a ‘bad practice’ by then, since there was really no sane way to circumvent the problem.

Not validating user input

Not validating user input is one of the most common bad practices I’ve encountered. It gives rise to a whole slew of problems, ranging from SQL injection, to cross-site scripting and excessive exception throwing. For instance, many beginners don’t seem to realize that Javascript validations don’t protect your server from malicious users who can (of course) just send data to your server directly, bypassing any Javascript validation you may have in place.

A more subtle form of this bad practice is when a programmer doesn’t validate if data conforms to business rules right when it enters the system. Instead, such a programmer validates data at some other point in time, perhaps when the data is actually used. Of course, it’s often too late then to correct matters and afterwards the location which allowed for this invalid data is hard or impossible to find.

Mixing business logic and view code

Not separating business- and view code is another frequently encountered practice. It’s a major cause of creating spaghetti from code, which makes bug fixing and applying changes much harder than they should be. This bad practice is especially common for people with a PHP background, where the community more or less seems to encourage this practice (or at least doesn’t discourages it as much as in e.g. the Java or .NET communities).

One major problem with this bad practice is that beginning developers don’t always want to adopt a more sane MVC approach. It’s very much true that the MVC pattern may be overkill for small applications. However, many larger applications tend to be grown out of smaller ones. On top of that, for a new programmer the one or two pages he makes at first often seem to be the entire world, even when the application which is going to include these pages already has perhaps 500 other ones. Seeing the rest of the world is a skill often learned only over time.

For Java EE, an early effort by Sun to gently push the programmer into this MVC model was JSTL. In JSTL the programmer is presented with a number of tags and an expression language (EL) to define the rendering. JSTL contains conditionals, variables, and looping constructs. It should be very clear that these are solely meant to be used for rendering and nothing else. Or isn’t that so clear? A couple of years ago I asked one programmer to stop putting business logic in JSP pages using Java scriptlets and start using JSTL. After putting up some initial resistance, he finally agreed and went back to his work. When I looked through his next CVS commit, I was in for a surprise though. All the business logic was still exactly there in the JSP page, but this guy had simply rewritten the Java scriptlet code into JSTL tags! Needless to say that expressing business logic in the view layer through JSTL is an even worse practice.

Well, I’ll leave it to that today. Continue with the next installment here

Arjan Tijms 

15 comments to “Java best practices”

  1. developer says:

    It’s very helpfull, Looking forward to the following parts 🙂

  2. prashant says:

    Good article.

  3. Hazem Ahmed Saleh says:

    In some times, you may need to mix JSTL with JSF code.
    Check JSF 1.2 specs.

  4. arjan says:

    Hazem, I absolutely agree with you. Just mixing JSTL and JSF is not a bad practice by itself. The emphasis however is on -sometimes-. Sometimes its ok, sometimes its not. In one of the next installments of this blog I’ll discuss a case where its not ok.

  5. Sam says:

    What annoys me is people not copying the style of existing code.  So what if at your last job you put an I at the start of all your interfaces, its pretty easy to see thats not done here.  Totally aside for the argument of if thats a good or bad idea, its always going to be a bad idea to have n styles of coding.

  6. arjan says:

    Good point to mention Sam! It’s indeed one of the things I look for when checking source code. A consistent coding style is often much easier on the eyes and more pleasant to use.

    A consistent API is also much easier to learn for new people and often faster to debug.


  7. links for 2007-08-14 « My Weblog says:

    […] Over Java development en vacatures voor Java software specialisten » Java best practices (tags: java) […]

  8. Over Java development en vacatures voor Java software specialisten » Java best practices 2 - Explicit cases says:

    […] Java best practices 2 – Explicit cases augustus 15, 2007 on 9:58 pm | In Java | […]

  9. JAVA development en vacatures voor Java software specialisten » Java best practices 3 - Eating Exceptions and Mixing JSTL with JSF says:

    […] Java best practices 3 – Eating Exceptions and Mixing JSTL with JSF augustus 26, 2007 on 11:35 pm | In Java | […]

  10. JAVA development en vacatures voor Java software specialisten » Java best practices 4 - Native Arrays and Not Using Java 5. says:

    […] Java best practices 4 – Native Arrays and Not Using Java 5. september 3, 2007 on 3:47 pm | In Java | […]

  11. JAVA development en vacatures voor Java software specialisten » Java best practices 5 - Code to Interface, Access by name and Instance Data says:

    […] Java best practices 5 – Code to Interface, Access by name and Instance Data oktober 7, 2007 on 7:17 pm | In Java | […]

  12. Madhu says:

    very good article. which is very much help ful for me.thanks

  13. sandeep says:

    very nice article. you’ve explained in a good way.

    Java best practice quotes

    sandeep kumar

  14. Peter McElroy says:

    Well, there is nothing wrong with passing strings around. They are easy to handle don’t pollute the heap with objects.

    PS: My dog farted

  15. asad says:

    This blog awesome and i learn a lot about programming from here.The best thing about this blog is that you doing from beginning to experts level.

Type your comment below:

Time limit is exhausted. Please reload CAPTCHA.

css.php best counter