sem15_boas_prticas

Prévia do material em texto

AULA TEÓRICA 16 
 
 
 
 
 
Tema 15. Boas	
  prá)cas	
  de	
  programação	
  
Ø  como	
  organizar	
  o	
  código;	
  	
  
Ø  importância	
  dos	
  comentários	
  e	
  documentação;	
  
Ø  como	
  usar	
  convenções	
  de	
  nomes;	
  
Ø  importância	
  de	
  tratamento	
  de	
  erros	
  e	
  padrões	
  de	
  projetos.	
   
Elaborado por eng.Tatiana Kovalenko, UEM 
1	
  
Boas práticas de programação 
 
Para que serve: 
 
Ø  Organizar e melhorar o processo de desenvolvimento de software, facilitar a 
manutenção e reduzir os custos, e consequentemente aprimorar a 
qualidade do produto final. 
 
Ø  Na busca de qualidade ao desenvolver um aplicativo, é imprescindível a 
adoção de boas práticas. Destacamos algumas delas que ajudam a manter 
o código mais legível, fácil de compreender e de manter. 
Lembre-se, para alcançarmos um bom código, não basta apenas que ele 
funcione. 
 
O uso de regras e boas práticas geram melhor legibilidade do código, 
contribuindo significativamente para que o ciclo de desenvolvimento de 
sistemas ocorra de maneira mais ágil, prática e de fácil manutenção. 
 
Programadores mais experientes costumam dizer que “a pior coisa que existe 
é dar continuidade a um software desenvolvido por terceiros”. 
 2	
  
 
1.1 – Por que padronizar? 
 
Convenções de código são importantes para os programadores pelos 
seguintes motivos: 
²  80% do tempo gasto em codificação de um software é na fase de 
manutenção; 
²  Dificilmente qualquer software é mantido por toda a sua vida pelo 
autor original; 
²  Convenções de código melhoram a legibilidade do software, permitindo que 
os desenvolvedores entendam o código de forma mais rápida e 
completamente; 
²  Se você enviar o seu código-fonte como um produto, você precisa ter 
certeza de que é bem feito e limpo como qualquer outro produto que você 
criar. 
 
2 – Nomeação de Ficheiros 
2.1 – Sufixos 
Os ficheiros Java possuem os seguintes sufixos (extensões): 
Código Fonte: “.java”; 
Classe compilada : “.class”. 
3	
  
 
 3 – Organização dos Ficheiros 
Evite arquivos com mais de 2000 linhas, pois eles se tornam ficheiros pesados. 
 
 3.1 – Ficheiros de Código Fonte (.java) 
 
Cada ficheiro Java contém uma única classe ou interface pública (public). 
Quando as classes privadas (private) e interfaces (interface) estão 
associadas a uma classe pública, você pode colocá-los no ficheiros de origem 
igual ao da classe pública. A classe pública deve ser a primeira classe ou 
interface no ficheiros . 
 
Os ficheiros Java seguem a seguinte ordem: 
§  Comentário de Cabeçalho; 
§  Declaração de pacotes e imports; 
§  Declarações de Classes e Interfaces. 
 
 3.1.1 – 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. 
 4	
  
 /* 
 * Classe 
 * 
 * Versão 
 * 
 * Data 
 * 
 * Copyright 
 */ 
 
3.1.2 – 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 podem ser os imports. 
 
package br.com.flaviojmendes; 
import java.io.*; 
 
5	
  
3.1.3 – Declaração de Classes e Interfaces 
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; 
u  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; 
u  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; 
u  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. 
u  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. 
 6	
  
4 – Indentação 
 
“Muita gente pode achar “frescura” esse capítulo, entretanto é algo que quando 
comecei a me policiar para usar essas padronizações senti logo o quanto 
ajuda, e finalmente parei de me preocupar em rolar a tela para a direita 
infinitamente até chegar ao fim da linha.” [2] 
 
4.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. 
 
4.2 – Quebra de Linha 
 
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. 7	
  
Alguns exemplos abaixo: 
 
v  Chamadas de métodos 
meuMetodo(variavelLong1, variavelLong2, variavelLong3, 
 variavelLong4, variavelLong5); 
 
var = meuMetodo1(variavelLong1, 
 meuMetodo2(variavelLong2, 
 variavelLong3)); 
 
Seguem-se do is 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. 
 
nomeLong1 = nomeLong2 * (nomeLong3 + nomeLong4 - nomeLong5) 
 + 4 * nomeLong6; // PREFERÍVEL 
 
nomeLong1 = nomeLong2 * (nomeLong3 + nomeLong4 
 - nomeLong5) + 4 * nomeLong6; //EVITAR 
 
8	
  
Seguem-se do is exemplos de indentação de dec la raçã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. 
 
//INDENTAÇÃO CONVENCIONAL 
meuMetodo(int numero, Object objetoFlavio, String objetoComBr, 
 Object maisUm) { 
 ... 
} 
 
//RECUAR 8 ESPAÇOS PARA EVITAR RECUO EXCESSIVO 
private static synchronized metodoFlavioJMendes(int numero, 
 Object objetoFlavio, String objetoComBr, 
 Object maisUm) { 
 ... 
} 
9	
  
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: 
 
//NÃO USE ESSA INDENTAÇÃO 
if ((condicao1 && condicao2) 
 || (condicao3 && condicao4) 
 ||!(condicao5 && condicao6)) { //QUEBRAS RUINS 
 metodoFazAlgumaCoisa(); //DIFÍCIL VISUALIZAÇÃO 
} 
 
//USE ESSA INDENTAÇÃO 
if ((condicao1 && condicao2) 
 || (condicao3 && condicao4) 
 ||!(condicao5 && condicao6)) { 
 metodoFazAlgumaCoisa(); 
} 
 
//OU FAÇA ASSIM 
if ((condicao1 && condicao2) || (condicao3 && condicao4) 
 ||!(condicao5 && condicao6)) { 
 metodoFazAlgumaCoisa(); 
} 
 
10	
  
5 – Comentários 
 
Programas em Java podem ter dois tipos de comentários: 
²  c o m e n t á r i o s d e i m p l e m e n t a ç ã o e c o m e n t á r i o s d e 
documentação. Comentários de aplicação são os encontrados em C++, 
que são delimitados por /* … */, e //. 
²  Comentários de documentação (conhecidos como “comentários doc”) são 
Java-only, e são delimitados por / ** … * /. Comentários de 
documentação podem ser extraídos para arquivos HTML usando a 
ferramenta javadoc. 
 
Comentários de implementação são destinados a comentar o código ou para 
comentários sobre uma implementação particular. 
 
Comentários de documentação são destinados a descrever a especificação 
do código, a partir de uma perspectiva independente de implementação. Paraserem 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. 
11	
  
5.1. Comentários. Formatos de implementação 
 
Existem quatro tipos de Comentários de Implementação: bloco, de uma linha, 
trailing, e de final de linha. 
 
5.1.1 Bloco de Comentários 
 
Blocos de comentário são usados​ para fornecer descrições de ficheiros, 
métodos, estruturas de dados e algoritmos. Blocos de comentário podem ser 
utilizados no início de cada ficheiro 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. 
 
/* 
 * Esse é um bloco de comentário. 
 */ 
12	
  
5.1.2 – 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 linha deve ser precedido por uma linha em branco. 
if (condicao) { 
 
 /* Trata a condição acima. */ 
 ... 
} 
 
5.1.3 – Trailing (à direita) 
Comentários muito curtos podem aparecer na mesma linha do có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 recuado para o mesmo nível. 
if (a == 2) { 
 return true; /* caso especial */ 
} else { 
 return isImpar(a); /* é impar */ 
} 
 
13	
  
5.1.4 – Final de Linha 
 
delimitador // pode comentar uma linha completa ou apenas uma 
l i n h a p a r c i a l . E l e n ã o d e v e s e r u t i l i z a d o e m l i n h a s 
consecutivas para comentários de texto, no entanto, pode ser utilizado 
em linhas consecutivas para comentar seções de código. 
 
if (condicao > 1) { 
 
 // Faz uma pirueta. 
 ... 
} 
else { 
 return false; // Eis a questão. 
} 
//if (daianeDosSantosMode > 1) { 
// 
// // Fazer um Twist Carpado. 
// ... 
//} 
//else { 
// return false; 
//} 14	
  
6 – Declarações 
6.1 – Número por Linha 
 
Uma declaração por linha é o recomendado, visto que facilita o comentário. 
Exemplificando, é melhor isso: 
 
int altura; // altura da tabela 
int largura; // largura da tabela 
 
do que isso: 
 
int altura, largura; 
 
Nunca instancie tipos diferentes na mesma linha: 
 
int qtdCasas, numerosCasas[]; //ERRADO! 
 
6.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. 
 15	
  
6.3 – Localização 
 
Coloque declarações apenas no início de blocos. (Um bloco é qualquer 
código entre chavetas ”{” e ”}”.) Não espere para declarar variáveis​ até sua 
primeira utilização, pois pode confundir o programador desavisado e dificultar a 
portabilidade do código dentro do escopo. 
 
void meuMetodo() { 
 int int1 = 0; // início do bloco do método 
 
 if (condicao) { 
 int int2 = 0; // início do bloco do if 
 ... 
 } 
} 
 
6.4 – Declaração de Classes e Interfaces 
 
Ao codificar classes e interfaces Java, as seguintes regras de 
formatação devem ser seguidas: 
o  Não há espaço entre um nome do método e o parêntese ”(“ começando sua 
lista de parâmetros; 
o  Abrir chavetas ”{“ aparece no final da mesma linha com a instrução de 
declaração; 16	
  
o  Fechar chaveta ”}” inicia uma linha por si só recuado para coincidir com a 
sua declaração de abertura correspondente. Excepto quando se trata de 
uma declaração nula, a ”}” deve aparecer imediatamente após a ”{“; 
class Exemplo extends Object { 
 int ivar1; 
 int ivar2; 
 
 Exemplo(int i, int j) { 
 ivar1 = i; 
 ivar2 = j; 
 } 
 
 int metodoVazio() {} 
 
 ... 
} 
 
o  Métodos são separados por uma linha em branco. 
 
17	
  
7 – Expressões 
7.1 – Expressões Simples 
Cada linha deve conter no máximo uma expressão: 
 
argv++; // Certo 
argc--; // Certo 
argv++; argc--; // ERRADO! 
 
7.2 – Expressões Compostas 
Instruções compostas são declarações que contêm listas de instruções entre 
chavetas “{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 chaveta de abertura deve estar no final da linha que se inicia a expressão 
composta; a chaveta de fechamento deve começar uma linha e ser recuado 
para o início da expressão composta; 
 
Chavetas 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. 
7.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. 
18	
  
 return; 
 return disco.tamanho(); 
 
7.4 if, if-else, if else-if else 
Devem seguir o padrão: 
if (condicao) { 
 instrucoes; 
} 
if (condicao) { 
 instrucoes; 
} else { 
 instrucoes; 
} 
 if (condicao) { 
 instrucoes; 
} else if (condicao) { 
 instrucoes; 
} else { 
 instrucoes; 
} 
Atenção: Cláusulas if SEMPRE devem conter chavetas “{” e “}”. Nunca faça 
isso if (condicao) //EVITE! NÃO OMITA AS CHAVETAS {}! 
 instrucao; 
19	
  
7.5 Expressões “for” 
 
Devem seguir o padrão: 
 
for (inicializacao; condicao; passo) { 
 instrucoes; 
} 
 
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: 
 
for (inicializacao; condicao; passo); 
 
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 ciclo for (para a cláusula de inicialização) 
ou no final. 
 
7.6 – Expressões “while” 
while deve ser implementado da seguinte forma: 
 
while (condicao) { 
 instrucoes; 
} 
20	
  
Uma expressão do-while deve ser implementada da seguinte maneira: 
do { 
 instrucoes; 
} while (condicao); 
 
7.8 – Expressões switch 
 
Um switch deve seguir o seguinte padrão: 
switch (condicao) { 
case ABC: 
 instrucoes; 
 /* passa direto */ 
case DEF: 
 intrucoes; 
 break; 
case XYZ: 
 intrucoes; 
 break; 
default: 
 intrucoes; 
 break; 
} 21	
  
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 
outro case for adicionado. 
 
7.9 – Expressões try-catch 
bloco de try-catch deve seguir o seguinte formato: 
try { 
 instrucoes; 
} catch (ExceptionClass e) { 
 instrucoes; 
} 
A instrução try catch também pode ser seguida por, finally, que é 
executado independentemente de o bloco try ser executado com êxito. 
try { 
 instrucoes; 
} catch (ExceptionClass e) { 
 instrucoes; 
} finally { 
 instrucoes; 
} 22	
  
 
8 – Espaços em Branco 
8.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. 
 
23	
  
8.2 – 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 
while (true) { 
 ... 
} 
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. 
a += c + d; 
a = (a + b) / (c * d); 
 
while (d++ = s++) { 
 n++; 
} 
printSize("tamanho é " + tamanho + "\n"); 
24	
  
Expressões em um for devem ser separadas por espaço 
for (expr1; expr2; expr3) 
 
Casts devem ser sempre seguidos por um espaço em branco 
 
meuMetodo((byte) aNum, (Object) x); 
meuMetodo((int) (cp + 5), ((int) (i + 3)) + 1); 
 
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 subsequentes do nome do pacote varia de acordo com uma 
organização próprias convenções de nomenclatura internos. 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 25	
  
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; 
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 coma letra 
minúscula em primeiro lugar, e com a primeira letra de cada palavra interna em 
maiúscula. 
Ex: 
visitarFlavioMendes(); 
comentarPosts(); 
26	
  
9.5 – Variáveis 
Excepto 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 mnemônico, isto é, concebido para indicar 
ao observador casual a intenção da sua utilização. 
 
Variáveis de apenas uma letra ​ devem ser evitadas, excepto para 
variáveis temporárias ”descartáveis”. Os nomes comuns para variáveis ​​
temporárias são i,j,k, m, n para inteiros, c, d, e para caracteres. 
 
Ex: 
 int i; 
 char c; 
 float distanciaNominal; 
 
27	
  
9.6 – Constantes 
 
Os nomes de constantes de classes deve ser todo em letras maiúsculas 
com palavras separadas por sublinhados (“_”). 
 
Ex: 
static final int TAMANHO_MAXIMO = 4; 
 
static final int PESO_MAXIMO = 999; 
 
static final int CPU = 1; 
 
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: 
 
metodo(); //OK 
Classe.metodo(); //OK 
objetoClasse.metodo(); //EVITE! 28	
  
10.3 – Constantes 
Constantes numéricas (literais) não devem ser codificadas directamente, 
excepto para -1, 0 e 1, que pode aparecer em um ciclo 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: 
 
altura1 = altura2 = 170; // EVITE! 
 
Não use o operador de atribuição em um lugar onde ele pode ser 
facilmente confundido com o operador de igualdade. Exemplo: 
 
if (c++ = d++) { // NÃO FAZER ISSO! 
 ... 
} 
 
Deverá ser assim: 
 
if ((c++ = d++) != 0) { 
 ... 
} 29	
  
Não utilize atribuições incorporadas em uma tentativa de melhorar o 
desempenho de tempo de execução. Este é o trabalho do compilador. 
Exemplo: 
 
d = (a = b + c) + r; // EVITE! 
 
Deve ser assim: 
 
a = b + c; 
d = a + r; 
 
10.5 – Práticas Diversas 
10.5.1 – Parênteses 
É geralmente uma boa ideia usar parênteses em expressões que 
envolvam operadores mistos para evitar problemas de precedência de 
operadores. Mesmo se o operador precedente parece claro para você, pode 
não ser para os outros, você não deve presumir que outros 
programadores sabem precedência, assim como você. 
 
if (a == b && c == d) // EVITE! 
if ((a == b) && (c == d)) // CERTO 
 
30	
  
Referência bibliográfica: 
 
1 ) . B o a s p r á t i c a s d e P r o g r a m a ç ã o - A r t i g o e a s y J a v a M a g a z i n e 6 
ht tp : / /www.devmedia.com.br /boas-prat icas-de-programacao-ar t igo-easy- java-
magazine-6/21137#ixzz28WCZlAD7 
 
2). Flávio J. Mendes on 09/02/2012 in Conceitos, Tutoriais 
http://www.flaviojmendes.com/blog/2012/02/09/boas-praticas-em-java-guia-definitivo/ 
 
31