Naming Conventions

The Eclipse Platform consists of a collection of Java packages. The package namespaceis managed in conformance with Suns package naming guidelines; subpackages shouldnot be created without prior approval from the owner of the package subtree. Thepackages for the open-source Eclipse project are all subpackages org.eclipse.The first package name segment after org.eclipse is generally the subproject name,followed by the component name.
Nội dung trích xuất từ tài liệu:
Naming Conventions Naming Conventions From Eclipsepedia Contents • 1 General o 1.1 Eclipse Workspace Projects o 1.2 Java Packages o 1.3 API Packages o 1.4 Internal Implementation Packages o 1.5 Test Suite Packages o 1.6 Examples Packages o 1.7 Additional rules • 2 Classes and Interfaces • 3 Methods • 4 Variables • 5 Constants • 6 Plug-ins and Extension Points • 7 System Files and SettingsGeneralLike other open source projects, the code base for the Eclipse project should avoid usingnames that reference a particular company or their commercial products.Eclipse Workspace ProjectsWhen Eclipse is being used to develop plug-ins for the Eclipse project, the name of theEclipse workspace project should match the name of the plug-in. For example,org.eclipse.core.runtime plug-in is developed in an Eclipse workspace project namedorg.eclipse.core.runtime.Java PackagesThe Eclipse Platform consists of a collection of Java packages. The package namespaceis managed in conformance with Suns package naming guidelines; subpackages shouldnot be created without prior approval from the owner of the package subtree. Thepackages for the open-source Eclipse project are all subpackages org.eclipse.The first package name segment after org.eclipse is generally the subproject name,followed by the component name. org.eclipse..[.*]- General form of packagenamesThe following subprojects are assigned at the time of writing: org.eclipse.jdt.[.*] - Java development tooling org.eclipse.pde.[.*] - Plug-in development environmentThe following package name segments are reserved: internal - indicates an internal implementation package thatcontains no API tests - indicates a non-API package that contains only test suites examples - indicates a non-API package that contains only examplesThese name are used as qualifiers and appear between the subproject and componentname: org.eclipse..internal.[.*] - internal package org.eclipse..tests.[.*] - tests org.eclipse..examples.[.*] - examplesIn the case of the Eclipse Platform proper, there is no subproject name, and the qualifiersappear immediately after the component name: org.eclipse.[.*] - Eclipse Platform proper org.eclipse..internal[.*] - Eclipse Platform internalpackage org.eclipse..tests[.*] - Eclipse Platform tests org.eclipse..examples[.*] - Eclipse Platform examplesThe following components of the Eclipse Platform proper are assigned at the time ofwriting: org.eclipse.ant[.*] - Ant support org.eclipse.compare[.*] - Compare support org.eclipse.core[.*] - Platform core org.eclipse.debug[.*] - Debug org.eclipse.help[.*] - Help support org.eclipse.jdi[.*] - Eclipse implementation of Java Debug Interface(JDI) org.eclipse.jface[.*] - JFace org.eclipse.platform[.*] - Documentation org.eclipse.scripting[.*] - Scripting support org.eclipse.sdk[.*] - SDK configuration org.eclipse.search[.*] - Search support org.eclipse.swt[.*] - Standard Widget Toolkit org.eclipse.ui[.*] - Workbench org.eclipse.update[.*] - Plug-in live update org.eclipse.vcm[.*] - Version and Configuration Management org.eclipse.webdav[.*] - WebDAV supportFor example, org.eclipse.jdt.internal.core.compiler - Correct usage org.eclipse.jdt.core.internal.compiler - Incorrect. internal shouldimmediately follow subproject name. org.eclipse.core.internal.resources - Correct usage org.eclipse.internal.core.resources - Incorrect. internal shouldnever immediately follow org.eclipse. org.eclipse.core.resources.internal - Incorrect. internal shouldimmediately follow Eclipse Platform component name.API PackagesAPI packages are ones that contain classes and interfaces that must be made available toISVs. The names of API packages need to make sense to the ISV. The number ofdifferent packages that the ISV needs to remember should be small, since a profusion ofAPI packages can make it difficult for ISVs to know which packages they need to import.Within an API package, all public classes and interfaces are considered API. The namesof API packages should not contain internal, tests, or examples to avoid confusion withthe scheme for naming non-API packages.Internal Implementation PackagesAll packages that are part of the platform implementation but contain no API that shouldbe exposed to ISVs are considered internal implementation packages. All implementationpackages should be flagged as internal, with the tag occurring just after the majorpackage name. ISVs will be told that all packages marked internal are out of bounds. (Asimple text search for .internal. detects suspicious reference in source files; likewise,/internal/ is suspicious in .class files).Test Suite PackagesAll packages containing test suites should be flagged as tests, with the tag occurring justafter the major package name. Fully automated tests are the norm; so, for example,org.eclipse.core.tests.resources would contain automated tests for API inorg.eclipse.core.resources. Interactive tests (ones requiring a hands-on tester) should beflagged with interactive as the last package name segment; so, for example,org.eclipse.core.tests.resources.interactive would contain the corresponding interactivetests.Examples PackagesAll packages containing examples that ship to ISVs should be flagged as examples, withthe tag occurring just after the major package name. For example,org.eclipse.swt.examples would contain examples for how to use the SWT API.Additional rules • Package names should contain only lowercase ASCII alphanumerics, and avoid underscore _ or dollar sign $ characters.Classes and InterfacesSuns naming guidelines states Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to ...