Plataforma Eclipse
Convenção de Nomenclatura

Última revisão: 4 de junho de 2001 - versão 1.0 para org.eclipse

Convenções de nomenclatura e diretrizes da Plataforma Eclipse:

Pacotes Java

A Plataforma Eclipse consiste em uma coleção de pacotes Java. O namespace do pacote é gerenciado de acordo com as Diretrizes de nomenclatura do pacote Sun; não devem ser criados subpacotes sem a aprovação prévia do proprietário da subárvore do pacote. Os pacotes da Plataforma Eclipse estão todos em subpacotes org.eclipse. O primeiro componente de nome de pacote depois de org.eclipse é chamado de nome de pacote principal. Os pacotes principais seguintes do org.eclipse são atribuídos no release inicial:
org.eclipse.ant[.*] - Ant support (Suporte Ant)
org.eclipse.compare[.*] - Compare support (Suporte de comparação)
org.eclipse.core[.*] - Platform core (Núcleo da plataforma)
org.eclipse.debug[.*] - Debug (Depuração)
org.eclipse.help[.*] - Help support (Suporte da Ajuda)
org.eclipse.jdi[.*] - Eclipse implementation of Java Debug Interface (JDI) (Implementação da Interface de Depuração Java (JDI) no Eclipse)
org.eclipse.jdt[.*] - Java Development Tooling (Ferramentas de Desenvolvimento Java)
org.eclipse.jface[.*] - JFace
org.eclipse.pde[.*] - Plug-in Development Environment (Ambiente de Desenvolvimento de Plug-in)
org.eclipse.scripting[.*] - Scripting support (Suporte de scripting)
org.eclipse.search[.*] - Search support (Suporte de pesquisa)
org.eclipse.swt[.*] - Toolkit de Widget Padrão
org.eclipse.ui[.*] - Workbench
org.eclipse.update[.*] - Plug-in live update (Atualização ativa de Plug-in)
org.eclipse.vcm[.*] - Version and Configuration Management (Gerenciamento de Versão e Configuração)
org.eclipse.webdav[.*] - WebDAV support (Suporte do WebDAV)
Os seguintes segmentos de nome de pacote estão reservados:
internal - indica um pacote de implementação interno que não contém API
tests - indica um pacote não-API que contém somente conjuntos de testes
examples - indica um pacote não-API que contém somente exemplos
Esses nomes são usados como qualificadores e só devem aparecer após o nome do pacote principal. Por exemplo:
org.eclipse.core.internal.resources - Uso correto
org.eclipse.internal.core.resources - Incorreto. internal precede o nome principal do pacote .
org.eclipse.core.resources.internal - Incorreto. internal não segue imediatamente o nome principal do pacote.
Independentemente da estruturação da Plataforma Eclipse, a Plataforma Eclipse é dividida em Núcleo e UI. Tudo o que for classificado como Núcleo é independente do sistema de janelas; aplicativos e plug-ins que dependem do Núcleo e não da UI podem ser executados sem dependências. A distinção entre Núcleo e UI não se assemelha à distinção entre API e não-API; ambos, Núcleo e UI, contêm API. A parte de UI da Plataforma Eclipse é conhecida como Workbench. O Workbench é uma estrutura da UI de nível superior para produtos de construção com UIs sofisticadas construídas com componentes conectáveis. O Workbench é construído sobre o JFace, SWT e o Núcleo da Plataforma. SWT (Standard Widget Toolkit) é um meio em nível inferior, um meio de comunicação independente da plataforma do sistema operacional com o sistema nativo de janelas. O JFace é uma estrutura da UI de nível médio útil para criar partes da UI complexas, como visualizadores de propriedades. SWT e JFace são UI por definição. A ferramenta Java é um IDE Java construído sobre o workbench. Fim parcial.

Pacotes API  Os pacotes API são aqueles que contêm classes e interfaces que devem estar disponíveis para ISVs. É necessário que os nomes dos pacotes API façam sentido para o ISV. O número de pacotes diferentes que o ISV precisa lembrar deve ser pequeno, uma vez que uma profusão de pacotes API pode tornar difícil para os ISVs saberem quais pacotes precisam importar. Dentro de um pacote API, todas as classes públicas e interfaces são consideradas API. Os nomes dos pacotes API não devem conter internal, tests, ou examples para evitar confusão com os esquemas de nomenclatura de pacotes não-API.

Pacotes de Implementação Interna  Todos os pacotes que fazem parte da implementação da plataforma, mas não contém API a ser exposta aos ISVs, são considerados pacotes de implementação interna. Todos os pacotes de implementação devem ser sinalizados como internal, com a marcação ocorrendo exatamente depois do nome principal do pacote. ISVs será informado que todos os pacotes marcados como internal estão fora dos limites. (Uma pesquisa de texto simples de ".internal." detecta referências suspeitas nos arquivos fonte; do mesmo modo, "/internal/" é suspeito em arquivos .class).

Pacotes de Conjuntos de Teste  Todos os pacotes que contêm conjuntos de teste devem ser sinalizados como tests, com a marcação ocorrendo exatamente depois do nome principal do pacote. Os testes completamente automatizados são a regra; então, por exemplo, org.eclipse.core.tests.resources deve conter testes automatizados para API em org.eclipse.core.resources. Testes interativos (que exigem um testador prático) devem ser marcados com interactive como o último segmento do nome do pacote; assim, por exemplo, org.eclipse.core.tests.resources.interactive deveria conter os testes interativos correspondentes.

Pacotes de Exemplos  Todos os pacotes contendo exemplos que são enviados para ISVs devem ser definidos como examples, com a marcação ocorrendo exatamente depois do nome principal do pacote. Por exemplo, org.eclipse.swt.examples deveria conter exemplos do modo de usar a API do SWT.

Regras adicionais:

Classes e Interfaces

As diretrizes de nomenclatura da Sun determminam
Os nomes das classes devem ser substantivos, utilizando maiúsculas e minúsculas, com a primeira letra de cada palavra interna em maiúscula. Tente manter os nomes das classes simples e descritivos. Use palavra completas - evite acrônimos e abreviações (exceto se a abreviação for mais usada do que o termo por extenso, como URL ou HTML).

Exemplos:
    classe Raster;
    classe ImageSprite;

Os nomes de interface devem ser escritos com letra maiúscula como os nomes das classes.

Para os nomes de interface, seguimos a convenção "I" para interface: todos os nomes de interface contêm o prefixo "I". Por exemplo, "IWorkspace" ou "IIndex". Essa convenção ajuda a leitura dos códigos tornando os nomes de interface mais facilmente reconhecidos. (As interfaces Microsoft COM fazem uso dessa convenção).

Regras adicionais:

Métodos

As diretrizes de nomenclatura da Sun determinam
Os métodos devem ser verbos, utilizando maiúsculas e minúsculas, com a primeira letra minúscula, com a primeira letra de cada palavra interna em maiúscula.

Exemplos:
    executar();
    runFast();
    getBackground();

Regras Adicionais:

Variáveis

As diretrizes de nomenclatura da Sun determinam
Exceto para variáveis, todas as ocorrências, classes e constantes de classe utilizam maiúsculas e minúsculas, com a primeira letra em minúscula. Palavras internas começam com letras maiúsculas. Os nomes de variáveis não devem começar com sublinhado _ ou símbolo de moedas $ , embora ambos sejam permitidos.

Os nomes de variáveis devem ser pequenos mas com sentido. A escolha do nome da variável deve ser mnemônica - ou seja, projetada para indicar a um observador ocasional o objetivo do seu uso. Os nomes de variáveis com um caracter devem ser evitados, exceto para variáveis temporárias "descartáveis". Nomes comuns para variáveis temporárias são i, j, k, m ; n para números inteiros; c, d e e para caracteres.

Exemplos:
    int i;
    char c;
    float myWidth;

(Nota: não estamos mais seguindo a convenção que prefixa os nomes de campos não constantes com "f", como "fWidget".)

Constantes

As diretrizes de nomenclatura da Sun determinam
Os nomes de constantes de classes declaradas variáveis e de constantes ANSI devem ser todos em letras maiúsculas, com as palavras separadas por underscores ("_").

Exemplos:
    static final int MIN_WIDTH = 4;
    static final int MAX_WIDTH = 999;
    static final int GET_THE_CPU = 1;

Plug-ins e Pontos de Extensão

Todos os plug-ins, inclusive os que fazem parte da Plataforma Eclipse, como os plug-ins Recursos e Ambientes de Trabalho, devem ter identificadores exclusivos seguindo o mesmo padrão de nomenclatura dos pacotes Java. Por exemplo, os plug-ins do workbench são chamados org.eclipse.ui[.*].

O namespace plug-in é gerenciado hierarquicamente; não crie um plug-in sem a aprovação prévia do proprietário do namespace envolvido.

Pontos de extensão que esperam extensões múltiplas devem ter nomes no plural. Por exemplo, "builders" em vez de "builder".