7 Tips to Write Better Java Code You Should Know

Yes, you can write short, clean Java code following these seven tips and tricks. Some of them might surprise you, but trust me, they are proved practices — at least by me.

1. Use IntelliJ IDEA as Your IDE

I’ve been using Eclipse for six years and NetBeans for three years. I still use them sometimes, but most of the time, I use IntelliJ IDEA only. I don’t want to start the holy war of IDEs here, but I just want to tell you IDEA will remind you to write shorter, better, cleaner code based on its integrated best practices. You just press ALT+Enter, and it will do the job for you. Most of the time, IntelliJ IDEA gives you smart and practical advice; you can also learn a variety of new information from them.

To make good use of IDEA, you’d better get an SSD, at least I did — my old laptop cannot run IDEA smoothly. Just a 256GB Samsung SSD will make your life much better. It’s a worthy investment if you are still using HDD.

2. Use JDK 8 or Higher Version

From JDK 8 and later, many new features introduced will allow you to write shorter and more expressive code, including lambda expressions, functional interfaces, stream APIs, and more. You don’t need to remember them actually, as IDEA will assist you to use this features, that’s another reason why you should use IDEA. “Java 8 in Action” might be of some help to you.

3. Use Maven/Gradle

Use Maven or Gradle to manage dependencies, builds, and deployment for your projects. If you have built many fundamental libraries to be reused among many projects, you’d better introduce Nexus if these libraries will be used internally only. Otherwise, you can deploy them to the Maven central repository.

4. Use Lombok

Say goodbye to the boilerplate code of setter/getter, hashcode/equals, and constructors/toString. Just one annotation — @Data — will work. Lombok reduces the code you write, but it also takes care of the generated bytecode.

5. Write Unit Tests

What? Are you serious?

Yes, I am. Testable code is usually organized better and cleaner, as it will drive you to manage the relationship of classes, the access level of methods, and other stuff well beforehand. I’ve found that even minimum unit tests will make development much faster and easier, which always drives you to write shorter, cleaner, and better code.

However, you will always hear opposing opinions that “I don’t have time to write unit tests" or "it’s a waste of time as the deadline is approaching.” It sounds true, and sometimes, it is true. But most of the time, from my experience, I found it’s not. If you don’t have time to write unit tests, you will “have” more time to fix bugs visible or invisible, without the quick feedback of the unit test, stability of code, and new changes that usually decrease, and sometimes, you may need to pray earnestly as you really don’t know what will happen or how many new bugs will be introduced.

Maybe some genius programmers can write bug-free code without unit tests. But I am not, and you probably are not, too. So just do it — trust me.

JUnit and TestNG would both work; though, I prefer TestNG.

6. Refactoring: Frequently but Slowly

Shorter, cleaner code cannot be done at once; it needs iteratively improvements. Refactor little by little and run test cases to make sure your change didn’t break the right behavior of the code. Things will get better and better. IDEA provides great refactoring support, such as extract method, rename, inline, and more.

Martin Flower’s book “Refactoring: Improving the Design of Existing Code (2nd Edition)” is a must-have if you have no idea what refactoring is and want to learn more.

7. Visit Customer Regularly and Get Feedback From Them

Honestly, this should be at the top of the list, but in this case, “the best will be last” here. You write code to resolve customer’s problems, to meet their requirements, and to remove their pain points. Sometimes, you wasted too much time implementing features and functions that are unnecessary. But how can you know that earlier? Keep in touch with customers regularly so that you can get their feedback as early as possible. However, this is not as easy as you think, even experienced product managers cannot get the message in a short time, even less than programmers who mainly focus on implementing.

A practical suggestion is, if you cannot reach customer directly, you should connect to your product owner frequently and talk about your concern clearly but also politely; this will save alot of time.

I’ve found these seven tips extremely useful over the past few years, and I hope they will help you, too. Happy coding!