Radu Ghiorghisor

5 Java coding beginner tips

Published on

First published at https://rghiorghisor.medium.com/5-java-coding-beginner-tips-d551dd14aefa

In this article I am trying to touch on just a few pointers that I feel will help Java beginner programmers to smooth their code writing abilities and to become a proficient coder faster.

All of the below ideas are inspired by some of the guidelines I find myself repeating to anyone taking on Java programming and I think that most of them will, or at least they should, pop up during the code reviews in the first months of professional work. At first, they might seem overwhelming but, like any other best practice in writing code, they will need repetition to get used to and become part of your developing second nature.

I am staying away from technical topics, like ArrayList vs. array, as I think they are easier to deal with, as they represent punctual answers to specific questions, and internet’s responses will be better and more comprehensive than some generic esoteric tips.

Below we will take a look at:

Respect code standards

When starting programming, how the code looks may not seem an important aspect of one’s work, how it behaves is after all what matters. But the fact is both of them are equally important and not respecting some of the industries widely accepted conventions will affect how others perceive the work.

There IS a difference between using not using proper accepted spacing and implementing your own conventions.

A reference that I have always recommended is Google’s Java Style Guide. Besides coding standards it also depicts some interesting cases that programmers should be aware, making it a great read.

Don’t be afraid to create classes/packages

Sometimes, new programmers live under the assumption that, because they are new to the project or to programming overall, they are not allowed to make such additions.

There is no career level after which one is allowed to add classes to the project. Hence, if you feel that new classes are needed to make the code cleaner, create and use them. While taking these decisions, please make sure to:

Don’t name classes just to have a name

We, as developers, constantly need to worry about properly naming variables and, by extension, classes and packages. By referring to the name of a class, one must infer what is its purpose.

That is the reason why Manager or Processor words in class names is not a great idea.

We all know that using such name post-fixes is the easy way out. Having an EntityManager class that offers operations for the Entity objects might seem as the perfect name. The problem with this approach is that EntityManager is not a meaningful name, as it states pretty much nothing about what the class does, other than some sort of management. But other classes that use or modify Entity instances don’t they also manage entities?

And if you feel bad for not finding proper naming faster, remember that we are all in the same boat. From David Karlton’ blog (and all the corners of the internet where developers are): “There are only two hard things in Computer Science: cache invalidation and naming things”.

A lot of class and variable naming advice can be picked up from Robert C. Martin’s Clean Code: A Handbook of Agile Software Craftsmanship, and I advise anyone to go through it at least once in their career.

Don’t let exceptions unhandled

A now famous good practice, it states that all exceptions must be treated and catch blocks must not be left empty. Silently swallowing exceptions is generally a situation to avoid because your code might not work as expected but is unable to signal this. In many cases, treating exception in the catch block involves at least one of the following actions:

  • Logging the exception;
  • Rethrowing the same exception or a new wrapped one.

At the same time, some exceptions should not clog up the log (console) or be rethrown.

In this example, the someObject.doSomething(String) call might throw an exception, or it may not, but to someone taking a look on the code the reason why the exception is not visible.

In Effective Java— Item 77: Don’t Ignore Exceptions, Joshua Bloch says that “If you choose to ignore an exception, the catch block should contain a comment explaining why it is appropriate to do so, and the variable should be named ignored “.

In conclusion, if you find yourself in a situation in which a catch block should be left empty:

  • Double check if no handling is required or if the situation can be prevented;
  • Rename the exception variable to properly express the real intent;
  • Include a comment and explain why this approach was decided on.

Unit tests are for functionalities not classes

Hopefully this will answer the question “Must I test private/abstract classes/interfaces?”

When writing unit tests for a class you must test what that class offers in terms of functionality, not what is the classes organization behind that practicality. Private methods or super classes support the tested class to perform a certain task, therefore those protected levels must be tested by calling the tested class.

Therefore, you should not write specific tests for private, protected methods or abstract classes. Their functionality must be tested by means of classes that employ them.Thank you for reading these words and I hope you find some guidance in them. I am just going to leave this here:

One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand. Robert C. Martin — Clean Code: A Handbook of Agile Software Craftsmanship

Creative Commons License

This work is licensed under a Creative Commons Attribuition-ShareAlike 4.0 International License .