没有合适的资源?快使用搜索试试~ 我知道了~
Java编程规范 对java初学者有一定的帮助可以在编写程序代码时养成良好的习惯!
资源详情
资源评论
资源推荐
2 - File Names
1
Java Code Conventions
1 - Introduction
1.1 Why Have Code Conventions
Code conventions are important to programmers for a number of reasons:
• 80% of the lifetime cost of a piece of software goes to maintenance.
• Hardly any software is maintained for its whole life by the original author.
• Code conventions improve the readability of the software, 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.
For the conventions to work, every person writing software must conform to the code
conventions. Everyone.
1.2 Acknowledgments
This document reflects the Java language coding standards presented in the Java Language
Specification, from Sun Microsystems, Inc. Major contributions are from Peter King, Patrick
Naughton, Mike DeMoney, Jonni Kanerva, Kathy Walrath, and Scott Hommel.
This document is maintained by Scott Hommel. Comments should be sent to
shommel@eng.sun.com
2 - File Names
This section lists commonly used file suffixes and names.
2.1 File Suffixes
Java Software uses the following file suffixes:
File Type Suffix
Java source .java
Java bytecode .class
3 - File Organization
2
2.2 Common File Names
Frequently used file names include:
3 - File Organization
A file consists of sections that should be separated by blank lines and an optional comment
identifying each section.
Files longer than 2000 lines are cumbersome and should be avoided.
For an example of a Java program properly formatted, see “Java Source File Example” on page
18.
3.1 Java Source Files
Each Java source file contains a single public class or interface. When private classes and
interfaces are associated with a public class, you can put them in the same source file as the
public class. The public class should be the first class or interface in the file.
Java source files have the following ordering:
• Beginning comments (see “Beginning Comments” on page 2)
• Package and Import statements
• Class and interface declarations (see “Class and Interface Declarations” on page 3)
3.1.1 Beginning Comments
All source files should begin with a c-style comment that lists the class name, version
information, date, and copyright notice:
/*
*
Classname
*
*
Version information
*
*
Date
*
*
Copyright notice
*/
File Name Use
GNUmakefile The preferred name for makefiles.
We use gnumake to build our software.
README The preferred name for the file that summarizes the
contents of a particular directory.
3 - File Organization
3
3.1.2 Package and Import Statements
The first non-comment line of most Java source files is a package statement. After that,
import statements can follow. For example:
package java.awt;
import java.awt.peer.CanvasPeer;
3.1.3 Class and Interface Declarations
The following table describes the parts of a class or interface declaration, in the order that they
should appear. See “Java Source File Example” on page 18 for an example that includes
comments.
Part of Class/Interface
Declaration
Notes
1 Class/interface documentation
comment (/**...*/)
See “Documentation Comments” on page 8 for
information on what should be in this comment.
2 class or interface statement
3 Class/interface implementation
comment (/*...*/), if necessary
This comment should contain any class-wide or
interface-wide information that wasn’t appropri-
ate for the class/interface documentation com-
ment.
4 Class (static) variables First the public class variables, then the pro-
tected, then package level (no access modifier),
and then the private.
5 Instance variables First public, then protected, then package
level (no access modifier), and then private.
6 Constructors
7 Methods These methods should be grouped by functional-
ity rather than by scope or accessibility. For
example, a private class method can be in
between two public instance methods. The goal is
to make reading and understanding the code eas-
ier.
4 - Indentation
4
4 - Indentation
Four spaces should be used as the unit of indentation. The exact construction of the indentation
(spaces vs. tabs) is unspecified. Tabs must be set exactly every 8 spaces (not 4).
4.1 Line Length
Avoid lines longer than 80 characters, since they’re not handled well by many terminals and
tools.
Note: Examples for use in documentation should have a shorter line length—generally no
more than 70 characters.
4.2 Wrapping Lines
When an expression will not fit on a single line, break it according to these general principles:
• Break after a comma.
• Break before an operator.
• Prefer higher-level breaks to lower-level breaks.
• Align the new line with the beginning of the expression at the same level on the previous
line.
• If the above rules lead to confusing code or to code that’s squished up against the right
margin, just indent 8 spaces instead.
Here are some examples of breaking method calls:
someMethod(longExpression1, longExpression2, longExpression3,
longExpression4, longExpression5);
var = someMethod1(longExpression1,
someMethod2(longExpression2,
longExpression3));
Following are two examples of breaking an arithmetic expression. The first is preferred, since
the break occurs outside the parenthesized expression, which is at a higher level.
longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longname6; // PREFER
longName1 = longName2 * (longName3 + longName4
- longName5) + 4 * longname6; // AVOID
Following are two examples of indenting method declarations. The first is the conventional
case. The second would shift the second and third lines to the far right if it used conventional
indentation, so instead it indents only 8 spaces.
剩余19页未读,继续阅读
cyh123
- 粉丝: 1
- 资源: 7
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0