2008年1月22日

zz 时间管理之任务猎杀日

迅速提升三倍你的工作效率

工作让你慢慢透不过气来吗?待办事项,计划和突发的琐事不停地积累已经把你包围?遇到这种情况时,你的最佳策略就是先走一步,超前工作。完成今天所有的任务甚至更多,你才能有呼吸的空间。

你会怎么做呢?当我面对这个问题,我的答案是,来一次“任务猎杀日" —— 这一天会是我效率最高的一天。我将预留大量的时间来完成待办事项上的任务并且超前工作。我发现,如果你计划得当,你可以让明天的效率比平常高出三倍!

    * 怎样设定“任务猎杀日”呢?

我已经成功完成了数以百计的“任务猎杀日”。因此,如果你正准备开始你自己的“任务猎杀日",可以参考如下步骤:

早起:如果你不是一个通常很早起床的人,请调早你的闹钟。在5:00-6:00起床有两个作用。首先,它给你一段在上课,工作,或家人醒来前的安静时间。其次,它能建立一种成就感,这可以激励你度过一整天。

早操:这并非绝对必要,但我发现用跑步或在房间里做几个俯卧撑来开始新的一天是另一种非常好的激励方法。而且,三十分钟的晨练可以赶走你身体里昏昏沉沉的感觉。

固定的任务清单:在你开始这一天以前,写下所有你必须完成的任务。一旦你完成这项清单,也就完成了一天的工作,然后你可以去做点真正想做的事情。有一个固定的工作目标可以让你更好的集中精力,“今天要工作一整天”,类似这种想法反而会导致拖延。

隔立自己:我的大部分工作是靠个人完成。这意味着,在“任务猎杀日”里,我的社交活动几乎为零。为了可以集中精力而不分心,就做一天的隐士吧。锁上房间或办公室的大门,直到你解决掉清单上的所有任务。

断“线”:电视、网络、Facebook、电话和即时通讯在这一天里都要保持离线。如果你实在需要互联网(比如:回电子邮件是工作清单的一部分)那么就专注于你的任务,别去做其他的。如果你沉溺于到处在网络闲逛,那就断线吧。

重要的工作优先:关于如何组织你的工作这个问题,那就是大石头优先!也就是把要完成的最重要的任务放在一天的开始,而不是结束。这样,你就能把你的焦点放在当前最重要的任务上。当然这一条也有例外,但你得把它作为一项总原则来遵循。

没有中途休息:在这一天中,任何形式的休息都应该尽量减少。但尤其是任务当中的休息。只有当你完成清单上相当一部分的工作后,你才能站起来去喘口气。如果你的论文只写到一半,先结束它,然后再去吃午饭。

休息最少化:一天没有悠闲的咖啡时光不会杀了你。我的原则是,大的任务之间有5分钟休息或花费20-30分钟来解决三餐都是可行的。但别到处闲晃,即使只有1小时。除非你已解决掉所有的项目,否则这会让你的一天以失败告终。

集中琐事:集中你全部的琐事(扔垃圾,修门铰链,装订等) ,然后一次解决。这可以帮助提高效率,因为它能减少工作流程的中断次数。

加快走路步伐:在这一天里,对于你做的每件事,你都得专注并且有紧迫感。如果在任务间要拿点什么东西,加快走路步伐能提醒你还有一个重要的使命要完成:清空你的任务清单。如果你需要通勤或开车,在这段时间里可以放盘磁带来提醒自己——你没有时间能随意浪费。

加速:一次承担所有任务并加速完成它们。我常常一次写几千字,甚至曾经一连写过30页的电子书。通常,人们很难拒绝休息的诱惑,但一旦你进入状态,请竭尽所能来维持它。

做重要的事,不仅是紧急的事:这条前面已说过,但它需要被再次提到。任务猎杀日是用来解决那些重要的长期的工作的,也就是说不要把时间仅仅放在当前问题的解决上。我建议在一天行程当中安排一个不亟须完成的长期计划。参考阅读《为什么要区分紧急与重要任务》

放一天假:在成功的处理完所有待办事项的一天后,给自己放天假。这可以帮助你在经历了一整天疲劳的工作后恢复精力。即使你第二天什么都不做,前几天的超前工作通常可以弥补。花一些时间与你的家人相处,读一本书,或是睡到中午。经过了三倍效率的一天,你值得拥有这些!

    * 弥缝啰嗦

“任务猎杀日”感觉就像是考试抱佛脚一样,临时进入紧急状态,开始忙碌。虽然这样集中起来完成任务效果不错,但这不能说明你应该经常进行任务猎杀日。如果你要启动任务猎杀日了,那说明前一段时间你都没有好好利用时间。所以除了要赶快完成堆积的任务外,你还应该反省一下为什么会有这么多任务聚集起来未完成!

2008年1月21日

zz Java语言编码规范

名称    Java语言编码规范(Java Code Conventions)
译者    晨光(Morning)
简介    本文档讲述了Java语言的编码规范,较之陈世忠先生《c++编码规范》的浩繁详尽,此文当属短小精悍了。而其中所列之各项条款,从编码风格,到注意事项,不单只Java,对于其他语言,也都很有借鉴意义。因为简短,所以易记,大家不妨将此作为handbook,常备案头,逐一对验。
声明    如需复制、传播,请附上本声明,谢谢。
原文出处:http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html,
译文出处:http://morningspace.51.net/,moyingzz@etang.com

目录
1 介绍

    * 1.1 为什么要有编码规范
    * 1.2 版权声明

2 文件名

    * 2.1 文件后缀
    * 2.2 常用文件名

3 文件组织

    * 3.1 Java源文件
          o 3.1.1 开头注释
          o 3.1.2 包和引入语句
          o 3.1.3 类和接口声明

4 缩进排版

    * 4.1 行长度
    * 4.2 换行

5 注释

    * 5.1 实现注释的格式
          o 5.1.1 块注释
          o 5.1.2 单行注释
          o 5.1.3 尾端注释
          o 5.1.4 行末注释
    * 5.2 文挡注释

6 声明

    * 6.1 每行声明变量的数量
    * 6.2 初始化
    * 6.3 布局
    * 6.4 类和接口的声明

7 语句

    * 7.1 简单语句
    * 7.2 复合语句
    * 7.3 返回语句
    * 7.4 if,if-else,if else-if else语句
    * 7.5 for语句
    * 7.6 while语句
    * 7.7 do-while语句
    * 7.8 switch语句
    * 7.9 try-catch语句

8 空白

    * 8.1 空行
    * 8.2 空格

9 命名规范

10 编程惯例

    * 10.1 提供对实例以及类变量的访问控制
    * 10.2 引用类变量和类方法
    * 10.3 常量
    * 10.4 变量赋值
    * 10.5 其它惯例
          o 10.5.1 圆括号
          o 10.5.2 返回值
          o 10.5.3 条件运算符"?"前的表达式"?"前的表达式
          o 10.5.4 特殊注释

11 代码范例

    * 11.1 Java源文件范例

1 介绍(Introduction)

1.1 为什么要有编码规范(Why Have Code Conventions)

编码规范对于程序员而言尤为重要,有以下几个原因:

- 一个软件的生命周期中,80%的花费在于维护
- 几乎没有任何一个软件,在其整个生命周期中,均由最初的开发人员来维护
- 编码规范可以改善软件的可读性,可以让程序员尽快而彻底地理解新的代码
- 如果你将源码作为产品发布,就需要确任它是否被很好的打包并且清晰无误,一如你已构建的其它任何产品

为了执行规范,每个软件开发人员必须一致遵守编码规范。每个人。

1.2 版权声明(Acknowledgments)

本文档反映的是Sun MicroSystems公司,Java语言规范中的编码标准部分。主要贡献者包括:Peter King,Patrick Naughton,Mike DeMoney,Jonni Kanerva,Kathy Walrath以及Scott Hommel。

本文档现由Scott Hommel维护,有关评论意见请发至shommel@eng.sun.com

2 文件名(File Names)

这部分列出了常用的文件名及其后缀。

2.1 文件后缀(File Suffixes)

Java程序使用下列文件后缀:

文件类别    文件后缀
Java源文件    .java
Java字节码文件    .class

2.2 常用文件名(Common File Names)

常用的文件名包括:

文件名    用途
GNUmakefile    makefiles的首选文件名。我们采用gnumake来创建(build)软件。
README    概述特定目录下所含内容的文件的首选文件名

3 文件组织(File Organization)

一个文件由被空行分割而成的段落以及标识每个段落的可选注释共同组成。超过2000行的程序难以阅读,应该尽量避免。"Java源文件范例"提供了一个布局合理的Java程序范例。

3.1 Java源文件(Java Source Files)

每个Java源文件都包含一个单一的公共类或接口。若私有类和接口与一个公共类相关联,可以将它们和公共类放入同一个源文件。公共类必须是这个文件中的第一个类或接口。

Java源文件还遵循以下规则:

- 开头注释(参见"开头注释")
- 包和引入语句(参见"包和引入语句")
- 类和接口声明(参见"类和接口声明")

3.1.1 开头注释(Beginning Comments)

所有的源文件都应该在开头有一个C语言风格的注释,其中列出类名、版本信息、日期和版权声明:

  /*
   * Classname
   *
   * Version information
   *
   * Date
   *
   * Copyright notice
   */

3.1.2 包和引入语句(Package and Import Statements)

在多数Java源文件中,第一个非注释行是包语句。在它之后可以跟引入语句。例如:

  package java.awt;

  import java.awt.peer.CanvasPeer;

3.1.3 类和接口声明(Class and Interface Declarations)

下表描述了类和接口声明的各个部分以及它们出现的先后次序。参见"Java源文件范例"中一个包含注释的例子。

     类/接口声明的各部分    注解
1    类/接口文档注释(/**……*/)    该注释中所需包含的信息,参见"文档注释"
2    类或接口的声明    
3    类/接口实现的注释(/*……*/)如果有必要的话    该注释应包含任何有关整个类或接口的信息,而这些信息又不适合作为类/接口文档注释。
4    类的(静态)变量    首先是类的公共变量,随后是保护变量,再后是包一级别的变量(没有访问修饰符,access modifier),最后是私有变量。
5    实例变量    首先是公共级别的,随后是保护级别的,再后是包一级别的(没有访问修饰符),最后是私有级别的。
6    构造器    
7    方法    这些方法应该按功能,而非作用域或访问权限,分组。例如,一个私有的类方法可以置于两个公有的实例方法之间。其目的是为了更便于阅读和理解代码。

4 缩进排版(Indentation)

4个空格常被作为缩进排版的一个单位。缩进的确切解释并未详细指定(空格 vs. 制表符)。一个制表符等于8个空格(而非4个)。

4.1 行长度(Line Length)

尽量避免一行的长度超过80个字符,因为很多终端和工具不能很好处理之。

注意:用于文档中的例子应该使用更短的行长,长度一般不超过70个字符。

4.2 换行(Wrapping Lines)

当一个表达式无法容纳在一行内时,可以依据如下一般规则断开之:

- 在一个逗号后面断开
- 在一个操作符前面断开
- 宁可选择较高级别(higher-level)的断开,而非较低级别(lower-level)的断开
- 新的一行应该与上一行同一级别表达式的开头处对齐
- 如果以上规则导致你的代码混乱或者使你的代码都堆挤在右边,那就代之以缩进8个空格。

以下是断开方法调用的一些例子:

  someMethod(longExpression1, longExpression2, longExpression3,
                   longExpression4, longExpression5);

  var = someMethod1(longExpression1,
                            someMethod2(longExpression2,
                                               longExpression3));

以下是两个断开算术表达式的例子。前者更好,因为断开处位于括号表达式的外边,这是个较高级别的断开。

  longName1 = longName2 * (longName3 + longName4 - longName5)
                     + 4 * longname6; //PREFFER

  longName1 = longName2 * (longName3 + longName4
                                         - longName5) + 4 * longname6; //AVOID

以下是两个缩进方法声明的例子。前者是常规情形。后者若使用常规的缩进方式将会使第二行和第三行移得很靠右,所以代之以缩进8个空格

  //CONVENTIONAL INDENTATION
  someMethod(int anArg, Object anotherArg, String yetAnotherArg,
                    Object andStillAnother) {
    ...
  }

  //INDENT 8 SPACES TO AVOID VERY DEEP INDENTS
  private static synchronized horkingLongMethodName(int anArg,
          Object anotherArg, String yetAnotherArg,
          Object andStillAnother) {
    ...
  }

if语句的换行通常使用8个空格的规则,因为常规缩进(4个空格)会使语句体看起来比较费劲。比如:

  //DON’T USE THIS INDENTATION
  if ((condition1 && condition2)
      || (condition3 && condition4)
      ||!(condition5 && condition6)) { //BAD WRAPS
      doSomethingAboutIt();             //MAKE THIS LINE EASY TO MISS
  }

  //USE THIS INDENTATION INSTEAD
  if ((condition1 && condition2)
          || (condition3 && condition4)
          ||!(condition5 && condition6)) {
      doSomethingAboutIt();
  }

  //OR USE THIS
  if ((condition1 && condition2) || (condition3 && condition4)
          ||!(condition5 && condition6)) {
      doSomethingAboutIt();
  }

这里有三种可行的方法用于处理三元运算表达式:

  alpha = (aLongBooleanExpression) ? beta : gamma;

  alpha = (aLongBooleanExpression) ? beta
                                   : gamma;

  alpha = (aLongBooleanExpression)
          ? beta
          : gamma;

5 注释(Comments)

Java程序有两类注释:实现注释(implementation comments)和文档注释(document comments)。实现注释是那些在C++中见过的,使用/*...*/和//界定的注释。文档注释(被称为"doc comments")是Java独有的,并由/**...*/界定。文档注释可以通过javadoc工具转换成HTML文件。

实现注释用以注释代码或者实现细节。文档注释从实现自由(implementation-free)的角度描述代码的规范。它可以被那些手头没有源码的开发人员读懂。

注释应被用来给出代码的总括,并提供代码自身没有提供的附加信息。注释应该仅包含与阅读和理解程序有关的信息。例如,相应的包如何被建立或位于哪个目录下之类的信息不应包括在注释中。

在注释里,对设计决策中重要的或者不是显而易见的地方进行说明是可以的,但应避免提供代码中己清晰表达出来的重复信息。多余的的注释很容易过时。通常应避免那些代码更新就可能过时的注释。

注意:频繁的注释有时反映出代码的低质量。当你觉得被迫要加注释的时候,考虑一下重写代码使其更清晰。

注释不应写在用星号或其他字符画出来的大框里。注释不应包括诸如制表符和回退符之类的特殊字符。

5.1 实现注释的格式(Implementation Comment Formats)

程序可以有4种实现注释的风格:块(block)、单行(single-line)、尾端(trailing)和行末(end-of-line)。

5.1.1 块注释(Block Comments)

块注释通常用于提供对文件,方法,数据结构和算法的描述。块注释被置于每个文件的开始处以及每个方法之前。它们也可以被用于其他地方,比如方法内部。在功能和方法内部的块注释应该和它们所描述的代码具有一样的缩进格式。

块注释之首应该有一个空行,用于把块注释和代码分割开来,比如:

  /*
   * Here is a block comment.
   */

块注释可以以/*-开头,这样indent(1)就可以将之识别为一个代码块的开始,而不会重排它。

  /*-
    * Here is a block comment with some very special
    * formatting that I want indent(1) to ignore.
    *
    *    one
    *        two
    *            three
    */

注意:如果你不使用indent(1),就不必在代码中使用/*-,或为他人可能对你的代码运行indent(1)作让步。

参见"文档注释"

5.1.2 单行注释(Single-Line Comments)

短注释可以显示在一行内,并与其后的代码具有一样的缩进层级。如果一个注释不能在一行内写完,就该采用块注释(参见"块注释")。单行注释之前应该有一个空行。以下是一个Java代码中单行注释的例子:

  if (condition) {

    /* Handle the condition. */
    ...
  }

5.1.3 尾端注释(Trailing Comments)

极短的注释可以与它们所要描述的代码位于同一行,但是应该有足够的空白来分开代码和注释。若有多个短注释出现于大段代码中,它们应该具有相同的缩进。

以下是一个Java代码中尾端注释的例子:

  if (a == 2) {
      return TRUE;              /* special case */
  } else {
      return isPrime(a);         /* works only for odd a */
  }

5.1.4 行末注释(End-Of-Line Comments)

注释界定符"//",可以注释掉整行或者一行中的一部分。它一般不用于连续多行的注释文本;然而,它可以用来注释掉连续多行的代码段。以下是所有三种风格的例子:

  if (foo > 1) {

      // Do a double-flip.
      ...
  }
  else {
      return false;          // Explain why here.
  }

  //if (bar > 1) {
  //
  //    // Do a triple-flip.
  //    ...
  //}
  //else {
  //    return false;
  //}

5.2 文档注释(Documentation Comments)

注意:此处描述的注释格式之范例,参见"Java源文件范例"

若想了解更多,参见"How to Write Doc Comments for Javadoc",其中包含了有关文档注释标记的信息(@return, @param, @see):

http://java.sun.com/javadoc/writingdoccomments/index.html

若想了解更多有关文档注释和javadoc的详细资料,参见javadoc的主页:

http://java.sun.com/javadoc/index.html

文档注释描述Java的类、接口、构造器,方法,以及字段(field)。每个文档注释都会被置于注释定界符/**...*/之中,一个注释对应一个类、接口或成员。该注释应位于声明之前:

  /**
    * The Example class provides ...
    */
  public class Example { ...

注意顶层(top-level)的类和接口是不缩进的,而其成员是缩进的。描述类和接口的文档注释的第一行(/**)不需缩进;随后的文档注释每行都缩进1格(使星号纵向对齐)。成员,包括构造函数在内,其文档注释的第一行缩进4格,随后每行都缩进5格。

若你想给出有关类、接口、变量或方法的信息,而这些信息又不适合写在文档中,则可使用实现块注释(见5.1.1)或紧跟在声明后面的单行注释(见5.1.2)。例如,有关一个类实现的细节,应放入紧跟在类声明后面的实现块注释中,而不是放在文档注释中。

文档注释不能放在一个方法或构造器的定义块中,因为Java会将位于文档注释之后的第一个声明与其相关联。

6 声明(Declarations)

6.1 每行声明变量的数量(Number Per Line)

推荐一行一个声明,因为这样以利于写注释。亦即,

  int level;  // indentation level
  int size;   // size of table

要优于,

int level, size;

不要将不同类型变量的声明放在同一行,例如:

  int foo,  fooarray[];   //WRONG!

注意:上面的例子中,在类型和标识符之间放了一个空格,另一种被允许的替代方式是使用制表符:

  int        level;         // indentation level
  int        size;          // size of table
  Object    currentEntry;  // currently selected table entry

6.2 初始化(Initialization)

尽量在声明局部变量的同时初始化。唯一不这么做的理由是变量的初始值依赖于某些先前发生的计算。

6.3 布局(Placement)

只在代码块的开始处声明变量。(一个块是指任何被包含在大括号"{"和"}"中间的代码。)不要在首次用到该变量时才声明之。这会把注意力不集中的程序员搞糊涂,同时会妨碍代码在该作用域内的可移植性。

  void myMethod() {
      int int1 = 0;         // beginning of method block

      if (condition) {
          int int2 = 0;     // beginning of "if" block
          ...
      }
  }

该规则的一个例外是for循环的索引变量

  for (int i = 0; i < maxLoops; i++) { ... }

避免声明的局部变量覆盖上一级声明的变量。例如,不要在内部代码块中声明相同的变量名:

  int count;
  ...
  myMethod() {
      if (condition) {
          int count = 0;     // AVOID!
          ...
      }
      ...
  }

6.4 类和接口的声明(Class and Interface Declarations)

当编写类和接口是,应该遵守以下格式规则:

- 在方法名与其参数列表之前的左括号"("间不要有空格
- 左大括号"{"位于声明语句同行的末尾
- 右大括号"}"另起一行,与相应的声明语句对齐,除非是一个空语句,"}"应紧跟在"{"之后

  class Sample extends Object {
      int ivar1;
      int ivar2;

      Sample(int i, int j) {
          ivar1 = i;
          ivar2 = j;
      }

      int emptyMethod() {}

      ...
  }

- 方法与方法之间以空行分隔

7 语句(Statements)

7.1 简单语句(Simple Statements)

每行至多包含一条语句,例如:

  argv++;       // Correct
  argc--;       // Correct
  argv++; argc--;       // AVOID!

7.2 复合语句(Compound Statements)

复合语句是包含在大括号中的语句序列,形如"{ 语句 }"。例如下面各段。

- 被括其中的语句应该较之复合语句缩进一个层次
- 左大括号"{"应位于复合语句起始行的行尾;右大括号"}"应另起一行并与复合语句首行对齐。
- 大括号可以被用于所有语句,包括单个语句,只要这些语句是诸如if-else或for控制结构的一部分。这样便于添加语句而无需担心由于忘了加括号而引入bug。

7.3 返回语句(return Statements)

一个带返回值的return语句不使用小括号"()",除非它们以某种方式使返回值更为显见。例如:

  return;

  return myDisk.size();

  return (size ? size : defaultSize);

7.4 if,if-else,if else-if else语句(if, if-else, if else-if else Statements)

if-else语句应该具有如下格式:

  if (condition) {
      statements;
  }

  if (condition) {
      statements;
  } else {
      statements;
  }

  if (condition) {
      statements;
  } else if (condition) {
      statements;
  } else{
      statements;
  }

注意:if语句总是用"{"和"}"括起来,避免使用如下容易引起错误的格式:

  if (condition) //AVOID! THIS OMITS THE BRACES {}!
      statement;

7.5 for语句(for Statements)

一个for语句应该具有如下格式:

  for (initialization; condition; update) {
      statements;
  }

一个空的for语句(所有工作都在初始化,条件判断,更新子句中完成)应该具有如下格式:

  for (initialization; condition; update);

当在for语句的初始化或更新子句中使用逗号时,避免因使用三个以上变量,而导致复杂度提高。若需要,可以在for循环之前(为初始化子句)或for循环末尾(为更新子句)使用单独的语句。

7.6 while语句(while Statements)

一个while语句应该具有如下格式

  while (condition) {
      statements;
  }

一个空的while语句应该具有如下格式:

  while (condition);

7.7 do-while语句(do-while Statements)

一个do-while语句应该具有如下格式:

  do {
      statements;
  } while (condition);

7.8 switch语句(switch Statements)

一个switch语句应该具有如下格式:

  switch (condition) {
  case ABC:
      statements;
      /* falls through */
  case DEF:
      statements;
      break;

  case XYZ:
      statements;
      break;

  default:
      statements;
      break;
  }

每当一个case顺着往下执行时(因为没有break语句),通常应在break语句的位置添加注释。上面的示例代码中就包含注释/* falls through */。

7.9 try-catch语句(try-catch Statements)

一个try-catch语句应该具有如下格式:

  try {
      statements;
  } catch (ExceptionClass e) {
      statements;
  }

一个try-catch语句后面也可能跟着一个finally语句,不论try代码块是否顺利执行完,它都会被执行。

  try {
      statements;
  } catch (ExceptionClass e) {
      statements;
  } finally {
      statements;
  }

8 空白(White Space)

8.1 空行(Blank Lines)

空行将逻辑相关的代码段分隔开,以提高可读性。

下列情况应该总是使用两个空行:

- 一个源文件的两个片段(section)之间
- 类声明和接口声明之间

下列情况应该总是使用一个空行:

- 两个方法之间
- 方法内的局部变量和方法的第一条语句之间
- 块注释(参见"5.1.1")或单行注释(参见"5.1.2")之前
- 一个方法内的两个逻辑段之间,用以提高可读性

8.2 空格(Blank Spaces)

下列情况应该使用空格:

- 一个紧跟着括号的关键字应该被空格分开,例如:

  while (true) {
      ...
  }

注意:空格不应该置于方法名与其左括号之间。这将有助于区分关键字和方法调用。
- 空白应该位于参数列表中逗号的后面
- 所有的二元运算符,除了".",应该使用空格将之与操作数分开。一元操作符和操作数之间不因该加空格,比如:负号("-")、自增("++")和自减("--")。例如:

    a += c + d;
    a = (a + b) / (c * d);

    while (d++ = s++) {
        n++;
    }
    printSize("size is " + foo + "\n");

- for语句中的表达式应该被空格分开,例如:

    for (expr1; expr2; expr3)

- 强制转型后应该跟一个空格,例如:

    myMethod((byte) aNum, (Object) x);
    myMethod((int) (cp + 5), ((int) (i + 3)) + 1);

9 命名规范(Naming Conventions)

命名规范使程序更易读,从而更易于理解。它们也可以提供一些有关标识符功能的信息,以助于理解代码,例如,不论它是一个常量,包,还是类。

标识符类型     命名规则     例子
包(Packages)     一个唯一包名的前缀总是全部小写的ASCII字母并且是一个顶级域名,通常是com,edu,gov,mil,net,org,或1981年ISO 3166标准所指定的标识国家的英文双字符代码。包名的后续部分根据不同机构各自内部的命名规范而不尽相同。这类命名规范可能以特定目录名的组成来区分部门(department),项目(project),机器(machine),或注册名(login names)。     com.sun.eng
com.apple.quicktime.v2
edu.cmu.cs.bovik.cheese
类(Classes)     命名规则:类名是个一名词,采用大小写混合的方式,每个单词的首字母大写。尽量使你的类名简洁而富于描述。使用完整单词,避免缩写词(除非该缩写词被更广泛使用,像URL,HTML)     class Raster;
class ImageSprite;
接口(Interfaces)     命名规则:大小写规则与类名相似     interface RasterDelegate;
interface Storing;
方法(Methods)     方法名是一个动词,采用大小写混合的方式,第一个单词的首字母小写,其后单词的首字母大写。     run();
runFast();
getBackground();
变量(Variables)     除了变量名外,所有实例,包括类,类常量,均采用大小写混合的方式,第一个单词的首字母小写,其后单词的首字母大写。变量名不应以下划线或美元符号开头,尽管这在语法上是允许的。
变量名应简短且富于描述。变量名的选用应该易于记忆,即,能够指出其用途。尽量避免单个字符的变量名,除非是一次性的临时变量。临时变量通常被取名为i,j,k,m和n,它们一般用于整型;c,d,e,它们一般用于字符型。     char c;
int i;
float myWidth;
实例变量(Instance Variables)     大小写规则和变量名相似,除了前面需要一个下划线     int _employeeId;
String _name;
Customer _customer;
常量(Constants)     类常量和ANSI常量的声明,应该全部大写,单词间用下划线隔开。(尽量避免ANSI常量,容易引起错误)     static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;

10 编程惯例(Programming Practices)

10.1 提供对实例以及类变量的访问控制(Providing Access to Instance and Class Variables)

若没有足够理由,不要把实例或类变量声明为公有。通常,实例变量无需显式的设置(set)和获取(gotten),通常这作为方法调用的边缘效应 (side effect)而产生。

一个具有公有实例变量的恰当例子,是类仅作为数据结构,没有行为。亦即,若你要使用一个结构(struct)而非一个类(如果java支持结构的话),那么把类的实例变量声明为公有是合适的。

10.2 引用类变量和类方法(Referring to Class Variables and Methods)

避免用一个对象访问一个类的静态变量和方法。应该用类名替代。例如:

  classMethod();             //OK
  AClass.classMethod();      //OK
  anObject.classMethod();    //AVOID!

10.3 常量(Constants)

位于for循环中作为计数器值的数字常量,除了-1,0和1之外,不应被直接写入代码。

10.4 变量赋值(Variable Assignments)

避免在一个语句中给多个变量赋相同的值。它很难读懂。例如:

  fooBar.fChar = barFoo.lchar = 'c'; // AVOID!

不要将赋值运算符用在容易与相等关系运算符混淆的地方。例如:

  if (c++ = d++) {        // AVOID! (Java disallows)
      ...
  }

应该写成

  if ((c++ = d++) != 0) {
    ...
  }

不要使用内嵌(embedded)赋值运算符试图提高运行时的效率,这是编译器的工作。例如:

  d = (a = b + c) + r;        // AVOID!

应该写成

  a = b + c;
  d = a + r;

10.5 其它惯例(Miscellaneous Practices)

10.5.1 圆括号(Parentheses)

一般而言,在含有多种运算符的表达式中使用圆括号来避免运算符优先级问题,是个好方法。即使运算符的优先级对你而言可能很清楚,但对其他人未必如此。你不能假设别的程序员和你一样清楚运算符的优先级。

  if (a == b && c == d)     // AVOID!
  if ((a == b) && (c == d))  // RIGHT

10.5.2 返回值(Returning Values)

设法让你的程序结构符合目的。例如:

  if (booleanExpression) {
      return true;
  } else {
      return false;
  }

应该代之以如下方法:

  return booleanExpression;

类似地:

  if (condition) {
      return x;
  }
  return y;

应该写做:

  return (condition ? x : y);

10.5.3 条件运算符"?"前的表达式(Expressions before '?' in the Conditional Operator)

如果一个包含二元运算符的表达式出现在三元运算符" ? : "的"?"之前,那么应该给表达式添上一对圆括号。例如:

  (x >= 0) ? x : -x;

10.5.4 特殊注释(Special Comments)

在注释中使用XXX来标识某些未实现(bogus)的但可以工作(works)的内容。用FIXME来标识某些假的和错误的内容。

11 代码范例(Code Examples)

11.1 Java源文件范例(Java Source File Example)

下面的例子,展示了如何合理布局一个包含单一公共类的Java源程序。接口的布局与其相似。更多信息参见"类和接口声明"以及"文挡注释"。

/*
* @(#)Blah.java        1.82 99/03/18
*
* Copyright (c) 1994-1999 Sun Microsystems, Inc.
* 901 San Antonio Road, Palo Alto, California, 94303, U.S.A.
* All rights reserved.
*
* This software is the confidential and proprietary information of Sun
* Microsystems, Inc. ("Confidential Information").  You shall not
* disclose such Confidential Information and shall use it only in
* accordance with the terms of the license agreement you entered into
* with Sun.
*/

package java.blah;

import java.blah.blahdy.BlahBlah;

/**
* Class description goes here.
*
* @version     1.82 18 Mar 1999
* @author     Firstname Lastname
*/
public class Blah extends SomeClass {
    /* A class implementation comment can go here. */

    /** classVar1 documentation comment */
    public static int classVar1;

    /**
     * classVar2 documentation comment that happens to be
     * more than one line long
     */
    private static Object classVar2;

    /** instanceVar1 documentation comment */
    public Object instanceVar1;

    /** instanceVar2 documentation comment */
    protected int instanceVar2;

    /** instanceVar3 documentation comment */
    private Object[] instanceVar3;

    /**
     * ...constructor Blah documentation comment...
     */
    public Blah() {
        // ...implementation goes here...
    }

    /**
     * ...method doSomething documentation comment...
     */
    public void doSomething() {
        // ...implementation goes here...
    }

    /**
     * ...method doSomethingElse documentation comment...
     * @param someParam description
     */
    public void doSomethingElse(Object someParam) {
        // ...implementation goes here...
    }
}

2008年1月20日

学做菜之甜椒肉丝

今天打算动手做一个甜椒肉丝。昨晚在老爸老妈的电话指导下知道了整个流程,想不到做这个菜居然还需要最后加芡汁。为了更加清楚,在网上找到如下介绍,想不到和爸妈说的几乎一模一样。佩服老爸老妈啊!今晚就按照这个做咯!

    * 【菜名】 甜椒肉丝
    * 【菜系】 川菜菜谱
    * 【主料】 猪肉
    * 【做法】 炒
    * 【味型】 清淡
    * 【成菜】 热菜

原料:猪肥瘦肉350克、甜椒100克、青蒜苗50克、嫩姜20克

调味料:水淀粉50克、盐少许、料酒20克、酱油10克、味精少许、鲜汤25克、甜酱20克

制作过程

1、猪肉切成粗丝,入碗加水淀粉、盐、料酒拌匀。

2、甜椒去蒂、籽,切成粗丝,嫩姜切细丝,蒜苗切小段。酱油、料酒、水淀粉、味精、鲜汤装碗内调匀成芡汁。

3、炒锅置火上,下油少许烧热,放入甜椒炒至断生后起锅。炒锅洗净置旺火上,下油烧热(约150℃,放肉丝炒散,加甜酱炒香,下甜椒、姜丝、青蒜苗合炒,烹入芡汁,炒匀起锅装盘即成。

美味小锦囊

◇青椒、红椒内含有维生素家族里知名度最高的维生素C,不过,人体无法贮存维生素C,别忘记时时补充、每天摄取!

◇肉丝在加水淀粉上浆前必须用清水充分浸泡,让肌肉纤维充分吸收水分、体形膨胀,并将带腥臊味的血浆完全泡出来。这样咸菜后色泽洁白、清爽不黏,还更加入味呢!

2008年1月18日

zz 如何参与团队合作

Link: http://www.mifengtd.cn/articles/how-to-participate-teamwork.html

现在,团队合作就是竞争力。随着市场竞争的日益激烈,企业更加强调团队精神,建立群体共识,以达到更高的工作效率。特别是有遇到大型项目时,想凭借一己之力去取得卓越的成果,可能非常困难。想必你也意识到,单打独斗的时代已经结束了,取而代之的真是团队合作!

团队的组成不是一个人,如何融入团队,和其它成员共同努力、精诚协助是件看起来很容易的事情,可事实却大相径庭。团队,除了要依靠卓越的领导者,每个成员都是使团队不断融合不可或缺的一份子。

打造一支高效的团队绝非一朝一夕之事,希望下面的一些建议能够帮助你更好的融入团队,积极参加团队合作。


领导者

领导者是团队的核心,是从全局角度把握整个团队方向的人。作为一个领导者,虽然你的权威级别是高一些,不过学会熟练地与别人一起完成更多的工作,都应该是为提示自身价值所能做的最重要的事。

    * 分工明确但不呆板明确的分工可以让每一位成员清楚的知道自己要做什么,什么时候做完,做到什么承度。这样就能够避免由于分工不明确而造成的部分人员闲置的问题。如果你还不太清楚怎样进行分工,那么你可以尝试给每一个任务都指定一个负责人,这是最简单的方法了。这里强调不能呆板的意思是说,当分工确定后,如果某一任务的负责人员遇到了某种困难而无法按期完成的时候,应该适当的调整分工或者让其它成员帮助他们完成。不要死守原来的分工。
    * 加强团队成员的日常交流不时的安排一些聚会或者组织素质拓展训练,一起吃饭,打打球,都是很好的加强团队成员间交流的方法。不要小看这一点,这是非常重要的。团队成员的日常交流可以让他们更加亲近,从而在工作中更容易进行合作。如果平时他们之间就有默契的话,在工作时的表现就更容易提高。
    * 说话时多使用我们在你说话的时候多使用我们这个代词,不要使用我、你、他或者直呼姓名,也要鼓励你的团队成员也这样做。这样可以帮助你的团队成员们形成一种集体意识,让他们从团队的角度去想问题,而不是总从自己出发。
    * 让每个人感觉到自己很重要你要让你团队中的每一个人都感到自己很重要,这样他们做事才会更有成就感,也更有紧迫感。一个人一旦觉得自己不重要,往往会非常沮丧,从而失去激情,这会导致工作效率和创造力的显著下降。

团队成员

每个团队成员都是不可或缺的,而且每一个团队成员都要具有团队合作的意识。无论你自身能力的强大,团队少了你依然会继续运行,所以不要枉自称大。

    * 做好自己的事情团队合作中,最起码的事情就是把自己的事情做好。团队的任务都是有分工的,分配给自己的任务就要按时做好。只有这样,你才能不给别人带来麻烦;也只有在这个前提下,你才能去帮助其他成员的事情,否则你就有些轻重不分了。
    * 信任你的伙伴既是团队成员,就要相信自己的伙伴,相信他们能够与你协调一致,相信他们会理解你,支持你。一个团队只有在信任的氛围中才可能有高效的工作。如果大家相互猜忌、互不信任,那么分工就不可能,因为总有一些任务依赖于别的任务;同时猜忌的气氛让每一个人都不能全心投入到工作中去,也不利于成员们工作能力的发挥。
    * 为他人着想不要事事都从自己的角度考虑。如果有任何问题或者遇到什么问题,先从别人的角度想一想,看看怎样能让他人更加方便。这样的人在团队当中会很受欢迎,同时也更有亲和力,而亲和力对于团队合作来说是很重要的。
    * 愿意多付出付出并不是什么坏事。多做一些,可以让团队的工作进展更快,你也得到更多的好评,能力上也有提高,何乐而不为呢?当然也不是付出的越多越好,如果所有的事都让你自己做了(虽然这一般是不可能的),其它的人一定会有意见的。

2008年1月17日

项目管理之甘特图

缘起:

        从明天开始,我将进入一个新的工作阶段,时间较长(两个月),目标确定,为了进行有效的时间管理以及任务分配,我打算采用软件工程的方法来进行管理。首先想到的就是甘特图。因为我指导的学生Zn,在上个月发给我他的个人项目计划时展示了一张甘特图,时间管理上非常清晰。回想自己大四的时候学习过这个东西,但是一直没有试验过。这次打算小试一下。

 

什么是甘特图:

甘特图(Gantt Chart)由亨利·甘特于1910年开发的,他通过条状图来显示项目,进度,和其他时间相关的系统进展的内在关系随着时间进展的情况。 其中,横轴表示时间,纵轴表示活动(项目)。线条表示在整个期间上计划和实际的活动完成情况。甘特图可以直观地表明任务计划在什么时候进行,及实际进展与计划要求的对比。管理者由此可以非常便利地弄清每一项任务(项目)还剩下哪些工作要做,并可评估工作是提前还是滞后,亦或正常进行。除此以外,甘特图还有简单、醒目和便于编制等特点。所以,甘特图对于项目管理是一种理想的控制工具。

甘特图的含义:

   1. 以图形或表格的形式显示活动;
   2. 现在是一种通用的显示进度的方法;
   3. 构造时应包括实际日历天和持续时间,并且不要将周末和节假日算在进度之内。

下面使用一个例子来简单说明甘特图:

时间以月为单位表示在图的下方,主要活动从上到下列在图的左边。计划需要确定数的出版包括哪些活动,这些活动的顺序,以及每项活动持续的时间。时间框里的线条表示计划的活动顺序,空白的现况表示活动的实际进度。甘特图作为一种控制工具,帮助管理者发现实际进度偏离计划的情况。在本例中,除了打印长条校样以外,其他活动都是按计划完成的。

甘特图的优点:

    * 图形化概要,通用技术,易于理解;
    * 中小型项目一般不超过30项活动;
    * 有专业软件支持,无须担心复杂计算和分析。

甘特图的局限:

    * 甘特图事实上仅仅部分地反映了项目管理的三重约束(时间、成本和范围),因为它主要关注进程管理(时间);
    * 软件的不足。尽管能够通过项目管理软件描绘出项目活动的内在关系,但是如果关系过多,纷繁芜杂的线图必将增加甘特图的阅读难度;
    * 为了不至于转移阅读者的注意力,还最好避免使用栅格。

另外,个人甘特图与平常我们使用的时间表是两种不同的任务表达方式。个人甘特图使用户可以直观地知道有哪些任务在什么时间段要做,而时间表则提供更精确的时间段数据。此外,用户还可以在时间表中直接更新任务进程。

制作甘特图的方法,有专门的软件如Ganttproject、Gantt Designer和Microsoft Project等等。当然你还可以在Microsoft Excel中手动绘制。这些弥缝将会在下次介绍。

 

甘特图(Gantt Chart)的制作步骤:

在开始介绍甘特图的制作步骤前,弥缝先向大家讲解一下什么是Work Breakdown Structure(WBS):

    WBS就是工作分解结构,就象一张道路交通图,它能够指引你如何从当前位置到达想去的地方。

因此,就有这么两个对于任务区分的概念:依赖性活动(Sequential activities)和决定性活动(Parallel activities)。有些任务需要一层一层的来完成,你需要先完成一项任务,才能继续下一项任务,这就是依赖性活动。而决定性活动则是指并不需要某一项任务结束后,就能开始的任务。

绘制甘特图的步骤:

   1. 明确项目牵涉到的各项活动、项目。内容包括项目名称(包括顺序)、开始时间、工期,任务类型(依赖/决定性)和依赖于哪一项任务。
   2. 创建甘特图草图。将所有的项目按照开始时间、工期标注到甘特图上。
   3. 确定项目活动依赖关系及时序进度。使用草图,并且按照项目的类型将项目联系起来,并且安排。
          * 此步骤将保证在未来计划有所调整的情况下,各项活动仍然能够按照正确的时序进行。
          * 也就是确保所有依赖性活动能并且只能在决定性活动完成之后按计划展开。
          * 避免关键性路径过长。关键性路径是由贯穿项目始终的关键性任务所决定的,它既表示了项目的最长耗时, 也表示了完成项目的最短可能时间。请注意,关键性路径会由于单项活动进度的提前或延期而发生变化。
          * 不要滥用项目资源,同时,对于进度表上的不可预知事件要安排适当的富裕时间(Slack Time)。 但是,富裕时间不适用于关键性任务,因为作为关键性路径的一部分,它们的时序进度对整个项目至关重要。
   4. 计算单项活动任务的工时量。
   5. 确定活动任务的执行人员及适时按需调整工时。
   6. 计算整个项目时间。专业性软件可以自动完成该项工作。

 

软件支持:

首推GanttProject,因为开源,而且经过实践,确实非常的方便,可以参见Demo。

2008年1月16日

Python提高建议(Python Enhancement Proposals)

今天发现了Python的一个提高编程技能的系列文章,是Python.org网站上提供的。仔细一看,足足有224篇,全都是Python的大牛们的撰写,想不到不是任何文章这里都收录的,居然还有像论文发表那样的流程:

有空得多读读啊,也算是对自己编程能力的一种训练吧。哎!俺现在的编程技巧很混乱,不系统啊。

 

差点忘了添加链接:

Index of Python Enhancement Proposals (PEPs)

2008年1月15日

Learning Epydoc

Epydoc 是什么,Epydoc好吃么?呵呵,这个是Zn在Lilacbbs上留言的模板 :)

先看看这个东西是什么,有什么用,为什么一定要学它?

Epydoc是一个用于Python模块自动生成API文档的工具,主要基于Python模块的文档字符串(docstring),例如Epydoc本省的API文档(html)。一种名叫Epytext轻量级的标记语言被用来标记各种文档字符串,主要是在一些特定的标签上添加相关的信息,例如参数类型等等。Epydoc还可以接受reStructureText,Javadoc以及普通文本格式的docstring。更精彩的例子推荐NLTK的官方API文档。

Epydoc 是纯Python 实现的 Python 专用文档化工具,与Python 结合非常自然,稳定,可扩展,Python代码中的注释采用Epydoc规定的格式来撰写可以非常方便的生成程序的规范化API文档。可以说Epydoc是采用Python按照软件工程开发步骤中不可缺少的一环。

熟悉Python的朋友知道Python还有一个类似的工具可以使用,那就是Pydoc。它和Epydoc的关系是后者能够生成更加丰富和漂亮的文档。

 

下面说说怎么用Epydoc。在网上找了半天,也没有看到一个好的中文资料介绍如何使用这个工具。分为以下几步:

1.安装,参见英文版说明

从sf上下载并安装epydoc-3.0beta1.win32.exe

2.在代码中插入相关的各种格式的Docstring,例如下列标签:

py文献信息

@author: ...作者
@license: ...版权
@contact: ...联系

py状态信息
@version: ...版本推荐使用$Id$
@todo [ver]: ...改进,可以指定针对的版本

py模块信息
@var v: ...模块变量v说明
@type v: ...模块变量类型v说明

py函式信息

@param p: ...参数 p 说明
@type v: ...参数 p 类型说明
@return: ...返回值说明
@rtype v: ...返回值类型说明

py提醒信息

@note: ...注解
@attention: ...注意
@bug: ...问题
@warning: ...警告

py关联信息
@see: ...参考资料

py标签格式
@tag: 内容...

还可以插入url,交叉引用,分块等功能,参见文档化开发注释规范

3.相关工具推荐

现在最喜欢使用的Python IDE是Eclipse + Pydev,今天发现Pydev的Code Style里面可以针对Docstring进行设置,弄好后在编写代码的时候,适当的用Ctrl+1就可以获得自动的Docstring内容,再添加一些就能生成良好的文档了。

4.生成API文档的时候推荐使用GUI方式,省时省力。点击Pydoc安装文档下的gui.py即可。

 

如果是其他的编程语言推荐使用Doxygen,支持C++, C, Java, Objective-C, IDL (Corba and Microsoft flavors) 以及PHP, C# and D 等等语言。

 

总之,我是离不开这个东东了。