
In my last post about [common Java violations][1], I listed a set of mistakes that java developers tend to make. While refactoring a Java project with the objective to resolve those violations, I used the refactoring features of Eclipse extensively to quickly change the code. Below is the compilation of such refactoring techniques.

[1]: https://veerasundar.com/blog/common-code-violations-in-java "common code violations in Java"

## 1. Adding curly braces around block level statements

It is often a good practice to wrap the block level statements with `{curly braces}`. But still, if there is only one statement in the block, then some developers prefer not to wrap them with `{}`. But Checkstyle will complain if you do so.

If you want to change this,

```java
    if(condition)
        doSomething;
```

to this:

```java
    if(condition){
        doSomething();
    }
```

Eclipse's **source cleanup **is there for your help.

1.  In *Project Explorer, *right click on the source folder and select *Source -> Clean up'¦*[![using source clean up to add curly braces around block statements][3]][3]
2.  Choose *Use custom profile *and then click *configure *next to the custom profile section.
3.  By default, clean up action is configured to do multiple cleanup task. Since we are focused only on adding curly braces, we will disable all other cleanup tasks. To do this, navigate to all the tabs in the *Custom Clean ups *window and deselect all the cleanups.
4.  Then in the *Code Style *tab, select the *Use blocks in if/while/for/do statements *option and click *OK.*
5.  Then in *Clean Up *dialog, click *Next *and the refactoring will occur. You'll be presented with a review page with the changes made.

[]: https://veerasundar.com/img/2012/10/use-block-statements.png

## 2. Joining to if statements into one

Lets say, you have a code like this:

```java
    if(isLoggedIn){
      if(isAdmin){
        doSecretStuff();
      }
    }
```

It is safe to combine the two _if_ statements into one, unless you have some other code in between the two *if *statements. Of course, you can manually edit the code to remove the second if and move the condition to up. But wait, when Eclipse can do this for us, why should we do it ourselves?![Join inner if statement with outer if statements][3]

[3]: https://veerasundar.com/img/2012/10/join-if-statements.png "join-if-statements"

1.  Place your cursor on the *if *keyword of the inner *if *statement.
2.  Press *Ctrl 1 *which will open a context menu.
3.  Select the option *Join 'if' statement with outer 'if' statement*.
4.  Voila! the two if statements are now combined into one.

You'll get:

```java
    if(isLoggedIn && isAdmin){
      doSecretStuff();
    }
```

## 3. Renaming a filed and its getter / setter methods

According to a [this][4], renaming an element is the mostly used refactoring in Eclipse. So, when you rename a field which has setter/getter methods, you'd manually rename those method names. But Eclipse can help here to simplify this.[![][6]][6]

[4]: http://stackoverflow.com/a/1858592/42372 "Eclipse: Most useful refactorings"

[]: https://veerasundar.com/img/2012/10/rename-field-getter-setter.png

1.  Place your cursor on the field name that you want to rename.
2.  Press *Ctrl Shift *and then press *R key *two times continuously which will open the '*Rename Field' *dialog box.
3.  Check the options 'Rename getter' and '_Rename setter'_ while providing a new name to your field.
4.  On clicking OK, this will rename the field as well as its getter/setter methods.

## 4. Inverting *if *statement

Suppose you have a code like this:

```java
    if(!isLoggedIn){
      // ask to login
    }else{
      // allow access
    }
```

Above code is 100% valid. But code quality tools such as Checkstyle might complain, because we are using a negativity check in the first condition (i.e. *!isLoggedIn*). When you have only one case (just the if block), then we can't do much about it. But when you have both *if *and *else*, then you can just invert the conditions to avoid this scenario.

1.  Place your cursor on the first *if *keyword.
2.  Press *Ctrl 1 *and then select *Invert 'if' statement*.
3.  Eclipse will invert the conditions and the corresponding blocks.
4.  Finally, you'll get:
    if(isLoggedIn){
    // allow access
    }else{
    // ask to login
    }

Helps to improve the readability of the code.

## Conclusion:

Of course, the above are just the tip of the iceberg. Eclipse is capable of doing much-more advanced refactoring. So, what are **your** secret refactoring techniques?


Eclipse refactoring on steroids


At work, recently I did a code cleanup of an existing Java project. After that exercise, I could see a common set of code violations that occur again and again in the code. So, I came up with a list of such common violations and shared it with my peers so that an awareness would help to improve the code quality and maintainability. I'm sharing the list here to a bigger audience.

The list is not in any particular order and all derived from the rules enforced by code quality tools such as [CheckStyle][1], [FindBugs][2] and [PMD][3].

[1]: http://checkstyle.sourceforge.net/ "Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard"
[2]: http://findbugs.sourceforge.net/ "Find bugs in java program"
[3]: http://pmd.sourceforge.net/ " source code analyzer"

Here we go!

## Format source code and Organize imports in Eclipse:

Eclipse provides the option to auto-format the source code and organize the imports (thereby removing unused ones). You can use the following shortcut keys to invoke these functions.

- **Ctrl Shift F** - Formats the source code.
- **Ctrl Shift O** - Organizes the imports and removes the unused ones.

Instead of you manually invoking these two functions, you can tell Eclipse to auto-format and auto-organize whenever you save a file. To do this, in Eclipse, go to **Window -> Preferences -> Java -> Editor -> Save Actions** and then enable **Perform the selected actions on save** and check **Format source code** **Organize imports**.

## Avoid multiple returns (exit points) in methods:

In your methods, make sure that you have only **one exit point**. Do not use returns in more than one places in a method body.

For example, the below code is **NOT RECOMMENDED** because it has more then one exit points (return statements).

```java
    private boolean isEligible(int age){
      if(age > 18){
        return true;
      }else{
        return false;
      }
    }
```

The above code can be rewritten like this (of course, the below code can be still improved, but that'll be later).

```java
    private boolean isEligible(int age){
      boolean result;
      if(age > 18){
        result = true;
      }else{
        result = false;
      }
      return result;
    }
```

## Simplify if-else methods:

We write several utility methods that takes a parameter, checks for some conditions and returns a value based on the condition. For example, consider the **isEligible** method that you just saw in the previous point.

```java
    private boolean isEligible(int age){
      boolean result;
      if(age > 18){
        result = true;
      }else{
        result = false;
      }
      return result;
    }
```

The entire method can be re-written as a **single return** statement as below.

```java
    private boolean isEligible(int age){
      return age > 18;
    }
```

## Do not create new instances of Boolean, Integer or String:

Avoid creating new instances of Boolean, Integer, String etc. For example, instead of using `new Boolean(true)`, use `Boolean.valueOf(true)`. The later statement has the same effect of the former one, but it has improved performance.

## Use curly braces around block statements.

Never forget to use curly braces around block level statements such as _if_, _for_, _while_. This reduces the ambiguity of your code and avoids the chances of introducing a new bug when you modify the block level statement.

**NOT RECOMMENDED**

```java
    if(age > 18)
      result = true;
    else
      result = false;
```

**RECOMMENDED**

```java
    if(age > 18){
      result = true;
    }else{
      result = false;
    }
```

## Mark method parameters as final, wherever applicable:

Always mark the method parameters as _final_ wherever applicable. If you do so, when you accidentally modify the value of the parameter, you'll get a compiler warning. Also, it makes the compiler to optimize the byte code in a better way.

**RECOMMENDED**

```java
    private boolean isEligible(final int age){ ... }
```

## Name _public static final_ fields in UPPERCASE:

Always name the _public static final_ fields (also known as _Constants_) in UPPERCASE. This lets you to easily differentiate constant fields from the local variables.

**NOT RECOMMENDED**

```java
public static final String testAccountNo = "12345678";
```

**RECOMMENDED**

```java
public static final String TEST_ACCOUNT_NO = "12345678";
```

## Combine multiple _if_ statements into one:

Wherever possible, try to combine multiple _if_ statements into single one.

For example, the below code;

```java
    if(age > 18){
      if( voted == false){
        // eligible to vote.
      }
    }
```

can be combined into single _if_ statements, as:

```java
    if(age > 18 && !voted){
      // eligible to vote
    }
```

## _switch_ should have _default_:

Always add a _default_ case for the _switch_ statements.

## Avoid duplicate string literals, instead create a constant:

If you have to use a string in several places, avoid using it as a literal. Instead create a String constant and use it.

For example, from the below code,

```java
    private void someMethod(){
      logger.log("My Application"   e);
      ....
      ....
      logger.log("My Application"   f);
    }
```

The string literal 'My Application' can be made as an Constant and used in the code.

```java
    public static final String MY_APP = "My Application";

    private void someMethod(){
      logger.log(MY_APP   e);
      ....
      ....
      logger.log(MY_APP   f);
    }
```

## Additional Resources:

- A collection of [Java best practices][4].
- List of available [Checkstyle checks][5].
- List of [PMD Rule sets][6]

[4]: http://www.javapractices.com/home/HomeAction.do
[5]: http://checkstyle.sourceforge.net/availablechecks.html
[6]: http://pmd.sourceforge.net/rules/index.html


Common code violations in Java


Constants are the constant things in a project. I mean, it is safe to assume that any project would have some kind of constant values used across the code.

The common practice in Java is to declare them as public, static and final variables so that they can be easily referenced wherever they needed.

Here's a list of patterns that I have seen on using such constants.

## 1. Define a Constants class

In this approach, you define a class 'Constants' and put all your constants inside this class. Then reference the constants as 'Constants.CONST_NAME' wherever needed. Easy as it looks.

```java
    public class Constants {
    	public static final String SITE_NAME="veerasundar.com";
    }

    class Hello{
    	public void someFun(){
    		System.out.print(Constants.SITE_NAME);
    	}
    }
```

But the con of this approach is that you need to prepend the class name 'Constants' all the time. If you are using constants very frequently, then this will become little ineffective. We can do better.

## 2. Define a Constants interface and implement it

The second approach is that you define an Interface that contains all your constants and then implement this interface in the class where you want to use the constants. This way, you don't need to prefix 'Constants', instead you can directly access the constant like CONSTANT_NAME.

```java
    public interface Constants {
    	public static final String SITE_NAME="veerasundar.com";
    }

    class Hello implements Constants{
    	public void someFun(){
    		System.out.print(SITE_NAME);
    	}
    }
```

But this approach is generally considered as a bad practice because it pollutes the class's implementation hierarchy. You are forced to implement an interface without much semantic meaning. We can still do better than this.

## 3. Use Java static imports

Static imports are introduced in Java 5. Using static imports you can import static members/properties of a class so that you can directly access them without prefixing it's parent class's name. So, we can define a *Constants *class as shown in first approach above and the use static imports to use the constant properties directly.

```java
    package com.test;
    public class Constants {
    	public static final String SITE_NAME = "veerasundar.com";
    }

    import static com.test.Constants.*;
    public class Hello {
    	public void someFun() {
    		System.out.print(SITE_NAME);
    	}
    }
```

So, we get the best of both worlds - we don't unnecessarily prefix *Constants *everywhere, and we don't pollute class's API too. Win!

But this approach too has some bad press against it. If you use static imports very often, then your code become hard to read and understand. Especially when you statically import a lot of methods. So, use it sparingly and wisely.

What do you think as the best of the above three approaches? Do you use any other approaches other than these? Feel free to comment!


#best-practice (3)