Month: November 2012

Android Follow Test Method Naming Conventions

When naming test methods, you can use an underscore to separate what is being tested from the specific case being tested. This style makes it easier to see exactly what cases are being tested. For example: testMethod_specificCase1 testMethod_specificCase2 void testIsDistinguishable_protanopia() { ColorMatcher

Tagged with: ,

Android Be Consistent

Our parting thought: BE CONSISTENT. If you’re editing code, take a few minutes to look at the code around you and determine its style. If they use spaces around their if clauses, you should too. If their comments have little

Tagged with: ,

Android Log Sparingly

While logging is necessary it has a significantly negative impact on performance and quickly loses its usefulness if it’s not kept reasonably terse. The logging facilities provides five different levels of logging. Below are the different levels and when and

Tagged with: ,

Eclipse Java TODO Comments

Use TODO comments for code that is temporary, a short-term solution, or good-enough but not perfect. TODOs should include the string TODO in all caps, followed by a colon: // TODO: Remove this code after the UrlTable2 has been checked

Tagged with: , ,

Android Treat Acronyms as Words

Treat acronyms and abbreviations as words in naming variables, methods, and classes. The names are much more readable: Good Bad XmlHttpRequest XMLHTTPRequest getCustomerId getCustomerID class Html class HTML String url String URL long id long ID Both the JDK and

Tagged with: ,

Android Use Standard Java Annotations

Annotations should precede other modifiers for the same language element. Simple marker annotations (e.g. @Override) can be listed on the same line with the language element. If there are multiple annotations, or parameterized annotations, they should each be listed one-per-line

Tagged with: ,

Android Limit Line Length

Each line of text in your code should be at most 100 characters long. There has been lots of discussion about this rule and the decision remains that 100 characters is the maximum. Exception: if a comment line contains an

Tagged with: ,

Android Use Standard Brace Style

Braces do not go on their own line; they go on the same line as the code before them. So: class MyClass { int func() { if (something) { // … } else if (somethingElse) { // … } else

Tagged with: ,

Android Follow Field Naming Conventions

Follow Field Naming Conventions Non-public, non-static field names start with m. Static field names start with s. Other fields start with a lower case letter. Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES. Source:

Tagged with: ,

Android Use Spaces for Indentation

We use 4 space indents for blocks. We never use tabs. When in doubt, be consistent with code around you. We use 8 space indents for line wraps, including function calls and assignments. For example, this is correct: Instrument i

Tagged with: ,