Convenções de nomenclatura e directrizes para a plataforma Eclipse:
org.eclipse.ant[.*] - Suporte de AntOs seguintes segmentos de nome de pacote estão reservados:
org.eclipse.compare[.*] - Suporte de comparação
org.eclipse.core[.*] - Núcleo da plataforma
org.eclipse.debug[.*] - Depuração
org.eclipse.help[.*] - Suporte de ajuda
org.eclipse.jdi[.*] - Implementação da Interface de Depuração Java (JDI) para Eclipse
org.eclipse.jdt[.*] - Ferramentas de programação Java
org.eclipse.jface[.*] - JFace
org.eclipse.ltk[.*] - Infra-estrutura genérica de ferramentas de linguagem
org.eclipse.osgi[.*] - API do Eclipse para interacção com o OSGi
org.eclipse.pde[.*] - Ambiente de Programação de Plug-ins
org.eclipse.search[.*] - Suporte de pesquisa
org.eclipse.swt[.*] - Toolkit de Widget Standard (SWT)
org.eclipse.team[.*] - Suporte de equipa e Gestão de Versões e Configuração
org.eclipse.text[.*] - Enquadramento do editor de texto
org.eclipse.tomcat[.*] - Suporte de Apache tomcat
org.eclipse.ui[.*] - Ambiente de trabalho
org.eclipse.update[.*] - Actualização/instalação
org.eclipse.webdav[.*] - Suporte de WebDAV
internal - indica um pacote de implementação interna que não contém qualquer APIEstes nomes são utilizados como qualificadores e devem aparecer apenas a seguir ao nome de pacote principal. Por exemplo,
tests - indica um pacote que não seja da API que contém apenas conjuntos de testes
examples - indica um pacote que não seja da API que contém apenas exemplos
org.eclipse.core.internal.resources - utilização correcta
org.eclipse.internal.core.resources - incorrecta. internal precede o nome de pacote principal.
org.eclipse.core.resources.internal - incorrecto. internal não aparece imediatamente a seguir ao nome de pacote principal.
Deixando de lado o modo como a plataforma Eclipse está estruturada, esta divide-se em Núcleo e UI. Tudo o que seja classificado como Núcleo é independente do sistema de janelas; as aplicações e os plug-ins que dependem do Núcleo de não da UI pode ser executados sem responsável. A diferença entre Núcleo e UI não está alinhada com a distinção entre API e não API; tanto o Núcleo como a UI contém API. A porção de UI da plataforma do Eclipse é conhecida como área de trabalho. A área de trabalho é uma infra-estrutura de UI de nível elevado para construir produtos com construção de UI sofisticada a partir de componentes conectáveis. A área de trabalho é construída por cima de JFace, SWT e do núcleo da plataforma. O SWT (Toolkit de Widget Standard) é um meio de nível inferior e independente da plataforma do OS de comunicar com o sistema de janelas nativo. JFace é uma infra-estrutura de nível intermédio útil para construir componentes de UI complexo como visualizadores de propriedades. SWT e JFace são UI por definição. As ferramentas Java são um IDE Java construído sobre a área de trabalho. Final à parte.
Pacotes de API os pacotes de API são aqueles que contêm classes e interfaces que devem ser disponibilizadas para ISVs. Os nomes dos pacotes de API devem fazer sentido para ISV. O número de pacotes diferentes que ISV devem recordar deve ser pequeno, uma vez que um grande número de pacotes de API pode dificultar que o ISV saiba quais os pacotes que deverá importar. Dentro de um pacote de API, todas as classes e interfaces públicas são consideradas como API. Os nomes de pacotes de API não devem conter os elementos internal, tests ou examples para evitar a confusão entre o esquema para a nomenclatura de pacotes que não sejam de API.
Pacotes de Implementação Interna todos os pacotes que fazem parte da implementação da plataforma, mas que não contêm qualquer API, devem ser expostos aos ISV que sejam considerados pacotes de implementação interna. Todos os pacotes de implementação devem ser sinalizados com o código internal, aparecendo o código após o nome do pacote principal. A todos os ISVs dir-se-á que todos os pacotes marcados com o código internal estão fora dos limites. (Uma pesquisa de texto simples para .internal." detecta referências suspeitas nos ficheiros de origem; do mesmo modo a ocorrência do elemento internal/" é suspeita em ficheiros .class).
Pacotes de Conjunto de Testes todos os pacotes que contêm conjuntos de testes devem ser sinalizados com o código tests, aparecendo o código após o nome do pacote principal. A norma são os testes totalmente automatizados; assim, por exemplo, org.eclipse.core.tests.resources iria conter testes automatizados para a API em org.eclipse.core.resources. Os testes interactivos (aqueles que requerem a intervenção de uma pessoa) devem ser sinalizados com o código interactive como o último segmento de nome de pacote; assim, por exemplo, org.eclipse.core.tests.resources.interactive iria conter os testes interactivos correspondentes.
Pacotes de Exemplo todos os pacotes que contêm exemplos que são enviados para ISVs devem ser sinalizados com o código examples, aparecendo o código após o nome do pacote principal. Por exemplo, org.eclipse.swt.examples iria conter exemplos sobre como utilizar a API de SWT.
Regras adicionais:
Directrizes de nomenclatura de Sun
Os nomes de classes devem ser nomes, com maiúsculas e minúsculas, sendo a primeira letra de cada palavra interna em maiúsculas. Tente que os nomes de classes sejam simples e descritivos. Utilizar palavras completas - evite os acrónimos e abreviaturas (a não ser que a abreviatura seja mais utilizada do que a forma longa, como URL ou HTML).
Exemplos:
class Raster;
class ImageSprite;
Os nomes de interfaces devem aparecer em maiúsculas como os nomes de classes.
Para os nomes de interfaces, segue-se a convenção de "I" para interface: todos os nomes das interfaces têm como prefixo um I". Por exemplo, IWorkspace" ou "IIndex". Esta convenção ajuda a fácil leitura do código ao tornar os nomes de interfaces mais reconhecíveis durante a leitura. (As interfaces COM da Microsoft subscrevem esta convenção.)
Regras adicionais:
Directrizes de nomenclatura de Sun
Os métodos devem ser verbos, em maiúsculas e minúsculas, sendo a primeira letra uma minúscula e a primeira letra de cada palavra interna deve ser maiúscula.Regras adicionais:
Exemplos:
run();
runFast();
getBackground();
Directrizes de nomenclatura de Sun
Excepto para as variáveis, todas as instâncias, classes e constantes de classes aparecem em maiúsculas e minúsculas, sendo a primeira letra uma minúscula. As palavras internas começam com maiúsculas. Os nomes de variáveis não devem começar por traço de sublinhado _ ou pelo símbolo do dólar $ , ainda que sejam permitidos.
Os nomes das variáveis devem ser pequenos, mas devem ter algum significado. A escolha de um nome de variável deve ser mnemónica, ou seja, destina-se a indicar ao observador normal o objectivo da utilização. Deve evitar-se os nomes de variáveis de um carácter, excepto para variáveis temporárias "desperdiçadas". Os nomes comuns para variáveis temporárias são i, j, k, m e n para números inteiros; e c, d e e para caracteres.
Exemplos:
int i;
char c;
float myWidth;
(Nota: já não se segue a convenção seguinte que coloca prefixo em nomes de campo de não constantes com f", como "fWidget".)
Directrizes de nomenclatura de Sun
Os nomes de constantes de classes declaradas de variáveis e de constantes de ANSI devem estar em maiúsculas, com as palavras separadas por traços de sublinhado ("_").
Exemplos:
static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;
Todos os plug-ins, incluindo aqueles que fazem parte da plataforma Eclipse, como os plug-ins de Recursos e Ambiente de Trabalho, devem ter identificadores únicos que sigam o mesmo padrão de nomenclatura dos pacotes Java. Por exemplo, os plug-ins de ambiente de trabalho são designados como org.eclipse.ui[.*].
O espaço de nome do plug-in é gerido hierarquicamente; não criar o plug-in sem a aprovação prévia do proprietário do espaço de nome delimitador.
Os pontos de extensão que esperam extensões múltiplas devem ter vários nomes. Por exemplo, builders" em vez de "builder".