
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


In my last article about **Aspect Oriented Programming** (AOP), I explained [how to use Spring AOP for profiling method execution time][1]. When the article was [posted][2] in DZone, it got a comment from [an user][3] saying that

[1]: https://veerasundar.com/blog/spring-aop-example-profiling-method-execution-time-tutorial "Spring AOP Example: Profiling method execution time tutorial"
[2]: http://www.dzone.com/links/spring_aop_example_profiling_method_execution_tim.html
[3]: http://www.dzone.com/links/users/profile/388907.html

> Profiling and logging seem to be to only imaginable AOP use cases.

But, I think **it is not**. Because AOP is an extensive area where a lot of examples can be shown as use cases of AOP. Here, 'Use cases' are nothing but the **cross cutting concerns** in your application. That is, the functionalities that are used by many part of your application. Logging and Profiling are the best examples and can be easily explained for the cross cutting concerns. That is why in most of the AOP tutorials you can see a logging example or profiling.

Anyway, I tried to do some search on the various AOP cross-cutting concerns (i.e. the _use cases_) that can be found in an J2EE applications. Here is the list of them. Feel free to add if I'm missing/wrongly added something.

## List of AOP Use Cases or Cross cutting concerns:

- **Transaction Management** - in an enterprise application, you can manage the transactional requests using AOP. For example, using the *Around *advice, you can wrap the request processing method and if the method fails for some reason, in your Advice, you can roll back the particular transaction.
- **Access control or Security **- in case you want to restrict the access to your method to a set of users, you can add these checks to the *Before *advice and verify the access credentials of the users before letting them to access your methods.
- **Managing Quotas for your API **- if your API is being used by many third party applications with predefined quotas, you can limit the access based the usage in your AOP advice. If the usage is below the allowed limit, the Advice can let the user to call the API or blocks it otherwise. This is something similar to the Google App Engine / Amazon services quota usages. But I'm not sure how Google/Amazon has implemented the quota limiting.
- **Exception Wrapping** - if you want to wrap a exception, thrown from your business methods, into a Common exception object and throw it to the top level layers, you can use *After throwing *advice to do the task. For example, if you want to wrap all the SQLExceptions into DAOLayerException object and throw it back to Service layer, instead of doing the exception wrapping in every single DAO method, you can implement the exception wrapping in an _After throwing advice_ and it's done.
- **Logging and Profiling - **off course, how can I leave these two? The evergreen examples(!) for the AOP.

I understand that this list is not an extensive one. So, if you have any more use cases to add this list, please leave a comment.


#list (2)