Diagnosing Java code: Reasons to use static types

Static Type--most programmers like it or hate it. Supporters boast that static types allow them to write cleaner and more reliable code, which cannot be done so well without them. Critics complain that static typing increases the complexity of the program.

Yes, the static type is not a free lunch; sometimes they are tedious to use. However, if our primary concern is to make the code error-free, then, in general, Java programming still has and uses static types better. Why? Static type checking:

Improved robustness through early error detection

Improve performance by making the required checks at the best time

compensate for the shortcomings of unit testing

Let's take a closer look at these reasons and take a look at static type checking and pair programming (pair programming) blending.

Improved robustness through early detection

Static type checking can improve the robustness of programs. Why? Because it helps to find errors as quickly as possible-before the program runs. The logic here does not have it. The sooner a bug is discovered, the easier it is to diagnose the problem, and the less data will be destroyed by the wrong calculation.

It is ideal to find and diagnose errors before the program is run. This advantage makes static type checking a great success in programming language design because it is a few ways to automatically detect errors in a program before the program is run, and it can accomplish this task within an acceptable time. "Acceptable time" means the time that is linearly related to the length of the program (with a very small constant coefficient), rather than other forms of automatic checking of the required cubic or even exponential time (many do not even guarantee completion).

Yes, the more powerful the type system is, the easier it is to edit the program (and the more errors the system will detect). I do not deny that the Java simple type system leaves a lot of flaws; it often hinders us and forces us to bypass it with forced transformation. But the situation is slowly improving.

The Sun JSR14 compiler adds a limited form of generics (also known as parameterized) to the language, and we believe it will be added to the language sooner or later because it is now firmly supported in the Java community process. More advanced language extensions (such as NextGen) commit to a higher level of increased expressiveness provided by JSR14. That's a good thing, because in many environments NextGen helps reduce some of the added complexity that is needed even in JSR14. See Resources for more information on this issue. (in addition to JSR14 links, there are also some arguments about the polymorphism of the article.) ）

However, the benefits of static type checking are more than just robustness. It also protects the performance of your program.

Improve performance by reducing the required checks

In a secure language ("security" means not allowing us to destroy its own abstract language), checking the type of parameters passed to the method is necessary and must be done, and checking the type of the accessed domain is necessary and must be completed. If these checks are not statically completed, they must be completed at run time.

These required checks are time-consuming, and the language in which they are checked at run time has a corresponding performance impairment. When the invariant is checked statically, we do not have to check it at run time, thus speeding the program to run. So, static type checking allows us to write more robust and efficient code.

It is traditionally assumed that compile-time static type checking is inefficient. It is time-consuming to link various types of references between files for large programs written in languages such as C + +, because each file must be combined to generate a large executable file at each compile time. But the Java language completely avoids this problem, because classes are compiled separately, in need of fashion into the JVM. There is no need to link all references to an executable file--so there is no corresponding slowdown at compile time.

Now, what do we say to people who claim that static types are unnecessary in a unit test environment?