Boas Práticas Java

Prévia do material em texto

] 
 
 
 
 
Programação Orientada a Eventos 
Boas Práticas de Programação Java 
2013.1 
 
 
 
 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
2 
 
 
1. Sufixos ................................................................................................................................... 3 
2. Organização dos Arquivos ..................................................................................................... 3 
2.1 Arquivos de Código Fonte (.java) .................................................................................. 3 
3. Indentação............................................................................................................................. 4 
3.1 Tamanho da Linha ......................................................................................................... 4 
3.2 Quebra de Linha ............................................................................................................ 5 
4. Comentários .......................................................................................................................... 6 
4.1 Implementation Comment Formats ............................................................................. 7 
5. Declarações ........................................................................................................................... 8 
5.1 Número por Linha ......................................................................................................... 8 
5.2 Inicialização ................................................................................................................... 8 
5.3 Localização .................................................................................................................... 9 
5.4 Declaração de Classes e Interfaces ............................................................................... 9 
6. Expressões ........................................................................................................................... 10 
6.1 Expressões Simples ..................................................................................................... 10 
6.2 Expressões Compostas ................................................................................................ 10 
6.3 Expressões return ........................................................................................................ 10 
6.4 If, if-else, if else-if else ................................................................................................. 10 
6.5 Expressões “for” .......................................................................................................... 11 
6.6 Expressões “while” ...................................................................................................... 12 
6.7 Expressões do-while .................................................................................................... 12 
6.8 Expressões switch ....................................................................................................... 12 
6.9 Expressões try-catch ................................................................................................... 12 
7. Espaços em Branco .............................................................................................................. 13 
7.1 Linhas em Branco ........................................................................................................ 13 
8. Espaços ................................................................................................................................ 13 
9. Convenções de Nomes ........................................................................................................ 14 
9.1 Pacotes ........................................................................................................................ 14 
9.2 Classes ......................................................................................................................... 14 
9.3 Interfaces ..................................................................................................................... 15 
9.4 Métodos ...................................................................................................................... 15 
9.5 Variáveis ...................................................................................................................... 15 
9.6 Constantes ................................................................................................................... 15 
10. Práticas de Programação ................................................................................................. 16 
10.1 Fornecendo acesso a variáveis de instância e de classe ............................................. 16 
10.2 Referindo-se a variáveis e métodos de classe ............................................................ 16 
10.3 Constantes ................................................................................................................... 16 
10.4 Atribuições de Variáveis .............................................................................................. 16 
10.5 Práticas Diversas.......................................................................................................... 17 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
3 
 
1. Sufixos 
Os arquivos Java possuem os seguintes sufixos (extensões): 
 Código Fonte: “.java”; 
 Classe compilada : “.class”. 
2. Organização dos Arquivos 
Evite arquivos com mais de 2000 linhas, pois eles se tornam arquivos pesados. 
2.1 Arquivos de Código Fonte (.java) 
Cada arquivo Java contém uma única classe ou interface pública. Quando as classes privadas e 
interfaces estão associadas a uma classe pública, você pode colocá-los no arquivo de origem 
igual ao da classe pública. A classe pública deve ser a primeira classe ou interface no arquivo. 
Os arquivos Java seguem a seguinte ordem: 
 Comentário de Cabeçalho; 
 Declaração de pacotes e imports; 
 Declarações de Classes e Interfaces. 
Comentário de Cabeçalho 
Todos os códigos fonte devem possuir um cabeçalho que contenha o nome da Classe, versão, 
data e informações de direitos autorais. 
 
Declaração de Pacotes e Imports 
A primeira linha que não seja comentário, deve ser a declaração do pacote. As linhas seguintes 
 
 
 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
4 
 
Declaração de Classes e Interfaces 
O fluxo a seguir descreve as seções da declaração de uma Classe ou Interface na ordem em 
que devem aparecer. 
1. Comentário de Documentação da Classe ou Interface; 
2. Declaração da Classe ou Interface; 
3. Comentário de Implementação da Classe ou Interface; 
Este comentário deve conter todas as informações da Classe ou Interface mais genéricos e 
que não eram apropriados para o comentário de documentação da Classe ou Interface. 
4. Variáveis estáticas (static) da Classe; 
Primeiro as públicas (public), depois as protegidas (protected), depois as default (sem 
explicitar), e então as privadas (private). 
5. Variáveis instanciáveis; 
Primeiro as públicas (public), depois as protegidas (protected), depois as default (sem 
explicitar), e então as privadas (private). 
6. Construtores; 
7. Métodos. 
Esses métodos devem ser agrupados por funcionalidade ao invés de escopo ou 
acessibilidade. Por exemplo, um método privado pode estar entre dois métodos públicos. 
O objetivo é tornar a leitura e compreensão do código mais fácil. 
3. Indentação 
3.1 Tamanho da Linha 
Evite linhas com mais de 80 colunas, visto que a maioria dos desenvolvedores não possuem 
recursos para visualizar mais que isso. 
Obs.: Para uso em documentações, procure usar no máximo 70 colunas. 
 
 
 
 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
5 
 
3.2 Quebra deLinha 
Quando o código não couber em uma linha (respeitando o limite de 80 colunas), quebre-o 
seguindo os princípios: 
 Quebre após a vírgula; 
 Quebra antes de um operador; 
 Prefira quebras de linha a um nível mais alto; 
 Alinhe a linha de novo com o início da expressão no mesmo nível da linha anterior; 
 Se as regras anteriores levarem a um código confuso ou o código ficar esmagado 
contra a margem direita, coloque apenas 8 espaços em seu lugar. 
Alguns exemplos abaixo: 
Chamadas de métodos 
 
Seguem-se dois exemplos de como quebrar uma expressão aritmética. O primeiro é o 
preferido, uma vez que a quebra ocorre fora da expressão entre parênteses, que é a um nível 
superior. 
 
Seguem-se dois exemplos de indentação de declaração de métodos. O primeiro é o caso 
convencional. A segunda iria deslocar a segunda e terceira linhas para a extrema direita se 
fosse utilizada a indentação convencional. Por isso, recuamos apenas 8 espaços. 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
6 
 
Quebra de linha para declaração de IF’s devem usar a regra dos 8 espaços, uma vez que o 
recuo convencional torna difícil ver o corpo. Por exemplo:
 
4. Comentários 
Programas em Java podem ter dois tipos de comentários:comentários de implementação e 
comentários de documentação. Comentários de aplicação são os encontradosem C + +, que 
são delimitados por / * … * /, e / /. Comentários de documentação (conhecidos como 
“comentários doc”) sãoJava-only, e são delimitados por / ** … * /. Comentários de 
documentação podem ser extraídos para arquivos HTMLusando a ferramenta javadoc. 
Comentários de implementação são destinados a comentar o código ou para comentários 
sobre uma implementaçãoparticular. Comentários de documentação são destinados 
adescrever a especificação do código, a partir de uma perspectiva independente de 
implementação. Para serem lidos por desenvolvedores que não necessariamente possuem o 
código fonte em mãos. 
Os comentários devem ser usados para dar uma visão geral 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 que sejam relevantes para a leitura e compreensão do programa. 
 
 
 
 
 
 
 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
7 
 
4.1 Implementation Comment Formats 
Existem quatro tipos de Comentários de Implementação: bloco, de uma linha, trailing, e de 
final de linha. 
Bloco de Comentários 
Blocos de comentário são usados para fornecer descrições de arquivos, métodos, estruturas 
de dados e algoritmos. Blocos de comentário podem ser utilizados no início de cada arquivo e 
antes de cada método. Eles podem também ser utilizados em outros locais, tais como dentro 
de métodos.Blocos de comentário que estejam dentro de uma função ou método devem ser 
indentados para o mesmo nível que o código que descrevem. 
Um bloco de comentário deve ser precedido por uma linha em branco para separá-lo do resto 
do código. 
 
Comentários de uma linha 
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 pode ser escrito em uma única linha, ele deve seguir o formato 
de bloco de comentário. Um comentário de uma linhadeve ser precedido por uma linha em 
branco. 
 
 
Trailing 
Comentários muito curtos podem aparecer na mesma linha docódigo que descrevem, mas 
devem ser deslocados o suficiente para separá-los das declarações. Se mais de um breve 
comentário aparece em um pedaço de código, todos eles deverão ser recuados para o mesmo 
nível. 
 
 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
8 
 
Final de Linha 
O delimitador / / pode comentar uma linha completa ou apenas uma linha parcial. Ele não 
deve ser utilizado em linhas consecutivas para comentários de texto, no entanto, pode ser 
utilizado em linhas consecutivas para comentar seções de código. 
 
5. Declarações 
5.1 Número por Linha 
Uma declaração por linha é o recomendado, visto que facilita o comentário. Exemplificando, é 
melhor isso: 
 
do que isso : 
 
 Nunca instancie tipos diferentes na mesma linha 
 
5.2 Inicialização 
Procure inicializar variáveis locais onde elas estão declaradas.A única razão para não inicializar 
uma variável onde estádeclarada é se o valor inicial depende de algum cálculo que ocorre 
primeiro. 
 
 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
9 
 
5.3 Localização 
Coloque declarações apenas no início de blocos (Um bloco équalquer código entre chaves ”{” e 
”}”). 
Não espere paradeclarar variáveis até sua primeira utilização, pois pode confundir o 
programador desavisado e dificultar a portabilidade do código dentro do escopo. 
 
5.4 Declaração de Classes e Interfaces 
Ao codificar classes e interfaces Java, as seguintes regras de formatação devem ser seguidas: 
 Não há espaço entre um nome do método e o parêntese ”(“começando sua lista de 
parâmetros; 
 Abrir chaves ”{“ aparece no final da mesma linha com ainstrução de declaração; 
 Fechar chaves ”}” inicia uma linha por si só recuado para coincidir com a sua 
declaração de abertura correspondente. Exceto quando se trata de uma declaração 
nula, o ”}” deve aparecer imediatamente após a ”{“; 
 
 Métodos são separados por uma linha em branco. 
 
 
 
 
 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
10 
 
6. Expressões 
6.1 Expressões Simples 
Cada linha deve conter no máximo uma expressão: 
 
6.2 Expressões Compostas 
Instruções compostas são declarações que contêm listas de instruções entre chaves 
“{instruções}”. Veja as seguintes seções para obter exemplos. 
 As declarações fechadas devem ser indentadas um nível mais do que o comando 
composto; 
 A chave de abertura deve estar no final da linha que se inicia a expressão composta; a 
chave de fechamento deve começar uma linha e ser recuado para o início da 
expressão composta; 
 Chaves são usadas em torno todas as declarações, até mesmo declarações individuais, 
quando eles fazem parte de uma estrutura de controle, como uma instrução if-else ou 
for. Isto torna mais fácil adicionar declarações sem acidentalmente introduzir erros 
devido a esquecer de adicionar chaves. 
6.3 Expressões return 
A instrução de retorno com um valor não deve usar parênteses, a menos que faça o valor de 
retorno mais óbvio de alguma forma. 
 
6.4 If, if-else, if else-if else 
Devem seguir o padrão: 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
11 
 
 
Atenção: Cláusulas IF SEMPRE devem conter chaves “{” e “}”. Nunca faça isso 
 
6.5 Expressões “for” 
Devem seguir o padrão: 
 
Um for vazio (aquele em que todo o trabalho é feito na inicialização, condição e cláusulas de 
atualização) deve ter a seguinte forma: 
 
 Ao usar o operador vírgula na cláusula de inicialização ou atualização de um for, evitar a 
complexidade de usar mais de três variáveis. Se necessário, use declarações separadas antes 
do laço for (para a cláusula de inicialização) ou no final do loop (a cláusula de atualização). 
 
 
 
 
 
 
 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
12 
 
6.6 Expressões “while” 
O while deve ser implementado da seguinte forma: 
 
Um while vazio deve ser implementado da seguinte forma: 
 
6.7 Expressões do-while 
Uma expressão do-while deve ser implementada da seguinte maneira: 
 
6.8 Expressões switch 
Um switch deve seguir o seguinte padrão: 
 
Toda vez que um case não inclui uma instrução break, adicione um comentário onde a 
instrução break seria. Isto é mostrado no exemplo de código anterior. 
Cada instrução switch deve incluir um default. O break no default é redundante, mas evita que 
um erro fall-through ocorre se mais tarde um outrocase for adicionado. 
6.9 Expressões try-catch 
O bloco de try-catch deve seguir o seguinte formato: 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
13 
 
 A instrução try catch-também pode ser seguida por, finally, que é executado 
independentemente de o bloco try ser executado com êxito. 
 
7. Espaços em Branco 
7.1 Linhas em Branco 
As linhas em branco melhoram a legibilidade organizando seções de código que são 
logicamente relacionadas. 
Duas linhas em branco devem ser sempre utilizados nas seguintes circunstâncias: 
 Entre seções de um código fonte; 
 Entre as definições de Classe e Interface. 
Uma linha em branco deve ser sempre utilizada nas seguintes circunstâncias: 
 Entre métodos; 
 Entre as variáveis locais e a primeira instrução de um método; 
 Antes de um bloco de comentário ou de um comentário de linha única; 
 Entre seções lógicas de um método para facilitar a leitura. 
8. Espaços 
Espaços devem ser usados nas seguintes circunstâncias: 
 Uma palavra chave seguida de parênteses deve ser separada por uma espaço 
 
 
 
 Note-se que um espaço em branco não deve ser usado entre um nome de método e 
da sua abertura de parênteses. Isto ajuda a distinguir palavras-chave de chamadas de 
método. 
 O espaço deve aparecer após vírgulas em uma lista de argumentos; 
 Todos os operadores binários, exceto. Devem ser separadas de seus operandos por 
espaços. Os espaços em branco nunca devem separar operadores unários, como 
incremento (“+ +”) e decremento (“-”) de seus operandos. 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
14 
 
 
 Expressões em um “for” devem ser separadas por espaço 
 
 Casts devem ser sempre seguidos por um espaço em branco 
 
 
9. Convenções de Nomes 
As convenções de nomenclatura tornam os programas mais compreensíveis, tornando-os mais 
fáceis de ler. Eles podem também fornecer informação sobre a função do identificador, por 
exemplo, quer se trate de um pacote, constante, ou de classe que pode ser útil na 
compreensão do código. 
9.1 Pacotes 
O prefixo do nome do pacote original é sempre escrito em letras minúsculas todo-ASCII e deve 
ser um dos nomes de domínio de nível superior, atualmente com, edu, gov, mil, net, org, ou 
um dos códigos de duas letras identificando os países, tal como especificado na norma ISO 
3166, 1981. 
Componentes subseqüentes do nome do pacote variam de acordo com uma organização 
própria e convenções de nomenclatura internas. Tais convenções podem especificar que 
certos componentes do nome do diretório têm divisão, departamento, projeto, máquina, ou 
nomes de login. 
Ex: 
br.com.flaviojmendes 
9.2 Classes 
Os nomes de classe devem ser substantivos, em maiúsculas e minúsculas com a primeira letra 
de cada palavra interna em maiúscula. Tente manter seus nomes de classe simples e 
descritivos. Evite siglas e abreviaturas (a menos que a sigla seja muito mais usada que a forma 
longa, como URL ou HTML). 
Ex: 
class Controle; 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
15 
 
class Testador; 
9.3 Interfaces 
Nomes de interface devem ser capitalizados como nomes de classes. 
Ex: 
interface Armazenamento; 
9.4 Métodos 
Métodos devem ser verbos em maiúsculas e minúsculas com a letra minúscula em primeiro 
lugar, e com a primeira letra de cada palavra interna em maiúscula. 
Ex: 
visitarFlavioMendes(); 
comentarPosts(); 
9.5 Variáveis 
Exceto para as variáveis, todas as instâncias, constantes, classes estão em maiúsculas e 
minúsculas com uma letra minúscula em primeiro lugar. Palavras internas começam com letras 
maiúsculas. Os nomes de variáveis não deve começar com underscore _ ou sinal de dólar $ , 
mesmo que ambos sejam permitidos. 
Os nomes de variáveis devem ser curtos, mas significativos. A escolha de um nome da variável 
deve ser mneumônico, isto é, concebido para indicar ao observador casual a intenção da sua 
utilização. Variáveis de apenas uma letra devem ser evitadas, exceto para variáveis 
temporárias ”descartáveis”. Os nomes comuns para variáveis temporárias são i, j, k, m, n e 
para inteiros, c, d, e para caracteres. 
Ex: 
 
9.6 Constantes 
Os nomes de constantes de classes e de constantes ANSIdeve ser todo em letras maiúsculas 
com palavras separadas por sublinhados (“_”). (Constantes ANSI devem ser evitadas, para 
facilidade de depuração.) 
Ex: 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
16 
 
 
10. Práticas de Programação 
10.1 Fornecendo acesso a variáveis de instância e de classe 
Apenas deixe uma variável ou classe públicas se tiver um bom motivo para isso. 
10.2 Referindo-se a variáveis e métodos de classe 
Evite o uso de um objeto para acessar uma classe (estática) ou método. Use um nome de 
classe em seu lugar. Por exemplo: 
 
10.3 Constantes 
Constantes numéricas (literais) não devem ser codificadas diretamente, exceto para -1, 0 e 1, 
que pode aparecer em um loop “for” como os valores do contador. 
10.4 Atribuições de Variáveis 
Evite atribuir o mesmo valor a diversas variáveis em uma única instrução. É difícil de ler. 
Exemplo: 
 
Não use o operador de atribuição em um lugar onde ele pode ser facilmente confundido com o 
operador de igualdade. Exemplo: 
 
Deverá ser assim: 
 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
17 
 
 Não utilize atribuições incorporadas em uma tentativa de melhorar o desempenho de tempo 
de execução. Este é o trabalho do compilador. Exemplo: 
 
Deve ser assim: 
 
10.5 Práticas Diversas 
Parênteses 
É geralmente uma boa idéia usar parênteses em expressõesque envolvam operadores mistos 
para evitar problemas de precedência de operadores. Mesmo se o operador precedenteparece 
claro para você, pode não ser para os outros, você não deve presumir que outros 
programadores sabem precedência, assim como você. 
 
 
Retorno de Valores 
Tente fazer com que a estrutura do seu programa decorresponda à intenção. Exemplo: 
 
Deve ser escrito assim 
 
Similarmente, 
 
deve ser escrito assim 
 
 
Disciplina Programação Orientada a Eventos 
Boas Práticas de Programação 
 
18 
 
Comentários Especiais 
Use XXX em um comentário para sinalizar algo que é errado, mas funciona. Use FIXME para 
marcar algo que é errado e não funciona. 
Fonte: (http://www.flaviojmendes.com/blog/2012/02/09/boas-praticas-em-java-guia-definitivo/)