Java – Convenções de Nomenclatura

Neste tutorial irei mostrar como a linguagem de programação Java utiliza as convenções de nomenclatura de codificação.
A padronização de código é conveniente devido a vários aspectos. Um deles é a manutenção do software desenvolvido, que pode ser feita por diversas pessoas diferentes, e que codificam de forma diferente. A padronização ajuda a deixar o código mais legível, facilitando assim o entendimento do mesmo por parte dos desenvolvedores que farão manutenção no código-fonte.
A convenção de nomenclatura em Java é uma regra a seguir quando se decide nomear seus identificadores, como classes, pacotes, variáveis, constantes, métodos, etc.
Mas, não se é forçado a seguir. Portanto, é conhecido como convenção, não regra. Essas convenções são sugeridas por várias comunidades Java, como Oracle e Eclipse.
Todas as classes, interfaces, pacotes, métodos e campos da linguagem de programação Java são fornecidas de acordo com a convenção de nomenclatura Java. Se você não seguir essas convenções, isso poderá gerar confusão ou código incorreto. Por isso, é uma vantagem se utilizar convenções de nomenclatura em Java.

Ao usar as convenções de nomenclatura padrão do Java, você facilita a leitura do código para você e outros programadores. A legibilidade do programa Java é muito importante.
Isso indica que menos tempo é gasto para descobrir o que o código faz.

A seguir, estão as principais regras que devem ser seguidas por todos os identificadores:
- O nome não deve conter espaços em branco.
- O nome não deve começar com caracteres especiais como & (e comercial), $ (dólar), _(underline).

Vamos ver algumas outras regras que devem ser seguidas pelos identificadores.

Classe
- Deve começar com a letra maiúscula.
- Deve ser um substantivo como Cor, Botão, Sistema, Tópico, etc.
- Use palavras apropriadas, em vez de siglas.

Exemplo:
public class Teste {
//codificação da classe omitida
}

Interface
- Deve começar com a letra maiúscula.
- Deve ser um adjetivo como Runnable, Remote, ActionListener.
- Use palavras apropriadas, em vez de siglas.

Exemplo:
interface Testado {
//codificação da classe omitida
}

Variável
- Ela deve começar com uma letra minúscula, como id, nome, descricao.
- Não deve começar com caracteres especiais como & (e comercial), $ (dólar), _
(underline).
- Se o nome contiver várias palavras, inicie-o com a letra minúscula seguida por uma letra maiúscula como primeiroNome, ultimoNome.
- Evite usar variáveis de um caractere, como x, y, z.

Exemplo:
class Teste {
//variável
int id;
String descricao;
//codificação da classe omitida
}

Constante
- Deve estar em letras maiúsculas, como VERMELHO, AMARELO.
- Se o nome contiver várias palavras, ele deverá ser separado por um underline (_), como TAMANHO_MINIMO.
- Pode conter dígitos, mas não como a primeira letra.

Exemplo:

class Teste {
//constante
final static int TAMANHO_MINIMO = 18;
//codificação da classe omitida
}

Método
- Deve começar com letra minúscula.
- Deve ser um verbo como main(), print(), println().
- Se o nome contiver várias palavras, inicie-o com uma letra minúscula seguida por uma letra maiúscula, como actionPerformed().

Exemplo:

class Teste {
//método
void imprimir() {
//codificação do método omitida
}
}

Métodos Getters e Setters
Alguns dos muitos frameworks existentes, deduzem quais são as propriedades dos seus objetos ao lerem os métodos getters e setters. Se você utilizar uma convenção diferente nesse ponto, os frameworks não vão encontrar as suas propriedades ou manipulá-las da forma correta, e nesse caso você acaba sendo obrigado a seguir as convenções.
Os getters devem ter o nome começando por get seguido de uma letra maiúscula, ter o retorno diferente de void e não ter parâmetros. Se o tipo de retorno for boolean (o tipo primitivo), o prefixo pode ser tanto get quanto is. Alguns frameworks permitem que o prefixo is possa ser usado também quando o tipo de retorno é Boolean (o Objeto).
Os setters devem ter o nome começando por set seguido de uma letra maiúscula, ter exatamente um parâmetro, e ter retorno void. Alguns os frameworks permitem que o retorno possa ser do tipo da própria classe que declara o método. Além disso, na maioria dos casos, o tipo do parâmetro do setter deve ser o mesmo que o retorno do getter.

Exemplo:
package br.com.tidicas;
public class Teste {
//variavel
int id;
String descricao;
//constante
final static int TAMANHO_MINIMO = 18 ;

public int getId() {
return id;
}

public void setId(int id) {
this.id = id;
}

public String getDescricao() {
return descricao;
}

public void setDescricao(String descricao) {
this.descricao = descricao;
}
//codificacao da classe omitida
}

Pacote
- Deve ser uma letra minúscula, como java, lang.
- Se o nome contiver várias palavras, ele deverá ser separado por pontos (.) Como
java.util, java.lang, br.com.tidicas.

Exemplo:

package br.com.tidicas; //pacote
class Teste {
//codificação da classe omitida
}

CamelCase
CamelCase é utilizado em convenções de nomenclatura Java.
Java segue a sintaxe camelCase para nomear a classe, interface, método e variável.
Se o nome for combinado com duas palavras, a segunda palavra começará com letras maiúsculas sempre como incluiBlog(), primeiroNome, BlogTest, BlogListener, etc.

Espaços em Branco
É um item que é subdividido em Linhas em Branco e Espaços em Branco.

Linhas em Branco
As linhas em branco melhoram a legibilidade, definindo seções de código que estão logicamente relacionadas.
Duas linhas em branco devem sempre ser usadas nas seguintes circunstâncias:
- Entre as seções de um arquivo de código
- Entre as definições de classe e interface

Uma linha em branco deve sempre ser usada nas seguintes circunstâncias:
- Entre métodos
- Entre as variáveis locais em um método e sua primeira declaração
- Antes de um bloco ou comentário de linha única
- Entre seções lógicas dentro de um método para melhorar a legibilidade

Espaços em Branco
Espaços em branco devem ser usados nas seguintes circunstâncias:
- Uma palavra-chave seguida por parênteses deve ser separada por um espaço.

Exemplo:
while (true) {

}

Observe que um espaço em branco não deve ser usado entre o nome de um método e seu parêntese de abertura. Isso ajuda a distinguir palavras-chave de chamadas de método.
Um espaço em branco deve aparecer após as vírgulas nas listas de argumentos.
Todos os operadores binários exceto “.” devem ser separados de seus operandos por espaços. Espaços em branco nunca devem separar operadores unários, como menos unário, incremento (“++”), e decremento (“–”) de seus operandos.

Exemplo:
a += c + d;
a = (a + b) / (c * d);
while (d++ = s++) {
n++;
}
imprimirTamanho(“O tamanho é ” + foo + “\n”);

As expressões em uma instrução for devem ser separadas por espaços em branco.

Exemplo:
for (expr1; expr2; expr3)

Os lançamentos devem ser seguidos por um espaço em branco.

Exemplos:
meuMetodo((byte) aNum, (Object) x);
meuMetodo((int) (cp + 5), ((int) (i + 3)) + 1);

Comentários
Os programas Java podem ter dois tipos de comentários: comentários de implementação e comentários de documentação. Os comentários de implementação são aqueles encontrados em C ++, que são delimitados por /*…*/ e //. Comentários de documentação (conhecidos como “comentários de documentos”) são somente Java e são delimitados por /**…*/. Os comentários do documento podem ser extraídos para arquivos HTML usando a ferramenta javadoc.
Os comentários de implementação destinam-se a comentar o código ou a comentários sobre a implementação específica. Os comentários do documento destinam-se a descrever a especificação do código, de uma perspectiva livre de implementação. Para ser lido por desenvolvedores que podem não necessariamente ter o código-fonte em mãos.
Os comentários devem ser usados para fornecer visões gerais do código e fornecer informações adicionais que não estão prontamente disponíveis no próprio código. Os comentários devem conter apenas informações relevantes para a leitura e compreensão do programa. Por exemplo, as informações sobre como o pacote correspondente é criado ou em qual diretório ele reside não devem ser incluídas como comentários.
A discussão de decisões de design não triviais ou não óbvias é apropriada, mas evite duplicar as informações que estão presentes (e claras) no código. É muito fácil que comentários redundantes fiquem desatualizados. Em geral, evite comentários que possam ficar desatualizados à medida que o código evolui.

Nota: A frequência dos comentários às vezes reflete a baixa qualidade do código. Quando você se sentir obrigado a adicionar um comentário, considere reescrever o código para torná-lo mais claro.
Os comentários não devem ser colocados em caixas grandes desenhadas com asteriscos ou outros caracteres.
Os comentários nunca devem incluir caracteres especiais, como alimentação de formulário e backspace.

Formatos de Comentário de Implementação
Os programas podem ter quatro estilos de comentários de implementação: bloco, linha
única, final e final de linha.

Blocos de Comentários
Os comentários de bloco são usados para fornecer descrições de arquivos, métodos, estruturas de dados e algoritmos. Os comentários do bloco podem ser usados no início de cada arquivo e antes de cada método. Eles também podem ser usados em outros lugares, como nos métodos. Os comentários de bloco dentro de uma função ou método devem ser indentados no mesmo nível do código que eles descrevem.
Um comentário de bloco deve ser precedido por uma linha em branco para separá-lo do resto do código.

/*
* Aqui está um bloco de comentário.
*/

/*
* Aqui está um comentário em bloco com alguns muito especiais
* formatação que desejo que o indent (1) ignore.
*
*
* um
* dois
* três
*/
Nota: indent /*- indent

Comentários de Linha Única
Comentários curtos podem aparecer em uma única linha recuada para o nível do código que se segue. Se um comentário não puder ser escrito em uma única linha, ele deve seguir o formato de bloco de comentário. Um comentário de uma única linha deve ser precedido por uma linha em branco.

Aqui está um exemplo de comentário de uma única linha no código Java:
if (condition) {
/* Lidar com a condição. */

}

Comentários Finais
Comentários muito curtos podem aparecer na mesma linha do código que descrevem, mas devem ser deslocados o suficiente para separá-los das instruções. Se mais de um comentário curto aparecer em um pedaço de código, todos eles devem ser recuados para a mesma configuração de guia.

Aqui está um exemplo de comentário final no código Java:
if (a == 2) {
return TRUE; /* caso especial */
} else {
return isPrime(a); /* funciona somente para alternativa a */
}

Comentários de Fim de Linha
O // delimitador de comentário pode comentar uma linha completa ou apenas uma linha parcial. Não deve ser usado em várias linhas consecutivas para comentários de texto; no entanto, ele pode ser usado em várias linhas consecutivas para comentar as seções do código.

Seguem exemplos de todos os três estilos:

if (foo > 1) {
// Faça um double-flip.

} else {
return false; // Explique o porquê aqui.
}
//if (bar > 1) {
//
//
// Faça um flip triplo.
// …
//} else {
//return false;
//}

Comentários de Documentação
Os comentários do documento descrevem classes, interfaces, construtores, métodos e campos Java. Cada comentário de documento é definido dentro dos delimitadores de comentário /**…*/, com um comentário por classe, interface ou membro. Este comentário deve aparecer logo antes da declaração:

/**
* A classe de exemplo fornece …
*/
public class Exemplo { …

Observe que as classes e interfaces de nível superior não são recuadas, enquanto seus membros são. A primeira linha do comentário de documento (/**) para classes e interfaces não é recuada; cada linha de comentário subsequente do documento tem 1 espaço de recuo (para alinhar verticalmente os asteriscos). Membros, incluindo construtores, têm 4 espaços para a primeira linha de comentário do documento e 5 espaços depois.
Se você precisar fornecer informações sobre uma classe, interface, variável ou método que não seja apropriado para documentação, use um comentário de bloco de implementação ou comentário de uma linha imediatamente após a declaração. Por exemplo, os detalhes sobre a implementação de uma classe devem entrar em tal comentário de bloco de implementação após a instrução da classe, não no comentário do documento da classe.
Os comentários do documento não devem ser posicionados dentro de um método ou bloco de definição do construtor, porque o Java associa os comentários da documentação à primeira declaração após o comentário.

Segue um exemplo de aplicação Java com a utilização de convenções de nomenclatura no código.

Baixar Código-Fonte via GitHub

No vídeo abaixo, irei mostrar este tutorial.

Para ver o vídeo no YouTube Clique Aqui

Por favor, deixe seu like se gostar da dica.

Fonte: http://www.oracle.com/technetwork/java/codeconvtoc-136057.html

Esta entrada foi publicada em Java SE. Adicione o link permanenteaos seus favoritos.

Os comentários estão encerrados.