Some small details worth noting in optimizing the code

Recently in the modification of the project some code violation issues, are detected by sonar ... Many of the problems are recurring ... So now I'm going to record something that I think is more important and easy to commit.

Log

For example I use SLF4J, that should be declared in the class private static final Logger Logger = Loggerfactory.getlogger (Xxxx.class)

private static final 3 modifier words can not be changed, indispensable.

Logger is possible, or changed to log, these 2 types are recommended.

Found in some classes that someone would write private final Logger Logger = Loggerfactory.getlogger (GetClass ())

This is not standard. You do not have to create an object of the logger class for each instance of the class

determines whether the collection is empty

When judging if the set is empty, someone would write like that. list.size () > 0

This is also not standard. The specification is List.isEmpty ()

This is more concise.

Long Type

If there are 1 long values that need to be converted to a long object, someone might do so. New Long (long)

This is not the best choice, you can use long.valueof (long) instead, because long is a cache.

You can refer to this article

In addition, if literal constants are used directly, L is capitalized, such as using long num = 1L instead of 1l.

Traverse Map

There are many ways to traverse a map. I have been using the simplest kind.

 for (String key:map.keySet ()) {    = map.get (key);}

But it's also problematic. It's an efficiency problem, so it's better to use entry speed.

The workaround is

 for (map.entry<string, string> entry:map.entrySet ()) {    = entry.getvalue ();     = Entry.getkey ();}

string

Sometimes you need to splice strings, and now I think that string is generally not used directly, perhaps a lot of people will use StringBuffer to replace.

This time should be noted that if the stitching string is inside the method, StringBuffer is a local variable exists, this time there is no synchronization problem, you can consider the use of StringBuilder instead, to achieve better efficiency.

tab and Space

The suggested use of spaces instead of tab,ide in coding can automatically replace the tab with a space, because it may be slightly different to indent 1 tabs in different environments, but the spaces are the same. Although I think tab is better than space ... Because the mouse can be more simple to locate the code ... But there is some truth to this rule ....

if

A single if also requires some parentheses, or the next time you add code, it will be easy to mistake. Although eclipse can format code for easy checking, it's better to write.

Throw Exception

When you throw exception, sonar suggests that you throw your own custom exception instead of a very high-level exception, which may make it easier to judge what is wrong.

string comparison

This is a little bit of work experience of friends should know that 2 string comparison should be written in front of the constant.

because string constants are NOT NULL, and references may point to NULL. This avoids null pointer exceptions.

Method Parameters

Method parameters should be avoided within the method as much as possible, otherwise it might affect references outside the method.

I personally think you can use converter to copy a parameter.

Catching exceptions

After catching an exception, either log the exception or re-throw it. Instead of doing nothing at all. Otherwise the outer layer may not know that there is an exception.

Even if a new exception is thrown in the catch block, it is best to record the old exception. Otherwise the original crime scene was lost.

It is also best not to use Ex.printstacktrace (), but to use logger to record exceptions, which is not the same as using System.out.print or logger.

comparing strings to numbers

If you have 1 string integers, and you want to compare 1 numbers, someone might write this.

Integer.valueof (String) < 2000

In fact, do more than 1 times unnecessary packing and unpacking

The valueof method calls the Parseint method, and the Parseint method returns an integer that is returned by int,valueof, so the int is boxed into an integer.

Then the comparison, the integer and 2000 when compared with the case will be split into int. So it is equivalent to do more than 1 times of useless boxing and unpacking.

You might consider using the Integer.parseint method instead of valueof

returns the type of the collection and array method to avoid returning null as much as possible

If you can, consider returning an empty collection with an array instead of returning null.

For example, return new ArrayList () instead of NULL

Because there are places where others traverse arrays and collections in the form of foreach rather than simple for

In this case, traversing null throws an exception directly, while traversing an empty collection and array is not.

The above is probably my recent experience ~

Some small details worth noting in optimizing the code