The ten rules that Java program developers need to know

Program

There are many standards and best practices for Java developers. This article lists the ten basic principles that every developer must follow, and if there is a rule that can be obeyed and not complied with, it will result in a very tragic outcome.

1. Add a comment to your code

Everyone knows this, but somehow forgot to follow. How many times have you "forgotten" to add a comment? This is true: annotations have no substantive contribution to the function of the program. But you need to go back to the code you wrote two weeks ago, probably all your life, and you can't remember why. If the code is yours, you are lucky. Because it's likely to remind you of it. But unfortunately, a lot of the time, the code is someone else's, and it's very likely that he has left the company.

2. Don't make things complicated.

I've done this before, and I believe all people have done it. Developers often propose a solution for a simple problem. We introduce EJBS for applications that only have 5 users. We use the framework for an application and it does not need it at all. We add property files, object-oriented solutions, and threads to the application, but it doesn't need them at all. Why do we do this? Some of us do not know how to do better, but others do so in order to learn new knowledge, so that the application is more interesting to us.

3. Keep in mind--"less is much (less is more)" isn't always good

The efficiency of code is a great thing, but in many cases writing fewer lines of code does not improve the efficiency of the Code. Please let me show you a simple example.

if (Newstatuscode.equals ("SD") && (selloffdate = null | | | Todaydate.compareto (selloffdate) <0 | | (lastuseddate!= null && todaydate.compareto (lastuseddate) >0)) || (Newstatuscode.equals ("OBS") && (obsdate = = NULL | | | Todaydate.compareto (obsdate) <0)) {Newstatuscode = "NYP";}

I would like to ask: The above section of the code to say if conditions to do it easy? Now let's assume that whoever writes this code without complying with the first rule--add a comment to your code.

Wouldn't it be simpler if we split the condition into two separate if statements? Now consider the following correction code:

if (Newstatuscode.equals ("SD") && (selloffdate = null | | | Todaydate.compareto (selloffdate) <0 | | (lastuseddate!= null && todaydate.compareto (lastuseddate) >0))) {Newstatuscode = "NYP";} else if (newstatuscode.equals ("OBS") && (obsdate = null | | | Todaydate.compareto (obsdate) <0)) {Newstatuscode = "NYP";}

Does it not have better readability? Yes, we repeated the terms of the statement. Yes, we have extra "IF" and two pairs of extra brackets. But the code is more readable and understandable.

4. Please do not have hard code

Developers often consciously forget or ignore this rule because we, as usual, are in a hurry. If we follow this rule, we may miss the progress. We may not be able to end our current state. But how much time does it take to write an extra line of code that defines static constants?

Here's an example.

public class A {

public static final String s_constant_abc = "ABC";

public boolean MethodA (String sParam1) {

if (A.s_constant_abc.equalsignorecase (sParam1)) {

return true;

}

return false;

}

}

Now, every time we need to compare the string "ABC" with some variables, we just need to refer to S_CONSTANT_ABC instead of remembering what the actual code is. It also has the advantage of being more prone to modifying constants in one place, rather than looking for this code in all the code

Don't invent your own frameworks.

Thousands of kinds of frameworks have been introduced, and most of them are open source. Many of these frameworks are excellent solutions and are being applied to thousands of applications. You need to keep up with the pace of these new frameworks, at least superficially. One of the best and most straightforward examples of these wonderful, widely used frameworks is struts. In the frameworks you can imagine, this Open-source Web frameworks is a perfect candidate for web-based applications. But you have to remember the second rule--don't complicate things. If you're developing a three-page application-please, do not use struts, there is no "control" request for such an application.

6. Do not print line and string addition

I know that for debugging purposes, developers like to add System.out.println to every place we think fit, and we'll say to ourselves that we'll delete the code later. But we often forget to delete these lines of code, or we simply do not want to delete them. We use SYSTEM.OUT.PRINTLN to test, why do we still have access to them when we have finished the test? We might delete a line of code we actually need, simply because you underestimate the damage caused by SYSTEM.OUT.PRINTLN, consider the following code:

public class Badcode {public static void Calculationwithprint () {Double somevalue = 0d;for (int i = 0; i < 10000; i++) { System.out.println (somevalue = somevalue + i);} }public static void Calculationwithoutprint () {Double somevalue = 0d;for (int i = 0; i < 10000; i++) {somevalue = Someva Lue + i;}} public static void Main (String [] n) {badcode.calculationwithprint (); Badcode.calculationwithoutprint ();}

According to the test, the Calculationwithoutprint () method took 0.001204 seconds to run. By comparison, running the Calculationwithprint () method took an astonishing 10.52 seconds.

(If you don't know how to get a table like this, see my article "Java Profiling with WSAD" Java Profiling with WSAD)

The best way to avoid such a CPU waste is to introduce a wrapper method, as follows:

public class Badcode {public static final int debug_mode = 1;public static final int production_mode = 2;public static Voi d calculationwithprint (int logmode) {Double somevalue = 0d;for (int i = 0; i < 10000; i++) {somevalue = somevalue + i;m Yprintmethod (LogMode, somevalue);} public static void Myprintmethod (int logmode, double value) {if (LogMode > Badcode.debug_mode) {return;} System.out.println (value); }public static void Main (String [] n) {badcode.calculationwithprint (Badcode.production_mode);}}

According to the test, the method using StringBuffer takes only 0.01 seconds to execute, and the method that uses the string addition takes 0.08 seconds to run. The choice is obvious.

7. Focus on the GUI

No matter how ridiculous this sounds, I have to explain repeatedly that the GUI is as important to business customers as it is to function and performance. The GUI is a necessary part of a successful system. (however), it magazines often tend to overlook the importance of GUIs. Many organizations do not hire designers who are experienced in designing "user-friendly" GUIs to save money. Java developers have to rely on their own HTML knowledge, but their knowledge in this area is limited. I've seen a lot of these apps: "Computer-friendly," not "user-friendly." I rarely see developers who are proficient in software development and GUI development. If you are the unfortunate developer who is assigned to develop the user interface, you should follow the following three principles:

Don't invent the wheel again. Look for existing systems that have similar user interface requirements.

Second, first create a prototype. This is a very important step. Customers like to see what they're going to get. This is good for you, too, because you get feedback before you do your best to make a user interface that will make users angry.

Third, wear the user's hat. In other words, stand in the user's perspective to check the application requirements. For example, whether a summary page should be paginated or not. As a software developer, you tend to ignore paging in a system because it makes you less likely to develop complexity. However, this is not the best solution from a user's perspective, because the data for the summary will have hundreds of rows of data.

8. Always ready to document the requirements

Each business requirement must be documented. This may be true in some fairy tales, but not in the real world. No matter how pressing time is for your development, and no matter the delivery date is imminent, you must always be aware that each business requirement is documented.

9. Unit tests, Unit tests, unit tests

I will not delve into the details of what is the best way to unit test your code. What I'm going to say is that unit tests have to be done. This is the most basic principle of programming. This is the least overlooked of all the above rules. If your colleagues can create and test unit tests for your code, this is the best thing to do. But if you don't do these things for you, then you have to do it yourself. When you create your unit test plan, follow these rules:

First, write the unit test case before you write the code.

Write a note in the unit test.

Test all public methods that perform the "interesting" function ("interesting" means a non-setters or getters method unless they execute the set and get methods in a special way).

10. Remember-quality, not quantity.

Don't stay in the office too late (when you don't have to stay too late). I understand that sometimes product problems, tight deadlines, and unexpected events can stop us from getting off work on time. However, under normal circumstances, managers will not appreciate and reward those who work too late staff, he appreciated them because of the quality of their products. If you follow the rules I've given above, you'll find that your code is less bugs and more maintainable. And that's the most important part of your job.

Summarize

In this article, I give 10 important rules for Java developers. It is important not only to know the rules, but it is more important to follow these rules in the coding process. Hopefully these rules will help us become better programmers and professionals.