Fennec/NativeUI/CodingStyle: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(→‎Closing resources: fix finally block)
No edit summary
 
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Coding Style =
This page has been consolidated into [[Mobile/Fennec/Android#Coding_Style]].
 
== XML files (layout, resources, styles, etc) ==
 
* Each child tag should be indented with 4 spaces.
* The properties should be aligned with the first property of a tag.
* Each element should have "android:id" first, "style" (if exists) second, and the other properties follow. The root will have "xmlns:android" as first property.
* A Line break after every tag.
 
== Java ==
 
* We use the [http://www.oracle.com/technetwork/java/codeconvtoc-136057.html Java Coding Style]. Quick summary:
** FirstLetterUpperCase for class names
** camelCase for method and variable names
** One declaration per line
int x, y; // this is BAD!
int a;    // split it over
int b;    // two lines
** Braces should be placed like so (generally opening braces on same line, closing braces on a new line):
public void func(int arg) {
    if (arg != 0) {
        while (arg > 0) {
            arg--;
        }
    } else {
        arg++;
    }
}
 
* Places we differ from the Java coding style:
** Start class variable names with m (e.g. mSomeClassVariable)
** Don't use wilcard imports.
** 4-space indents
** spaces, not tabs
** Don't restrict yourself to 80-character lines. Java code tends to be long horizontally, so use appropriate judgement when wrapping. Avoid deep indents on wrapping. Note that aligning the wrapped part of a line with some previous part of the line (rather than just using a fixed indent) may require shifting the code every time the line changes, resulting in spurious whitespace changes.
* The [http://source.android.com/source/code-style.html Android Coding Style] has some useful guidelines too.
 
== Java Idioms ==
 
=== Closing resources ===
 
A good way to ensure things get closed properly is to use a try/finally block like so:
 
Cursor c = gimmeNewCursor();
try {
    useCursor(c);
    cursorMightThrowException(c);
    if (checkSomething(c)) {
        return extractReturnValue(c);
    }
} catch (SomeSpecificException sse) {
    log(sse);
} finally {
    try {
        c.close();
    } catch (Exception e) {
        // this handles/ignores NullPointerExceptions in case c was never assigned
        // and also anything else c.close() might throw (e.g. IOException)
    }
}
 
Once the try block is entered, the finally block will *always* get executed upon exit of the try block. The one exception is if there is a System.exit call inside the try block, which immediately exits the program and makes everything moot anyway. The finally block will get executed on caught and uncaught exceptions, as well as normal returns.
 
If you are casting the resource to something, make sure that you do the cast inside the try block, like so:
 
// GOOD!
InputStream is = getInputStream();
try {
    FileInputStream fis = (FileInputStream)is;
    ...
} finally {
    ...
}
 
rather than doing this:
 
// BAD!
FileInputStream fis = (FileInputStream)getInputStream();
try {
    ...
} finally {
    ...
}
 
This is so that in case of ClassCastExceptions you don't get a dangling open resource left behind.
 
=== Timing things ===
 
TLDR: Google recommends using SystemClock.uptimeMillis() for general purpose interval timing of user interface events or performance measurements. If you're adding stuff for timing, use SystemClock.uptimeMillis(), rather than something like new Date().getTime().
 
Normally in Java the default time-getter is System.currentTimeMillis() since it avoids the overhead of creating a new Date object. This is also what new Date() does under the hood. However, currentTimeMillis() and the Date object are both subject to change in unexpected ways if the user changes the time on their device, or if daylight savings comes into effect, or there's a network time update, or whatever. So Android has generously provided android.os.SystemClock which has various functions that you can use to get a better timestamp. Refer to the class javadoc and pick whichever function is most suitable for what you're trying to measure.
 
http://developer.android.com/reference/android/os/SystemClock.html

Latest revision as of 20:49, 12 August 2013

This page has been consolidated into Mobile/Fennec/Android#Coding_Style.

Retrieved from "https://wiki.mozilla.org/index.php?title=Fennec/NativeUI/CodingStyle&oldid=693552"