Aandroid coding convention and quality assurance plugin

We Know Business, We Know Technology, We Are Global

About me Private Informa>on

Name: Le Ngoc Viet Phone: 0168.948.9579 Email: [email protected], [email protected] Skype: lengocviet Facebook: hIp://facebook.com/viet.lengoc

Work History 2010/08~2012/04: AnLab Company/ Android Senior Developer 2012/05~Now: SETA InternaUonal Vietnam/ Android Tech-‐Leader & IOS Senior Developer


SETA　Group　Company Informa>on

Global IdenUty: SETA InternaUonal　（HQ）

Headquarters: Newport Beach, CA

Founded: 2008

2

ü  Hanoi, Vietnam(230) ü  Dublin, Ireland(20) ü  Los Angeles, USA(15) ü  Tokyo,Japan(30) *w/Terras

ü  Los Angeles(HQ) ü  Dublin(Branch) ü  Sydney(Partner) ü  Singapore(Partner) ü  Tokyo(Branch)

Fulfillment Centers: Sales LocaUons:

SETA Interna>onal Vietnam Headquarters: Hanoi, Vietnam

Founded: 2009

Employees: 230 +

Website: www.seta-‐internaUonal.com

Address: 4th floor, 3D Building, Duy Tan Str, Cau Giay, HN

Tel/ Phone: (84) 37-‐950-‐983


Android coding convention and Quality assurance plugin

2013. 12


Topics

§  Android Coding ConvenUon §  Quality Assurance Code Plugins (Eclipse) §  Q&A


Why Need Coding ConvenUon?


Why Need Coding ConvenUon?

Code convenUons are important to programmers for a number of reasons: –  40%-‐80% of the lifeUme cost of a piece of soiware goes to maintenance.

– Hardly any soiware is maintained for its whole life by the original author.

–  Code convenUons improve the readability of the soiware, allowing engineers to understand new code more quickly and thoroughly.

–  If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.


Coding ConvenUon

Coding ConvenUon ? – Coding convenUons are a set of guidelines for a specific programming language that recommend programming style, pracUces and methods for each aspect of a piece program wriIen in this language.


Android Coding ConvenUon

•  Standard Java coding convenUons •  Android coding convenUons


Android Coding ConvenUons


Name ConvenUons

Use “m” for non-‐public, non sta>c fields – “m” for “member variable” or “data member”

• Yes – private String mFirstName; – private boolean mIsMarried;

• No – private String firstName; – private boolean isMarried;

• Use “s” for sta>c (non-‐final) fields • Yes

– private staUc double sBiggestRadius; • No

– private staUc double biggestRadius; For example:

public class MyClass { public staUc final int SOME_CONSTANT = 42; public int publicField; private staUc MyClass sSingleton; int mPackagePrivate; private int mPrivate; protected int mProtected; }


Impact of Naming ConvenUon on Constructors

Standard Style public class Person { private String firstName, lastName; public Person(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } … }

Android Style public class Person { private String mFirstName, mLastName; public Person(String firstName, String lastName) { mFirstName = firstName; mLastName = lastName; } … }


Never Ignore ExcepUons

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


Don't Catch Generic ExcepUon

try { someComplicatedIOFuncUon(); // may throw IOExcepUon someComplicatedParsingFuncUon(); // may throw ParsingExcepUon someComplicatedSecurityFuncUon(); // may throw SecurityExcepUon // phew, made it all the way } catch (ExcepUon e) { // I'll just catch all excepUons handleError(); // with one generic handler! }


Use Spaces for IndentaUon

We use 8 space indents for line wraps, including funcUon calls and assignments. For example,

this is correct: Instrument i = someLongExpression(that, wouldNotFit, on, one, line); and this is not correct: Instrument i = someLongExpression(that, wouldNotFit, on, one, line);


Coding ConvenUons

•  Write Short Methods – No official limit, but try to keep methods short and focused. Think oien about

how to refractor your code to break it into smaller and more reusable pieces. – Max line of method is 40 lines.

•  Keep lines short – They have a strict rule of 100 characters except for imports or comments that

contain URLs or commands that cannot be broken up.


Treat Acronyms as Words

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


Order Import Statements

First – Android packages

• import android.foo.Bar; • Second

– Third party packages • import com.coreservlets.uUls.RandomUUls;

• Third – Standard java or javax packages

• import java.uUl.*; • Within each group

– AlphabeUcal (uppercase Z before lowercase a) • Separa>ng groups

– Blank line between each major grouping


Quality Assurance Code

•  Why need quality assurance code. •  Aims of quality assurance code. •  Tool support.


Why need quality assurance code?


Aims of quality assurance code

-‐  Developing the code quality -‐  Decreasing bugs in the development phase and cost to repair defect aier release.


QA code plugin (eclipse)

•  Checkstyle •  PMD •  Findbugs


Checkstyle Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard.


Demo


PMD

PMD is a source code analyzer. It finds common programming flaws like unused variables, empty catch blocks, unnecessary object creaUon, and so forth. It supports Java, JavaScript, XML, XSL. AddiUonally it includes CPD, the copy-‐paste-‐detector. CPD finds duplicated code in Java, C, C++, C#, PHP, Ruby, Fortran, JavaScript.


What is PMD?

PMD scans Java source code and looks for poten>al problems like: –  Possible bugs -‐ empty try/catch/finally/switch statements –  Dead code -‐ unused local variables, parameters and private methods –  SubopUmal code -‐ wasteful String/StringBuffer usage –  Overcomplicated expressions -‐ unnecessary if statements, for loops that

could be while loops –  Duplicate code -‐ copied/pasted code means copied/pasted bugs


Demo


FindBugs

–  Findbugs is an Open Source project for staUc analysis of the Java bytecode to idenUfy potenUal soiware bugs. The Findbugs analysis can be integrated into the Eclipse IDE via an addiUonal soiware component.

–  Findbugs provides early feedback about potenUal errors in the code. This helps the developer to access these problems early in the development phase.


Findbugs

Correctness bug -‐ Probable bug -‐ an apparent coding mistake resulUng in code that was probably not what the developer intended. We strive for a low false posiUve rate.

Bad PracUce -‐ ViolaUons of recommended and essenUal coding pracUce. Examples include hash code and equals problems, cloneable idiom, dropped excepUons, serializable problems, and misuse of finalize. We strive to make this analysis accurate, although some groups may not care about some of the bad pracUces.

Dodgy -‐ Code that is confusing, anomalous, or wriIen in a way that leads itself to errors. Examples include dead local stores, switch fall through, unconfirmed casts, and redundant null check of value known to be null. More false posiUves accepted. In previous versions of FindBugs, this category was known as Style.


Demo


Report

Checkstyle

PMD

Findbugs


References

•  hIp://source.android.com/source/code-‐style.html

•  hIp://www.oracle.com/technetwork/java/codeconv-‐138413.html

•  hIp://findbugs.sourceforge.net •  hIp://pmd.sourceforge.net/ •  hIp://eclipse-‐cs.sourceforge.net/


Thank you

Aandroid coding convention and quality assurance plugin

Software

Transcript of Aandroid coding convention and quality assurance plugin