Shawn的開發記錄

#Naming

Classes & Interfaces

Written in UpperCamelCase

BAD:

interface onClickListener

GOOD:

interface OnClickListener

Methods

Written in lowerCamelCase

BAD:

public void SetValue(){
}

GOOD:

public void setValue(){
}

Fields

Written in lowerCamelCase.

public int publicField;

• Non-public, non-static field names start with an m.

int mPackagePrivate;
private int mPrivate;
protected int mProtected;

• Static field names start with an s.

private static SingletonClass sSingleton;

• Static final fields should be written in uppercase, with an underscore separating words

public static final int THE_ANSWER = 42;

Variables & Parameters

Written in lowerCamelCase.

• Single character values to be avoided except for temporary looping variables.

BAD:

public void setValue(){
  int i; 
  i = i+5;
}

GOOD:

public void setValue(){
  for (int i =0 ;i < 10 ; i++)
}

XML File Names

BAD:

login.xml
intro_screen.xml
save_button.xml

GOOD:

activity_login.xml
fragment_intro_screen.xml
button_save.xml

XML Attribute

BAD:

android:id="@+id/userName"

GOOD:

android:id="@+id/user_name"
android:id="@+id/name"

Language

Use English spelling.

BAD:

String blak = "#00000";
String shahor = "#00000"; //hebrew

GOOD:

String black = "#00000";

Treat acronyms as words

Treat acronyms and abbreviations as words in naming variables, methods, and classes to make names more readable:

BAD:

XMLHTTPRequest
userID
class HTML
String URL
long ID

GOOD:

XmlHttpRequest
userId
class Html	
String url	
long id

#Brace Style

Use standard brace style

BAD:

public Class
{
  private void setValue()
  {
  // do something ..
   }
}

GOOD:

public Class{
  private void setValue(){
  // do something ..
  }
}

• Conditional statements are always required to be enclosed with braces

BAD:

if (true) 
  setValue();

GOOD:

if (true){
  setValue();
 }
//OR
if (true)  setValue(); //acceptable

#Declarations

Access Level Modifiers

• methods and variables access level should be explicitly defined for classes

Fields & Variables

single declaration per line

BAD:

public String firstName,lastName,age;

GOOD:

public String firstName;
public String lastName;
public String age;

#Formatting & Spacing

Code formatting is very important to make your code eaisly readable

• use the charm keyboard shorts to formate your code :

Windows : Ctrl+Alt+L

Mac : ⌘+Option+L

#Other

TODO comments

Use TODO comments for code that is temporary, a short-term solution, or good-enough but not perfect.

GOOD:

// TODO: Remove this code after all production mixers understand.
// TODO: Change this to use a flag instead of a constant.
// TODO: Remove this code after the UrlTable has been checked in.

BAD:

// TODO: Ali Esa Assadi (developer name)
// TODO: Ali - later

Switch Statements

Switch cases should almost always have a default case.

1. To ‘catch’ an unexpected value
2. To handle ‘default’ actions, where the cases are for special behavior.
3. To show someone reading your code that you’ve covered that case.

BAD:

switch(type){
    case 1:
        //something
        break;
    case 2:
        //something else
         break;
}

GOOD:

switch(type){
    case 1:
        //something
         break;
    case 2:
        //something else
         break;
    default:
        // unknown type! should probably be some handling
         break;
}

Annotations

Use standard Java annotations. Android standard practices for the four predefined annotations in Java are:

@Deprecated 
//Annotation type used to mark program elements that should no longer be used by programmers.
//Compilers produce a warning if a deprecated program element is used.

@Override 
//Annotation type used to mark methods that override a method declaration in a superclass.
//Compilers produce an error if a method annotated with @Override does not actually override 
//a method in a superclass.

@Nullable 
//Denotes that a parameter, field or method return value can be null.

@NonNull 
//Denotes that a parameter, field or method return value can never be null.

Exceptions

Don’t ignore exceptions

Do not do this. While you may think your code will never encounter this error condition or that it is not important to handle it, ignoring exceptions as above creates mines in your code for someone else to trigger some day.

BAD:

void setServerPort(String value) {
    try {
        serverPort = Integer.parseInt(value);
    } catch (NumberFormatException e) { }
}

GOOD:

• if you are confident that ignoring the exception is appropriate then you may ignore it, but you must also comment why with a good reason:

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

• Dangeros Throw a new RuntimeException

/** Set port. If value is not a valid number, die. */

void setServerPort(String value) {
    try {
        serverPort = Integer.parseInt(value);
    } catch (NumberFormatException e) {
        throw new RuntimeException("port " + value " 
is invalid, ", e);
    }
}

• Handle the error gracefully and substitute an appropriate value in the catch {} block.

/** 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
    }
}

• Throw a new exception that’s appropriate to your level of abstraction.

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

• Throw the exception up to the caller of your method.

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

Don’t catch generic exception

It can also be tempting to be lazy when catching exceptions and do something like this:

BAD:

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

GOOD:

Alternatives to catching generic Exception:

• Catch each exception separately as separate catch blocks after a single try. This can be awkward but is still preferable to catching all Exceptions.Beware repeating too much code in the catch blocks.
• Refactor your code to have more fine-grained error handling, with multiple try blocks. Split up the IO from the parsing, handle errors separately in each case.
• Rethrow the exception. Many times you don’t need to catch the exception at this level anyway, just let the method throw it.

Remember: exceptions are your friend! When the compiler complains you're not catching an exception, don't scowl. Smile: the compiler just made it easier for you to catch runtime problems in your code.

Loop

Loop variables should be declared in the for statement itself unless there is a compelling reason to do otherwise:

BAD:

int i;
for (i = 0; i < n; i++) {
    doSomething(i);
}

GOOD:

for (int i = 0; i < n; i++) {
    doSomething(i);
}
//OR
for (Iterator i = c.iterator(); i.hasNext(); ) {
    doSomethingElse(i.next());
}