Sugguestions under Eclipse 3.0 and others
2004-07-02 17:30
651 查看
Sugguestions under Eclipse 3.0:
-------------------------------
[1]. Use Source -> Format(++F/,+F) to format the
codes every time before saving.
[2]. Use Source -> Organize Imports(++O) to organize the imports
[3]. Turn on the Javadoc's compiler option: Preferences: Java -> Compiler ->
Javadoc: Malformed Javadoc comment(Warning) & Missing Javadoc comment(Warning)
[4]. Try to clear the all the warning codes (using +1 to get quick fix)
before committing codes to CVS.
Sugguestions for the comment on codes:
--------------------------------------
[5]. Comment on every Interface class.
[6]. Comment should be given if a method is only called by a special class
(specially when the class is not in the same package).
[7]. When creating a public static method, try to comment it and try to write
a JUnit TestCase when necessary.
[8]. When creating a *Util class, try to comment every method and write
TestCase on every method.
Suggestions on DATA and UI relationship:
----------------------------------------
[9]. Try to seperate the DATA and UI into different class, and give every
DATA class a TestCase, and give every UI component a simple test(Simple means
that I do not have to launch the whole application to test it).
[10]. Mark the joint (make a comment) that DATA and UI interwined.
Further suggestions:
--------------------
[11]. Interface with only a single instance should be combined as a Class.
[12]. Interface with lots of instances should make a classical instance
an example and make detailed comment on it, and should notify the user to
read the example(tutorial) on every other instance Class.
[13]. If some classes' logic fit some classical model, try to comment out
such model, and give a URI for the reader to get a further reading.
[14]. Mark out(make comment with question mark and write down which place
confuses you on) the codes that you do not understand, so the other would
know the point and give explaination later.
[15]. Make further effort to explain how you make up the project step by
step, and make your further effort to repeat the steps and to quicken the
step, and make your codes strong enough for further steps which maybe
interrupt between the steps.
[1], [2], [3], [4], [5] should become our custom. [15] will be an advanced
sugguestion(Try to reach that level, you will be an expert).
ADDING MORE SUGGESTIONS ARE WELCOME
--Joz
--July 2, 2004
-------------------------------
[1]. Use Source -> Format(++F/,+F) to format the
codes every time before saving.
[2]. Use Source -> Organize Imports(++O) to organize the imports
[3]. Turn on the Javadoc's compiler option: Preferences: Java -> Compiler ->
Javadoc: Malformed Javadoc comment(Warning) & Missing Javadoc comment(Warning)
[4]. Try to clear the all the warning codes (using +1 to get quick fix)
before committing codes to CVS.
Sugguestions for the comment on codes:
--------------------------------------
[5]. Comment on every Interface class.
[6]. Comment should be given if a method is only called by a special class
(specially when the class is not in the same package).
[7]. When creating a public static method, try to comment it and try to write
a JUnit TestCase when necessary.
[8]. When creating a *Util class, try to comment every method and write
TestCase on every method.
Suggestions on DATA and UI relationship:
----------------------------------------
[9]. Try to seperate the DATA and UI into different class, and give every
DATA class a TestCase, and give every UI component a simple test(Simple means
that I do not have to launch the whole application to test it).
[10]. Mark the joint (make a comment) that DATA and UI interwined.
Further suggestions:
--------------------
[11]. Interface with only a single instance should be combined as a Class.
[12]. Interface with lots of instances should make a classical instance
an example and make detailed comment on it, and should notify the user to
read the example(tutorial) on every other instance Class.
[13]. If some classes' logic fit some classical model, try to comment out
such model, and give a URI for the reader to get a further reading.
[14]. Mark out(make comment with question mark and write down which place
confuses you on) the codes that you do not understand, so the other would
know the point and give explaination later.
[15]. Make further effort to explain how you make up the project step by
step, and make your further effort to repeat the steps and to quicken the
step, and make your codes strong enough for further steps which maybe
interrupt between the steps.
[1], [2], [3], [4], [5] should become our custom. [15] will be an advanced
sugguestion(Try to reach that level, you will be an expert).
ADDING MORE SUGGESTIONS ARE WELCOME
--Joz
--July 2, 2004
相关文章推荐
- 《java与模式》读书笔记2----软件的可维护性和可复用性
- 动态生成JAVA代码
- 开发structs的工具-myeclipse
- Java安全通信、数字证书及数字证书应用实践(zz)
- Java安全通信、数字证书及数字证书应用实践
- 一个无名内隐类的问题(Java)
- JAVA程序桥联数据库
- 三年Java、一年管理,效益真是从管理中来
- Eclipse的插件和应用
- eclipse3终于出来了。。。
- JavaMail实例详解
- show一下我所钟爱的Eclipse
- Java学习笔记001
- Eclipse调试"陷阱"
- one strange problem about spring 's setting property
- 基类和子类的调用顺序(C#,java)
- 一个获取文件crc32校验码的简洁的java类
- 一个实现MD5的简洁的java类
- Eclipse下的Jython开发工具(翻译)
- 深入Struts 1.1 -转贴