Java Coding Standard
跳转到： 导航、 搜索
1 命名规则 命名规则表
名字标记示例
FileCallManager.java
ClassCallManager
常量定义CALL_MANAGER_ERROR
Class attributem, smCdmaIsSecondCallActive, sAttctManager
MethodgetErrorCode
Method参数signalStrength，singal
Rule1 Java 文件名跟Class的名字要一致，大写第一个字母，如果名字多于一个单词，后续单词也要大写首字母。Rule2 Class 命名大写第一个字母，如果名字多于一个单词，后续单词也要大写首字母 Rule3 常量定义大写所有字母，每个单词以下划线来分隔Rule4 Class 的非静态非公开变量以m开头，静态变量s开头，后续follow Rule2 Rule5 Method 需要动词并以小写开头，后续用首字母大写来分开单词Rule6 Method参数：单个小写单词，多于一个单词的后续用首字母大写来分开单词 2 代码风格和间隔Rule7 在任何改动的文件都需要加上公司confidential的标识/* ——————————————————————————-Copyright (C) 2011, Nollec Wireless CO. LTD. All Rights ReservedRevision History:Bug/Feature IDAuthorModification DateDescription—————————————————————————-BugID/FeatureIDdeveloper nameYYYY/MM/DDbrief discription———————————————————————————-*/Rule7 在任何改动或者新建的文件都需要加上公司confidential的标识 Rule8 Revision History 在Feature开发完成或Bug解决完成后必须更新Rule9 所有的Comments必须用英文填写Rule10 代码缩进的时候不要用Tab，用4个空格代替（跟编辑器有关,可设置）void func()｛if (something bad){…if (another thing bad){} }Rule 11 函数创建修该注释需要按照Android规则新创建的函数按下列例子书写 /*** Get the presentation from the callerinfo if not null otherwise,* get it from the connection.** @param conn The phone connection.* @param info The CallerInfo. Maybe null.* @return The presentation to use in the logs.*/private int getPresentation(Connection conn, CallerInfo callerInfo) {int presentation;if (null == callerInfo) {presentation = conn.getNumberPresentation();} else {presentation = callerInfo.numberPresentation;if (DBG) log("- getPresentation(): ignoring connection’s presentation: " +conn.getNumberPresentation());}if (DBG) log("- getPresentation: presentation: " + presentation);return presentation;}对于Modified 代码，需要developer name, 时间，和brief description
/**
* xxx xxx xxx * 2011/6/23 * description: * xxxxxxxx xxxxxx xxxxxx xxx */对于需要在SDK publish的接口，Class，需要有详尽的描述Rule12 代码风格统一，｛｝需要跟原来代码一致Android 代码风格跟下面的例子一样，代码需要跟此一致if (condition) { doSomething();}3 Exception Rule13 尽量不要使用try catch捕获异常，而是显式的抛出一个异常 Rule14 使用try catch 一定要在catch语句中做好相应的处理，不能留空 Rule15 不要捕获Exception类型的异常 private final Handler mAttachmentEditorHandler = new Handler() {@Overridepublic void handleMessage(Message msg) {switch (msg.what) {case AttachmentEditor.MSG_EDIT_SLIDESHOW: {try { //”’不要使用try catch”’editSlideshow();} catch (Exception e) { //不要在这里捕获基类Exception//这里留空非常危险，一旦出错，根本找不到}break;}case AttachmentEditor.MSG_SEND_SLIDESHOW: {if (isPreparedForSending()) {ComposeMessageActivity.this.confirmSendMessageIfNeeded();}break;}
为什么不要使用try catch？
我们应该对于如何划分异常的层次有一个理解对于完全已知的错误，结合逻辑编写处理这种错误的代码，自己无法处理的，继续向上抛出，增加程序的鲁棒性但是如果你根本不确定报出什么异常，请不要这样做。为什么要声明方法抛出异常？方法是否抛出异常与方法返回值的类型一样重要。假设方法抛出异常确没有声明该方法将抛出异常，那么客户程序员可以调用这个方法而且不用编写处理异常的代码。那么，一旦出现异常，那么这个异常就没有合适的异常控制器来解决。为什么不要捕获Exception类异常？Exception分为两类：unchecked(RuntimeException 和 error) & checked因为RuntimeException这种由于程序本身错误导致的异常，是程序员的问题。你catch了Exception，意味着子类RuntimeException也被catch了。在catch中可以做什么？1，赋默认值2，做一些错误处理3，抛出一个自己封装的异常类对象在catch中不可以做什么？1，抛出一个RuntimeException。(除非你认为你的程序除了崩掉重启别无他法，否则别这么做)其他Rule16 少用或不用Finally
finally 这个关键字很不好用，因为我们根本无法确定什么时候他会执行，是return之前还是之后？没人知道。除非你要对外部资源进行一些收尾，比如使用InputStream，你要close。否则，不要用它。
Rule 17 import: 顺序android, 3rd party, java(x), import 规则：一定要引全类名，不要引用整个包 Rule 18 代码行长 < 100Rule 19 当有需要在未来完成的工作时，加上TODO注释，并给出触发事件或者时间点 // TODO: Remove this code after the UrlTable2 has been checked in.// TODO: Change this to use a flag instead of a constant.Rule 20 资源文件的comments<?xml version="1.0" encoding="UTF-8"?> <!– -yu.guo -2011-3-25 -description –> <abc><list></list> </abc>
，原以为“得不到”和“已失去”是最珍贵的，可原来把握眼前才是最重要的。
