Review 11 common errors in Java code

Code review is one of the most important ways to eliminate bugs, and these reviews are particularly effective most of the time. Because the code review itself is aimed at the object, is to overlook the entire code in the testing process of problems and bugs. Also, code reviews can help eliminate some of the special details of errors, especially those that are easily found when reading code, which are often not easily identified by tests on the machine. This article makes some constructive suggestions for common Java code issues that are easy to come by, so that you can notice these common detail errors during the review of your code.

It is easier to choose the wrong work for others than to find your own mistakes. The existence of different perspectives also explains why the authors need to be edited, and why athletes need coaches. Not only should we not reject other people's criticisms, we should welcome others to discover and point out the deficiencies in our programming work, we will benefit greatly. Formal code review (inspection) is one of the most powerful technologies to improve code quality, code review--and colleagues looking for bugs in the code--the errors found are different from those found in the test, so the relationship is complementary, not competitive.

If the censor is able to consciously look for specific errors, rather than aimlessly browsing the code to discover errors, then the effect of code review will be more effective. In this article, I have listed 11 common errors in Java programming. You can add these bugs to your code review Checklist (checklist) so that after the code review, you can be sure that there are no more such errors in your code.

Common error: Multiple copies of a string

One error that the test cannot find is to generate multiple copies of immutable (immutable) objects. Immutable objects are immutable and therefore do not need to be copied. The most commonly used immutable object is string.

If you have to change the contents of a string object, you should use StringBuffer. The following code works correctly:

String s = new String ("Text here");

However, this code has poor performance and is not necessarily so complicated. You can also rewrite the above code in the following ways:

String temp = "Text here";
String s = new String (temp);

But this code contains an extra string, which is not entirely necessary. The better code is:

String s = "Text here";

Ii. Common error 2#: No Clone (clone) returned objects

Encapsulation (encapsulation) is an important concept of object-oriented programming. Unfortunately, Java provides a convenient--java to allow the return of private data (reference) for accidentally breaking encapsulation. The following code reveals this:

import java.awt.Dimension;
/***Example class.The x and y values should never*be negative.*/
public class Example{
　 private Dimension d = new Dimension (0, 0);
　 public Example (){ }
　 /*** Set height and width. Both height and width must be nonnegative * or an exception is thrown.*/
　 public synchronized void setValues (int height,int width) throws IllegalArgumentException{
　　 if (height < 0 || width < 0)
　　　 throw new IllegalArgumentException();
　　　 d.height = height;
　　 d.width = width;
　 }
　 public synchronized Dimension getValues(){
　　 // Ooops! Breaks encapsulation
　　 return d;
　 }
}

The example class guarantees that the height and width values It stores are always non-negative, and attempting to use the Setvalues () method to set a negative value triggers an exception. Unfortunately, because GetValues () returns a reference to D rather than a copy of D, you can write the following destructive code:

Example ex = new Example();
Dimension d = ex.getValues();
d.height = -5;
d.width = -10;

Now, the example object has a negative value! If the caller of getvalues () never sets the width and height values of the returned dimension object, it is not possible to detect such errors by test alone.

Unfortunately, over time, customer code may change the value of the returned dimension object, which is a tedious and time-consuming process, especially in a multithreaded environment, to trace the source of the error.

A better way is to have getvalues () return a copy:

public synchronized Dimension getValues(){
return new Dimension (d.x, d.y);
}

The internal state of the example object is now secure. The caller can change the state of the copy it receives as needed, but to modify the internal state of the example object, it must be done through Setvalues ().