Code style guidelines for contributors (1)

Code style guidelines for contributors code submission Style Guide (1)

Link: http://source.android.com/source/code-style.html

This code style guide, which I saw when I checked the android document by accident, simply translated it. I learned a little more, but I can also exercise my skills in English, if your translation is inappropriate, please correct it;

The following rules are not selective recommendations, but must be strictly followed. All Android code submissions must be followed; otherwise, the code will not be accepted. Note that not all codes comply with these rules, but new code submission must follow.

Java language rules
We follow the standard naming conventions for Java code, and also add some rules:

Don't ignore exceptions
Sometimes the encoding staff may write the following code that completely ignores the exception:

1 void setServerPort(String value) {2 try {3     serverPort = Integer.parseInt(value);4     } catch (NumberFormatException e) { }5 }

You should not do this in any situation. You may think that your code giant will not encounter this exception or is not worth handling, but the above ignore exception will leave a hidden potential vulnerability for your code, especially when other people will maintain the code in the future. Therefore, you must use certain rules to handle any exceptions that may occur in the code. The processing method depends on the situation.

James Gosling once said, "at any time when our code is caught with an empty catch, it will give people a sense of treasure. Of course, we certainly can write this, but we should at least consider this issue. In Java, it is difficult for you to completely avoid this bad feeling."

The feasible processing method is as follows (priority ):
1. Throw an exception up;

1 void setServerPort(String value) throws NumberFormatException {2       serverPort = Integer.parseInt(value);3 }

2. Throw an appropriate new exception based on the situation;

1 void setServerPort(String value) throws ConfigurationException {2 try {3        serverPort = Integer.parseInt(value);4      } catch (NumberFormatException e) {5          throw new ConfigurationException("Port " + value + " is not valid.");6      }7 }

3. Handle the error appropriately and assign a value to the catch;

/** Set port. If value is not a valid number, 80 is substituted. */void setServerPort(String value) {      try {             serverPort = Integer.parseInt(value);            } catch (NumberFormatException e) {            serverPort = 80; // default port for server            }}

4. Capture exceptions and throw new runtime exceptions. This method is dangerous: used only when you think the exception should be crash.

1 /** Set port. If value is not a valid number, die. */2 3 void setServerPort(String value) {4 try {5     serverPort = Integer.parseInt(value);6 } catch (NumberFormatException e) {7      throw new RuntimeException("port " + value " is invalid, ", e);8 }9 }

Note: The original exception is passed to the constructor of the runtime exception. If your code is compiled below java1.3, You need to ignore this exception.

5. Final measure: if you have enough confidence that ignore exceptions is the most appropriate practice, you can do so, but you should add comments here to write a good reason.

1 /** If value is not a valid number, original port number is used. */2 void setServerPort(String value) {3 try {4     serverPort = Integer.parseInt(value);5 } catch (NumberFormatException e) {6 // Method is documented to just ignore invalid user input.7 // serverPort will just be unchanged.8    }9 }

Don't catch generic exception do not catch General Exceptions

1 try {2     someComplicatedIOFunction(); // may throw IOException 3     someComplicatedParsingFunction(); // may throw ParsingException 4     someComplicatedSecurityFunction(); // may throw SecurityException 5 // phew, made it all the way 6 } catch (Exception e) { // I'll just catch all exceptions 7      handleError(); // with one generic handler!8 }

 

You should not write the above Code. In almost all cases, this general exception capture or throwable object is inappropriate, especially the throwable object, because it contains an error exception. This is dangerous, and it means that unexpected exceptions will also be caught (including runtime exceptions and NULL pointer exceptions ). This will mask the exception handling performance of your code. This also means that if someone else adds a new exception to the code you call, the compiler will not remind you to handle this situation extra. In most cases, you should not use the same method to handle different exceptions.
Of course, there are also a few exceptions under such rules: some specific test code or upper-level code that you need to capture all the errors (to avoid exception information appearing on the user interface ). In this case, you can use common exception capture to correctly handle these errors. Of course, you should also think carefully before doing so, and you need to give a comment to indicate the reason for your doing so.

An alternative to capturing general exceptions is as follows:
1. Independent catch code after each try statement. This is troublesome, but it is also a good way to catch all exceptions. Avoid generating a large number of repeated codes in each catch;
2. refactor your code to better use try/catch to handle errors. Separate Io parsing to handle various situations separately;
3. Throw an exception again. In many cases, you do not need to directly capture exceptions at the current level, so you can simply throw an exception.
Do not: exceptions are not a bad thing. When the compiler reports exceptions, do not frown. Just face him happily, because the compiler makes it easier for you to capture errors in the code at runtime.
To be continued...