Eclipse Code Recommenders 正式发布，智能代码建议工具
Eclipse基金会今日发布了 Eclipse Code Recommenders 。这个项目是IDE 2.0 研究的一部分，目的是为Eclipse提供更智能的基于用户习惯的代码预测功能。目前这个项目支持JFace，SWT，JDT 和 Wordbench。 目前发布的 Eclipse Code Recommenders 0.5 为这个项目的
Eclipse基金会今日发布了 Eclipse Code Recommenders 。这个项目是IDE 2.0 研究的一部分，目的是为Eclipse提供更智能的基于用户习惯的代码预测功能。目前这个项目支持JFace，，SWT，JDT 和 Wordbench。
目前发布的 Eclipse Code Recommenders 0.5 为这个项目的插件提供了一个全新的命名。所以用户必须卸载之前的版本，然后全新安装最新的版本。另外一个新的改进是Recommenders现在触发代码提示的时候实时分析所有的编译单元。这样开发者就可以在他们的项目用使用Code Recommenders而不用修改项目的配置文件。
这个项目目前使用 Eclipse Java Development Tools 作为分析工具的基础。之前的版本是基于 T.J. Watson 分析库 （WALA）。WALA仍然会被用于对复杂代码的分析和数据导出。你可以在这个公告（）中查看到其他的更新和改进，包括将来的开发计划。
你最喜欢的Eclipse（49）
在日的EclipseCon上，Codetrails。Code Recommenders项目源于这样一个想法——在开发人员使用不熟悉或者缺少详细文档的API时，。作为Eclipse Juno发行序列的一部分推出，它通过分析代码频率模式并将分析结果展示给开发人员来实现代码推荐功能。
第一个版本有一个嵌入式语料库，其中包含了关于核心Java库和多种Eclipse开源库的知识。举例来说，该知识库允许智能代码补全，即把当前上下文中最相关的方法推荐给开发人员。
swtTextWidget = new Text(container, SWT.NONE);
swtTextWidget.
setLayoutData(Object layoutData) : void – Control – 80%setText(String string) : void – Control – 53%addModifyListener(ModifyListener listener) : void – Text – 38%
每当开发人员使用支持的API（如上例中的SWT）时，Code Recommenders会自动从Eclipse服务器上逐个下载知识库。
Code Recommenders 1.0的基本代码与Eclipse UI的代码紧紧地捆绑在一起，使它很难在Eclipse IDE之外使用。Code Recommenders 2.0已经将推荐引擎从Eclipse特有的UI组件中重构出来，上述情况不复存在。该工具在Eclipse UI中的集成仍然以一种类似的方式出现，但现在可以在Headless模式下运行，比如，生成带注释的JavaDoc文档：
protected Control createDialogArea(Composite parent)
创建和返回对话框上部（按钮栏上方）的内容。
参见: 重载createDialogArea方法的子类通常也会重载下面两个方法：
configureShell(Shell): 63%okPressed(): 51%
建立在Code Recommenders 2.0基础上的另一项创新是新的上下文相关推荐功能，它考虑了代码补全功能触发点所在的方法的名称。例如，在setter或create方法中，与dispose（）相比，更可能调用SWT Text类的getText（）。而在一个名为dispose（）的方法中，最可能调用的Text类的方法是dispose（）。通过选取封闭方法上下文中的第一个单词（使用lowerCamelCase），推荐准确度可以得到提升。
是一个正在孵化中的项目，提供一种在一个集中的位置与其他人共享代码片段的方法。它还不是Code Recommenders 2.0的一部分，但已经相对稳定，很可能被整合到未来的版本中。
增加Crowd支持。该功能建立在Code Recommenders 2.0基础上，允许通过私有服务器在团队成员之间或者通过在整个社区范围内共享库分析结果。在后一种情况下，开发人员要根据白名单包的列表准确指定需要发送的代码补全事件（在用户从下拉列表中选择一项代码补全时发送）。可以在社区范围内共享事件的默认包列表中包含了多种开源库：
android*com.google.*java.*javafx.*javax.*org.apache.*org.eclipse.*org.jboss.*org.w3c.*org.xml.*
因此，使用插件时不应该对社区服务器暴露任何个人或内部的代码路径。作为选择，开发人员可以使用私有的Codetrails服务器，这样自然就可以在团队成员间共享任何内容。
是一个独立的库，可以分析现有的编译代码库，并提供建议供希望搭建自己服务器的组织使用；Code Trails公司提供了使用私有服务器的。将来，Codetrails Connect插件可能支持其它语言。
读者可以从或者上安装Code Recommenders 2.0。关于Codetrails Connect或ControlFlow服务的更多信息，参见的网站。
查看英文原文：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：493508次
积分：6605
积分：6605
排名：第2439名
原创：170篇
转载：109篇
评论：77条
(2)(1)(3)(4)(8)(6)(1)(2)(5)(1)(1)(3)(15)(7)(22)(8)(7)(1)(2)(2)(8)(3)(18)(42)(80)(28)常用插件：
Subversion，SVN客户端插件，该插件由Eclipse官方支持，与第三方Subclipse不分伯仲。可从Eclipse Marketplace中可直接下载安装
Properties Editor，属性文件编辑器插件，可从Eclipse Marketplace中可直接下载安装
StartExplorer，Windows 中资源目录管理插件，非常好用且方便，可快速进入目录或者CMD，可从Eclipse Marketplace中可直接下载安装
Eclipse Code Recommenders，代码智能提示插件，链接地址：
，可从Eclipse Marketplace中可直接下载安装
常用设置：
去掉不必要的启动项目
Window & Preferences & General & Startup and Shutdown
修改eclipse.ini文件
-XX:PermSize=128m
-XX:MaxPermSize=256m
-XX:ReservedCodeCacheSize=64m
关闭不必要的校验
Windows & Perferences & Validation & 将Build下的勾选去掉，只留下：Classpath Dependency Validator，其它都取消。（在需要验证某个文件的时候，我们可以单独去验证它，方法是：在需要验证的文件上右击 & Validation）
去掉拼写检查
Window & Perferences & General & Editors & Text Editors & Spelling & 去掉Enable spell checking复选框的勾选。
更改默认的JRE
Window & Perferences & Java & Installed JREs & 单击[Add...]按钮添加自己安装的JDK（注意不是普通的JRE）
更改字符编码格式
Window-&Perferences-&General-&Workspace，其中的Text file encoding修改为：UTF-8
设置眼睛保护色
Window-&Perferences-&General-&Editors-&Text Editors-&Background Color，RGB：204，232，207
调整Java和XML的宽度到：180
Java-&Code Style-&Formatter, 基于Eclipse-Buildin new 一个出来，设置Line Wrapping 和 Comments里的Line Width。同时修改XML-&XML Files-&Editor。
设置JavaDoc格式
依然是Java-&Code Style-&Formatter，在new出来的profile中，Comments里， 勾选Never Join lines，取消 New Line after @param tags
设置Package Explorer展现
View Menu-&Package presentation-&Hierarchical.
设置Console
取消Limit Console Output.
相关 [eclipse 插件] 推荐：
- 博客园_首页
最近找到一个Eclipse的插件，名字是Easy Explore，是
Easy Structs 其 中的一个部分. 主要的功能就是在Eclipse里面视图的部分如果看到自己的工程，或者Package，包什么的，在安装完该插件以后点击鼠标右键，选 择&Easy Explore&就可以快速的打开该文件的windows存放文件夹，对于快速的导出源文件是一个很有用的插件.
- CSDN博客研发管理推荐文章
Eclipse的应用需要众多的插件，但是Eclipse的插件大家又知道多少呢. 1、PyDev – Eclipse的Python开发环境. Pydev这个插件能够让用户利用Eclipse进行Python、Jython以及Iron Python开发，使Eclipse成为一流的Python IDE（集成开发环境）.
- 开源软件 - ITeye博客
Subversion，SVN客户端插件，该插件由Eclipse官方支持，与第三方Subclipse不分伯仲. 可从Eclipse Marketplace中可直接下载安装. Properties Editor，属性文件编辑器插件，可从Eclipse Marketplace中可直接下载安装. StartExplorer，Windows 中资源目录管理插件，非常好用且方便，可快速进入目录或者CMD，可从Eclipse Marketplace中可直接下载安装.
今天为使用Eclipse的程序员们，收集一些比较高效的插件，这些插件可以帮助你提高工作效率. Properties Editor 编辑java的属性文件，并可以自动存盘为Unicode格式，在写一下配置文件的时候，不用工具生成. 官网：
http://propedit.sourceforge.jp/index_en.html .
- 编程语言 - ITeye博客
群里有一哥们儿安装Activiti的Eclipse插件安装了2天了还没装好，我看了都快急死了，好人做到底，特地为他写了这篇博客.
下载完成后，你将得到一个zip压缩包如图：.
然后在任意盘符新建一个文件夹用来存放解压后的文件，这里我是在E盘新建一个activiti-designer-0.6.0文件夹，如图：.
- Will - ITeye资讯频道
WireframeSketcher 2.7.0 发布了.
WireframeSketcher是一个Eclipse 插件，用于创建线框图、界面模型和UI原型. 在项目正式开发前创建原型有利于用户和开发者理解系统，在Eclipse中使用WireframeSketcher能够更好的进入项目开发流程.
- 博客 - 伯乐在线
Eclipse提供了一个可扩展插件的开发系统. 这就使得Eclipse在运行系统之上可以实现各种功能. 这些插件也不同于其他的应用（插件的功能是最难用代码实现的）. 拥有合适的Eclipse插件是非常重要的，因为它们能让Java开发者们无缝的开发基于J2EE和服务的应用程序. Eclipse的插件也能帮助他们开发不同应用架构上的程序.
- Taobao QA Team
公司很多产品会使用zookeeper,比如Meta消息中间件,在测试的过程中,我们经常需要查询zookeeper里面的信息来精确定位问题. 目前项目中有开发团队自己写的浏览器node-zk-browser，是基于node.js的express.js框架和node-zookeeper客户端实现的,具体可参考
/killme2008/node-zk-browser.
- ITeye资讯频道
Eclipse成为最流行的集成开发环境，在很大程度上要归功于它跨平台的插件支持系统. 通过将各种类型的插件添加到Eclipse中，可以扩充Eclipse的功能，以满足你的各种需求. 目前有许多款流行的Eclipse插件，其中一些很流行，有一些很时尚，还有一些仅仅是功能新巧，所有的这些功能各异的插件构成了强大的Eclipse，并不断为它的发展添加活力.
- tinda - ITeye资讯频道
Protobuf-dt是Google针对Eclipse编辑器开发的协议缓冲器插件，提供所有IDE编辑器所具备的功能，包括语法高亮、大纲视图、内容协助和超链接. Protobuf-dt还可提供跟协议缓冲器有关的功能，包括自动生成数字标签、Java式的文档和protoc整合. Google员工之前已经在多个内部工程里测试并使用了Protobuf-dt，所以你大可放心.
坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：@。The motivation section is important. Coding standards and guidelines tend to start "religious wars", and it is important to state the background for the recommendation.
In the guideline sections the terms must, should and can have special meaning. A must requirement must be followed, a should is a strong recommendation, and a can is a general guideline.
Many tools provide automatic code style checking and automated code formatting. Checkstyle by Oliver Burn is probably one of the most popular of such tools. An Eclipse integration for Checkstyle can be found here .
To use Checkstyle with Code Recommenders guidelines please use this xml configuration file: &TODO& 
At Eclipse every java source code file (at least) needs an EPL license header BEFORE it is checked in. The typical license header looks like this:
* Copyright (c) 2015 Codetrails GmbH.
* All rights reserved. This program and the accompanying materials
* are made available under the terms of the Eclipse Public License v1.0
* which accompanies this distribution, and is available at
* http://www.eclipse.org/legal/epl-v10.html
* Contributors:
Marcel Bruch - initial API and implementation.
package org.eclipse.recommenders.internal.rcp.
import ...
public class CompilerAstCompletionNodeFinder extends ASTVisitor {
Adopt the copyright header and Contributors section according to your affiliation and name. When using a new license header, add a file with the license header’s text to the licenses/resources/ folder, then update the root project’s pom.xml file to include the license file by adding it as a &validHeader& in build & pluginManagement & plugin & plugin com.mycila.maven-license-plugin & executions & execution check-license-header & configuration & validHeaders.
Files should always end with a line break. .java files without a line break at the end will cause the build to fail.
The main goal of the recommendation is to improve readability and thereby the understanding and the maintainability and general quality of the code. It is impossible to cover all the specific cases in a general guide and the programmer should be flexible.
/Users/Marcel/Workspaces/code-recommenders/public/org.eclipse.recommenders.parent
$ mvn clean install
... wait a few minutes and check the build results
The one who breaks the build... you already know what happens, right?
There are several kinds of projects:
Plug-in projects
Feature (source) projects
Test plug-in or fragment projects
Test fixture projects
Repository projects
Product projects
Releng projects (including target platform definitions etc.)
Finding appropriate names for projects is challenging. Eclipse defines many package naming conventions but only few project naming conventions. The guiding principle to name a plug-in is to name the project after its main package (yes, there should only be one, and yes, this one should be unique to all plug-ins). This section gives some additional naming conventions for Code Recommenders project. Note, that Code Recommenders have RCP as well as server plug-ins which makes the naming convention a bit harder.
Plug-in names follow the standard Eclipse Naming conventions. That means that (i) the project name on disk is the same as the plug-in id and (ii) plug-ins are named after their primary package. We recommend to flag plug-ins with a platform flag. Plug-ins that are considered to run on a server platform should be flagged with server, plug-ins considered to run inside Eclipse RCP with rcp, and plug-ins that can run on any platform without any platform flag.
The general naming schema for plug-ins is as follows:
plug-in id:
org.eclipse.recommenders.&component&[&&|.rcp|.server][.*]
source plug-in id:
org.eclipse.recommenders.&component&[&&|.rcp|.server][.*].source
platform flag:
[&&|.rcp|.server]
org.eclipse.recommenders.utils
org.eclipse.recommenders.utils.gson
org.eclipse.recommenders.utils.rcp
org.eclipse.recommenders.utils.web (put the webclient in here?)
org.eclipse.recommenders.injection
org.eclipse.recommenders.jayes
org.eclipse.recommenders.bayesnet ???
&rcp core plugins - no component since these plug-ins offer central services&:
org.eclipse.recommenders.rcp 
org.eclipse.recommenders.rcp.builder
org.eclipse.recommenders.rcp.store
org.eclipse.pletion
org.eclipse.recommenders.overrides.rcp
org.eclipse.recommenders.chain.rcp
org.eclipse.recommenders.subwords.rcp
org.eclipse.recommenders.analysis
org.eclipse.recommenders.analysis.rcp
org.eclipse.recommenders.codesearch (&-- implicit commons)
org.eclipse.recommenders.codesearch.rcp
org.eclipse.recommenders.codesearch.server
org.eclipse.recommenders.snipmatch (&-- implicit commons)
org.eclipse.recommenders.snipmatch.rcp
org.eclipse.recommenders.snipmatch.server
org.eclipse.recommenders.stacktrace (&-- implicit commons)
org.eclipse.recommenders.stacktrace.rcp
org.eclipse.recommenders.stacktrace.server
org.eclipse.recommenders.calls (&-- implicit commons)
org.eclipse.recommenders.calls.server ???
org.eclipse.recommenders.calls.rcp
Test projects are mostly fragments. They use the same naming conventions as plug-ins except that they use the tests flag right after the project name (i.e. org.eclipse.recommenders.tests). This practice is recommended by the Eclipse architecture council.
tests project id:
org.eclipse.recommenders.tests.&component&[.*]
source tests project id (pure virtual - used in source features at most):
org.eclipse.&subproject&.tests.&component&[.*].source
Usually, these names look like the plug-in name they contribute tests for but with the additional tests flag. Examples:
org.eclipse.recommenders.tests.calls.rcp
org.eclipse.recommenders.tests.rcp.builder
Test projects may offer common test infrastructure that may be reused between several test projects. These general purpose project may declare their own namespaces but should consider using the commons or shared namespace, e.g., org.eclipse.mons or org.eclipse.recommenders.tests.shared.
To line up the names according to the tests convention, we decided to use the feature flag and put it (similar to tests) directly behind the org.eclipse.recommenders prefix.
feature id:
org.eclipse.recommenders.feature.&component&[.*]
source feature id:
org.eclipse.recommenders.feature.&component&[.*].source
org.eclipse.recommenders.feature.calls.rcp
org.eclipse.recommenders.feature.calls.rcp.source
There may be additional feature packagings such as special packages for e4, rcp (==e3), server etc. The source flag is always the last segment in the feature id.
P2 repository projects should be prefixed with a repository flag.
p2 repository id:
org.eclipse.recommenders.repository.&distribution&.[variant]
org.eclipse.recommenders.repository{.all}
org.eclipse.recommenders.repository.rcp
org.eclipse.recommenders.repository.e4
org.eclipse.recommenders.repository.server
Products are currently used to build easy-to-install server distributions allowing developers to create an in-house knowledge base using code recommenders. More such packages may follow. Product projects should be prefixed with a product flag as follows.
product id:
org.eclipse.recommenders.product.&distribution&.[variant]
org.eclipse.recommenders.product.server
the distribution template should pickup the platform flag as specified for plug-ins and features.
Git repositories should be structured following this layout:
pom.xml (general settings such as versions, compiler settings etc.; group id=org.eclipse.recommenders)
pom.xml (specific build settings)
org.eclipse.recommenders.*
pom.xml (if needed)
org.eclipse.recommenders.feature.*
org.eclipse.recommenders.feature.*.source
pom.xml (specific test settings)
org.eclipse.recommenders.tests.*
org.eclipse.recommenders.fixture.*
repositories/
org.eclipse.recommenders.repository.*
org.eclipse.recommenders.build.*
org.eclipse.recommenders.product.*
Using flags such as feature, build, tests etc. seems redundant for project names given this disk layout. However, having all these projects in a single Eclipse workspace requires all projects to have a unique name. This is a bit redundant but I think an acceptable approach.
We considered using a per-component layout but this seems to be too much overhead given that our components consists of just a few plug-ins (sometimes just one project), and thus, are yet too small.
mypackage, pany.application.ui
Package naming convention used by Sun for the Java core packages. The initial package name representing the domain name must be in lower case.
At Eclipse there are a set of naming conventions described in great detail here: . This section summarizes them and add a few Code Recommenders specifc ones.
All packages start with:
org.eclipse.recommenders.*
Internal packages always start with
org.eclipse.recommenders.internal.* // NOT org.eclipse.recommenders.other.package.
// NOT org.eclipse.recommenders.other.internal.
Test packages start with
org.eclipse.recommenders.tests.* // NOT org.eclipse.recommenders.other.package.
// NOT org.eclipse.recommenders.other.tests.
Example packages start with
org.eclipse.recommenders.examples.* // NOT org.eclipse.recommenders.other.package.
// NOT org.eclipse.recommenders.other.examples.
General package naming recommendations
org.eclipse.recommenders.&component&[.*].wiring --& classes that contain glue code to configure and wire objects such as Google Guice modules, web service descriptors etc.
org.eclipse.recommenders.&component&[.*].net --& classes that contain mostly classes for network communication
org.eclipse.recommenders.tests.&component&[.*].interactive --& classes that contain interactive
(i.e., manual) test suites (Eclipse convention)
Line, AudioSystem
Common practice in the Java development community and also the type naming convention used by Sun for the Java core packages.
public interface IVariableUsageResolver // NOT just VariableUsageResolver
The I[TypeName] convention allows developers to quickly assess the relevant interfaces in a package. Like it or not - this is an Eclipse convention we have to obey.
line, audioSystem
Common practice in the Java development community and also the naming convention for variables used by Sun for the Java core packages. Makes variables easy to distinguish from types, and effectively resolves potential naming collision as in the declaration L
MAX_ITERATIONS, COLOR_RED
Common practice in the Java development community and also the naming convention used by Sun for the Java core packages.
TODO :Add section about enums
getName(), computeTotalWidth()
Common practice in the Java development community and also the naming convention used by Sun for the Java core packages. This is identical to variable names, but methods in Java are already distinguishable from variables by their specific form.
exportHtmlSource(); // NOT: exportHTMLSource();
openDvdPlayer(); // NOT: openDVDPlayer();
Using all uppercase for the base name will give conflicts with the naming conventions given above. A variable of this type whould have to be named dVD, hTML etc. which obviously is not very readable. Another problem is illustrated i When the name is connected to another, the readability
The word following the acronym does not stand out as it should.
liste der Standard abkürzungen:
ast -& jdt.deom rec -& recommenders jdt -& IJavaElement compiler -& compiler internal
cu -& compilationUnit -& preferred compilationUnit (no abbrev)
class Person
private S // NOT private String _
// NOT private String fN
// NOT private String name_;
void setName(String name)
this.name = // NOT name_=
To eliminate misinterpretations qualify field puts with this. and use the same names. Use IDE highlighting settings to make more visible on which kind of variable you are working.
void setTopic(Topic topic) // NOT: void setTopic(Topic value)
// NOT: void setTopic(Topic aTopic)
// NOT: void setTopic(Topic t)
void connect(Database database) // NOT: void connect(Database db)
// NOT: void connect(Database oracleDB)
Reduce complexity by reducing the number of terms and names used. Also makes it easy to deduce the type given a variable name only. If for some reason this convention doesn't seem to fit it is a strong indication that the type name is badly chosen.
Non-generic variables have a role. These variables can often be named by combining role and type:
Point startingPoint, centerP
Name loginN
English is the preferred language for international development.
Scratch variables used for temporary storage or indices are best kept short. A programmer reading such variables should be able to assume that its value is not used outside a few lines of code. Common scratch variables for integers are i, j, k, m, n and for characters c and d.
line.getLength(); // NOT: line.getLineLength();
The latter might seem natural in the class declaration, but proves superfluous in use, as shown in the example.
employee.getName();
employee.setName(name);
matrix.getElement(2, 4);
matrix.setElement(2, 4, value);
Common practice in the Java community and the convention used by Sun for the Java core packages. Getters should not change the internal state of the object. Exceptions may be lazy initializers. Getter should actually return something :-)
NOTE: this is a pure GET. No real computation effort needed.
isSet, isVisible, isFinished, isFound, isOpen
This is the naming convention for boolean methods and variables used by Sun for the Java core packages. Using the is prefix solves a common problem of choosing bad boolean names like status or flag. isStatus or isFlag simply doesn't fit, and the programmer is forced to chose more meaningful names.
Setter methods for boolean variables must have set prefix as in:
void setFound(boolean isFound);
There are a few alternatives to the is prefix that fits better in some situations. These are has, can and should prefixes:
boolean hasLicense();
boolean canEvaluate();
boolean shouldAbort =
<puteAverage();
puteInverse()
Give the reader the immediate clue that this is a potential time consuming operation, and if used repeatedly, he might consider caching the result. Consistent use of the term enhances readability.
vertex.findNearestVertex();
matrix.findSmallestElement();
node.findShortestPath(Node destinationNode);
Give the reader the immediate clue that this is a simple look up method with a minimum of computations involved. Consistent use of the term enhances readability.
printer.initializeFontSet();
The American initialize should be preferred over the English initialise. Abbreviation init should be avoided.
The use of initializeXYZ() in constructors to initialize complex fields is preferred over direct field initalizations.
Set&Statements& supportedCompletionR
// NOT Set&Statements& supportedCompletionNodes = createSupportedCompletionRequest()
public CallsCompletionEngine(..) {
initializeSuportedCompletionRequests();
private void initializeSuportedCompletionRequests()
supportedCompletionRequests = Sets.newHashSet();
supportedCompletionRequests.add(CompletionOnMemberAccess.class);
supportedCompletionRequests.add(CompletionOnMessageSend.class);
supportedCompletionRequests.add(CompletionOnQualifiedNameReference.class);
supportedCompletionRequests.add(CompletionOnSingleNameReference.class);
widthScale, nameTextField, leftScrollbar, mainPanel, fileToggle, minLabel, printerDialog
Enhances readability since the name gives the user an immediate clue of the type of the variable and thereby the available resources of the object.
Collection&Point&
Enhances readability since the name gives the user an immediate clue of the type of the variable and the operations that can be performed on its elements.
numberOfPoints, numberOfLines
Note that Sun use num prefix in the core Java packages for such variables. This is probably meant as an abbreviation of number of, but as it looks more like number it makes the variable name strange and misleading. If "number of" is the preferred phrase, numberOf prefix can be used instead of just n. num prefix must not be used.
for (Iterator it = points.iterator(); it.hasNext(); )
for (int i = 0; i & numberOfT i++)
get/set, add/remove, create/destroy, start/stop, insert/delete,
increment/decrement, old/new, begin/end, first/last, up/down, min/max,
next/previous, old/new, open/close, show/hide, suspend/resume, etc.
Reduce complexity by symmetry.
computeAverage(); // NOT: compAvg();
ActionE // NOT: ActionE
catch (Exception exception) { // NOT: catch (Exception e) {
There are two types of words to consider. First are the common words listed in a language dictionary. These must never be abbreviated. Never write:
cmd instead of command comp instead of compute cp instead of copy e instead of exception init instead of initialize pt instead of point etc.
Then there are domain specific phrases that are more naturally known through their acronym or abbreviations. These phrases should be kept abbreviated. Never write:
HypertextMarkupLanguage instead of html CentralProcessingUnit instead of cpu PriceEarningRatio instead of pe etc.
TODO: cu, exception changed
bool isE // NOT: isNoError
bool isF // NOT: isNotFound
The problem arise when the logical not operator is used and double negative arises. It is not immediately apparent what !isNotError means.
final int COLOR_RED = 1;
final int COLOR_GREEN = 2;
final int COLOR_BLUE = 3;
This indicates that the constants belong together, and what concept the constants represents.
An alternative to this approach is to put the constants inside an interface effectively prefixing their names with the name of the interface:
interface Color
final int RED = 1;
final int GREEN = 2;
final int BLUE = 3;
class AccessException extends Exception{...}
Exception classes are really not part of the main design of the program, and naming them like this makes them stand out relative to the other classes. This standard is followed by Sun in the basic Java library.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
=== Item 11: Override clone judiciously
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
The package statement location is enforced by the Java language. Letting all files belong to an actual (rather than the Java default) package enforces Java language object oriented programming techniques.
=== The import statements must follow the package statement. import statements should be sorted with the most fundamental packages first, and grouped with associated packages together and one blank line between groups.
import java.io.IOE
import java.net.URL;
import java.rmi.RmiS
import java.rmi.server.S
import javax.swing.JP
import javax.swing.event.ActionE
import org.linux.apache.server.SoapS
The import statement location is enforced by the Java language. The sorting makes it simple to browse the list when there are many imports, and it makes it easy to determine the dependiencies of the present package The grouping reduce complexity by collapsing related information into a common unit.
Your IDE supports you on this. Check out your settings.
import java.util.L
// NOT: import java.util.*;
import java.util.ArrayL
import java.util.HashS
Importing classes explicitly gives an excellent documentation value for the class at hand and makes the class easier to comprehend and maintain.
Your IDE will always keep the import list minimal and up to date - if you enable this feature in your preferences.
Class/Interface documentation.
class or interface statement.
Class (static) variables in the order public, protected, package (no access modifier), private.
Instance variables in the order public, protected, package (no access modifier), private.
Constructors.
Methods (in order they are used in code AKA vertical density).
Reduce complexity by making the location of each class element predictable.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
see "Effective Java" for details.
The first rule of methods is that they should be small. The second rule of methods is that 'they should be smaller than that!
This brings up another question: 20 lines isn't too large, right? Here at code recommenders we would say "No, a method with 20 lines is too large." Methods typically can be broke down to smaller chunks containing of 2,3, or 4 methods each. Sounds strange but the large a method the higher the probability that your method does many different things and thus would violate the next guideline. Thus, if you have a method that is larger than 5 lines carefully look on your code and be sure that this piece of work cannot be divided further into smaller pieces.
From Clean Code:
Methods should do one thing. And they should do it well. They should do 'only this one thing.
TODO: provide a code snippet
public IJavaElement getEnclosing(){
return hasElement? elem:
// better:
public Optional&IJavaElement& getEnclosing(){
return Optional.fromNullable(elem);
// or: Optional.absent()
Developers tend to assume that methods never return null. This is the source of most NullPointerExceptions. Thus, if a method may return null consider using Optional&T& classes as provided by Google Guava 10.0. Code Recommenders currently has it's own class for this (org.eclipse.recommenders.utils.Option) but this will be replaced soon. This guideline applies for public and protected methods that may be called from external clients. Dealing with null values internally is up to the developer. It's not enforced to apply this guideline to private methods too - it may or may not make sense depending on your case.
If there are methods such as hasX(), you may consider to throw an exception if getX() would return null. Not sure yet, which approach is more favorable. We are currently one-by-one changing our APIs to use optional classes.
&annotations& &access& abstract static final synchronized native strictfp
Following any &annotations& (like @Overide or @Nullable), which are not real modifiers, the &access& modifier (if present, one of public, protected or private) must be the first modifier.
public static double square(double a);
// NOT: static public double square(double a);
The most important lesson here is to keep the access modifier as the first modifier.
Of the possible modifiers, this is by far the most important, and it must stand out in the method declaration.
For the other modifiers, the order is less important.
Nevertheless, the suggestions of the
on modifier order should be followed.
see Effective Java for details.
see Effective Java for details.
see Effective Java for details.
see Effective Java for details.
see Effective Java for details.
see Effective Java for details.
see Effective Java for details.
floatValue = (int) intV // NOT: floatValue = intV
By this, the programmer indicates that he is aware of the different types involved and that the mix is intentional.
int[] a = new int[20];
// NOT: int a[] = new int[20]
The arrayness is a feature of the base type, not the variable. It is not known why Sun allows both forms.
void m(Boolean b){ // NOT:
if(!b.booleanValue())
void m(boolean b){ // BETTER:
You should use primitive types instead of their wrapping types whenever possible. When using the wrapping type, we assume that null is a valid and possible value that must be handled. Favor wrapper types if conversion between primitive and object type (int vs. Integer) would otherwise occur very frequently.
This ensures that variables are valid at any time. Sometimes it is impossible to initialize a variable to a valid value where it is declared. In these cases it should be left uninitialized rather than initialized to some phony value.
m(){ // NOT
List&C& res = Collections.emptyList();
if(someExpression){
res = new ArrayList();
.... // 10 lines more
if(someExpression){
List&C& res = new ArrayList();
.... // 10 lines more
return Collections.emptyList();
Enhances readability by ensuring all concepts are represented uniquely. Reduce chance of error by side effects.
The concept of Java information hiding and encapsulation is violated by public variables. Use private variables and access functions instead. One exception to this rule is when the class is essentially a data structure, with no behavior (equivalent to a C++ struct). In this case it is appropriate to make the class' instance variables public [2].
// NOT: double vertex[];
// NOT: int
public static void main(String[] arguments)
public double[] computeVertex()
The reason for is twofold. First, the array-ness is a feature of the class, not the variable. Second, when returning an array from a method, it is not possible to have the brackets with other than the type (as shown in the last example).
Keeping the operations on a variable within a small scope, it is easier to control the effects and side effects of the variable.
// NOT: for (i = 0, sum = 0; i & 100; i++)
for (i = 0; i & 100; i++)
sum += value[i];
sum += value[i];
Increase maintainability and readability. Make a clear distinction of what controls and what is contained in the loop.
// NOT: bool isDone =
while (!isDone) {
while (!isDone) {
do-while loops are less readable than ordinary while loops and for loops since the conditional is at the bottom of the loop. The reader must scan the entire loop in order to understand the scope of the loop.
In addition, do-while loops are not needed. Any do-while loop can easily be rewritten into a while loop or a for loop. Reducing the number of constructs used enhance readability.
These statements should only be used if they prove to give higher readability than their structured counterparts.
bool isFinished = (elementNo & 0) || (elementNo & maxElement);
bool isRepeatedEntry = elementNo == lastE
if (isFinished || isRepeatedEntry) {
if ((elementNo & 0) || (elementNo & maxElement)||
elementNo == lastElement) {
// even better:
if (isFinished(..) || isRepeatedEntry(..)) {
By assigning boolean variables to expressions, the program gets automatic documentation. The construction will be easier to read, debug and maintain. Using methods that reveal the intension of these checks should be preferred over use of temporary variables!
boolean isOk = readFile(fileName);
if (isOk) {
Makes sure that the exceptions does not obscure the normal path of execution. This is important for both the readability and performance.
if (isDone)
// NOT: if (isDone) doCleanup();
doCleanup();
This is for debugging purposes. When writing on a single line, it is not apparent whether the test is really true or not. Also the usage of curly brackets ensure that no statements accidentally fall out of an if branch:
if (isDone)
doCleanup();
unregisterListener(); // unregister will always be called - even if&#160;!isDone
InputStream stream = File.open(fileName, &w&);
if (stream&#160;!= null) {
if (File.open(fileName, &w&)&#160;!= null)) {
Conditionals with executable statements are simply very difficult to read. This is especially true for programmers new to Java.
private static final int
TEAM_SIZE = 11;
Player[] players = new Player[TEAM_SIZE]; // NOT: Player[] players = new Player[11];
If the number does not have an obvious meaning by itself, the readability is enhanced by introducing a named constant instead.
58. Floating point constants should always be written with decimal point and at least one decimal.
double total = 0.0;
double total = 0;
double speed = 3.0e8;
double speed = 3e8;
sum = (a + b) * 10.0;
This emphasize the different nature of integer and floating point numbers. Mathematically the two model completely different and non-compatible concepts.
Also, as in the last example above, it emphasize the type of the assigned variable (sum) at a point in the code where this might not be evident.
double total = 0.5;
double total = .5;
The number and expression system in Java is borrowed from mathematics and one should adhere to mathematical conventions for syntax wherever possible. Also, 0.5 is a lot more readable than .5; There is no way it can be mixed with the integer 5.
Thread.sleep(1000);
// NOT: thread.sleep(1000);
This emphasize that the element references is static and independent of any particular instance. For the same reason the class name should also be included when a variable or method is accessed from within the same class.
class DefaultTableCellRenderer implements TableCellRenderer {...}
It is not uncommon to create a simplistic class implementation of an interface providing default behaviour to the interface methods. The convention of prefixing these classes by Default has been adopted by Sun for the Java library.
class UnitManager
private final static UnitManager instance_ = new UnitManager();
private UnitManager() {...}
public static UnitManager getInstance() // NOT: get() or instance() or unitManager() etc.
return instance_;
Common practice in the Java community though not consistently followed by Sun in the JDK. The above layout is the preferred pattern.
class PointFactory
public Point newPoint(...)
Indicates that the instance is created by new inside the factory method and that the construct is a controlled replacement of new Point().
Advantages:
One advantage of static factory methods is that, unlike constructors, they have names.
A second advantage of static factory methods is that, unlike constructors, they are not required to create a new object each time they’re invoked.
A third advantage of static factory methods is that, unlike constructors, they can return an object of any subtype of their return type.
Disadvantages:
The main disadvantage of providing only static factory methods is that classes without public or protected constructors cannot be subclassed.
A second disadvantage of static factory methods is that they are not readily distinguishable from other static methods.
Follow a set of conventions when using them:
valueOf - Returns an instance that has, loosely speaking, the same value as its parameters. Such static factories are effectively type-conversion methods. Example: String.valueOf(boolean);
of - A concise alternative to valueOf, popularized by EnumSet.
getInstance - Returns an instance that is described by the parameters but cannot be said to have the same value. In the case of a singleton, getInstance takes no parameters and returns the sole instance.
newInstance - Like getInstance, except that newInstance guarantees that each instance returned is distinct from all others.
getType - Like getInstance, but used when the factory method is in a different class. Type indicates the type of object returned by the factory method.
newType - Like newInstance, but used when the factory method is in a different class. Type indicates the type of object returned by the factory method.
create[SomeSuffix] - Like newType, but may perform some special initializations on the returned objects. Example: Type.createWithDefaultResolver(...);
public void append(..)
doAppend(..);
catch (Exception e)
logAppendFailedError(e);
Sometimes the code to execute may throw exceptions which should be catched and not rethrown. Also subclasses may reimplement some behavior of the algorithm. To ensure consistency with the API one may delegate to a do[MethodName]() method and make the public method final. This way the superclass can ensure some consistency independent of actual subclasses executed.
Increase readability. Makes it clear what the unit should do and especially all the things it is not supposed to do. This again makes it easier to keep the code clean of side effects.
Code Recommenders provides a code formatter template for Eclipse which must be used by all committers. It's located in the releng project.
Most conventions on comments are enforced by the code formatter template of the code recommenders project. Thus just a few general notes on comments here.
In general, the use of comments should be minimized by making the code self-documenting by appropriate name choices and an explicit logical structure.
In an international environment English is the preferred language.
// Comment spanning
// more than one line.
Since multilevel Java commenting is not supported, using // comments ensure that it is always possible to comment out entire sections of a file using /* */ for debugging purposes etc.
private Multimap&String /* simple class name*/, String /* full qualified class names*/&
simple2fullyQualifiedC
Without the extra comment it can be hard to figure out what the collection consist of, and thereby how to treat the elements of the collection. In methods taking collection variables as input, the common type of the elements should be given in the associated JavaDoc comment.
Whenever possible one should of course qualify the collection with the type to make the comment superflous:
Abbreviation for Compilation Unit. Although accepted the usage of compilationUnit should be preferred over cu.
Abbreviation for Abstract Syntax Tree.
Abbreviation for Java Development Tools - also used if IJavaElements are used to make clear the difference to code recommenders or ast constructs with similar names.
Abbreviation for Recommenders. Typically used as prefix if objects of similar names are used in the same context. Example: jdtCu vs. recCu
Send comments to recommenders-dev@eclipse.org