1. Introdução
Na programação, estilo — não é sobre moda, e sim sobre sobrevivência. Java — é uma linguagem usada por equipes enormes e, se cada um escrever “como está acostumado”, o projeto rapidamente se transformará em um conjunto de partes desconexas, em que só o autor (e nem sempre) conseguirá se orientar.
Estilo de código — é um conjunto de regras que tornam o código igualmente legível para todos. É como sinais de trânsito: se forem ignorados, o tráfego rapidamente vira caos.
Por que isso é importante?
- Legibilidade: o código é lido com mais frequência do que é escrito. Estilo ruim — como a letra ilegível de um médico: ninguém entende o que está escrito.
- Manutenibilidade: se o código é escrito seguindo regras, é mais fácil de alterar e há menos chance de quebrar algo por acidente.
- Trabalho em equipe: na equipe, todos devem se entender sem perguntas desnecessárias.
- Ferramentas: autoformatadores e analisadores de código funcionam melhor quando o estilo é unificado.
2. Principais erros de estilo de código (e como evitá-los)
Não seguir indentação e chaves
Erro:
Código sem indentação e com chaves caóticas é sofrível para os olhos e para o cérebro.
if(x>0){
System.out.println("x é positivo");
}else{
System.out.println("x não é positivo");
}
Como fazer:
if (x > 0) {
System.out.println("x é positivo");
} else {
System.out.println("x não é positivo");
}
Comentário:
Use quatro espaços para cada nível de aninhamento (este é o padrão em Java). Tabulação é ruim, a menos que toda a equipe combine o contrário.
Nomes incorretos de variáveis, métodos e classes
Erro:
int a = 5;
String s = "Vasya";
void f() { /* ... */ }
Como fazer:
int age = 5;
String userName = "Vasya";
void printReport() { /* ... */ }
Comentário:
Os nomes devem ser significativos e refletir a essência da variável ou do método.
- Classes — com inicial maiúscula, CamelCase: UserAccount.
- Métodos e variáveis — com inicial minúscula, camelCase: calculateSalary, userList.
Métodos e classes muito longos
Erro:
Um método com 100 linhas, uma classe com 1000 linhas — é modo pesadelo para manutenção.
Como fazer:
Cada método deve fazer uma única coisa e ser curto (o ideal — caber na tela). As classes também não devem crescer ao tamanho de “Guerra e Paz”.
Exemplo:
Ruim:
public void processOrder() {
// 200 linhas de código
}
Bom:
public void processOrder() {
validateOrder();
calculateTotal();
saveToDatabase();
sendEmailConfirmation();
}
Uso de “números mágicos” e strings
Erro:
if (status == 42) {
// ...
}
Como fazer:
public static final int STATUS_APPROVED = 42;
if (status == STATUS_APPROVED) {
// ...
}
Comentário:
Em vez de números e strings “mágicos”, use constantes (static final). Nas versões mais novas do Java, também há enum — use-os para conjuntos limitados de valores.
Comentários: ausência ou excesso
Erro 1:
Nenhum comentário — não dá para entender o que um código complexo faz.
Erro 2:
Comentários para cada ação, até as óbvias.
// Incrementamos x em 1
x = x + 1;
// Verificamos se x é igual a 10
if (x == 10) {
// ...
}
Comentários assim só atrapalham! Comente apenas pontos complexos ou não óbvios. No geral, um bom código deve ser compreensível sem comentários — comentários servem para explicar o “porquê”, não o “o quê”.
// Considera o desconto para clientes VIP
double total = calculateTotalWithDiscount();
3. Convenções Java: como os profissionais escrevem
Em Java há padrões oficiais e de facto de formatação de código. Oracle Java Code Conventions e Google Java Style Guide — os mais populares.
Indentação e chaves
A chave de abertura fica na mesma linha da declaração:
public void print() {
// ...
}
Aninhamento — quatro espaços.
Nomenclatura
- Classes e interfaces: CamelCase com inicial maiúscula (Person, UserAccount).
- Métodos e variáveis: camelCase com inicial minúscula (calculateSalary, userList).
- Constantes: TODAS_AS_LETRAS_MAIÚSCULAS_COM_SUBLINHADO (MAX_SIZE, DEFAULT_TIMEOUT).
- Pacotes: apenas letras minúsculas, podem conter pontos (com.example.project).
Espaços
Espaços ao redor dos operadores e após as vírgulas:
int sum = a + b;
System.out.println(name, age);
Não coloque espaço após o parêntese de abertura nem antes do de fechamento:
if (x > 0) { ... }
Comprimento de linha
Recomenda-se não exceder 100–120 caracteres por linha. (Sim, seu monitor é enorme, mas o código ainda é mais legível quando não vai além do horizonte.)
Ordem de declaração dos membros da classe
Ordem recomendada (segundo a Oracle):
- Campos (primeiro estáticos, depois de instância)
- Construtores
- Métodos
Exemplo:
public class User {
private static int userCount;
private String name;
public User(String name) {
this.name = name;
userCount++;
}
public String getName() {
return name;
}
}
4. Exemplo: refatoração de um estilo ruim
Aqui está um exemplo de classe que pode ser encontrada na natureza:
class person{String n;int a;void p(){System.out.println(n+" "+a);}}
Em algum escritório, um desenvolvedor Java chora por causa desse código.
Vamos melhorá-lo:
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public void print() {
System.out.println(name + " " + age);
}
}
O que mudou:
- Classe e membros com modificadores de acesso corretos.
- Nomes significativos e legíveis.
- Cada membro da classe em uma nova linha.
- Usa um construtor para inicialização.
- Campos private, para preservar a encapsulação.
5. Dicas úteis
Autoformatadores
IDEs modernas (IntelliJ IDEA, Eclipse, VS Code) conseguem formatar automaticamente o código conforme o padrão.
Atalhos de teclado:
- IntelliJ IDEA: Ctrl + Alt + L
- Eclipse: Ctrl + Shift + F
Análise estática
Ferramentas como Checkstyle, SonarLint, PMD ajudam a identificar violações de estilo e possíveis erros antes mesmo da execução do programa.
Como isso funciona:
- O Checkstyle reclama se você tiver uma variável chamada x em vez de userAge.
- O SonarLint vai alertar se um método for longo demais ou se uma classe violar os princípios SOLID.
Separação de responsabilidades e “código limpo”
- Cada classe deve ser responsável por uma única tarefa (Single Responsibility Principle).
- Não tenha medo de criar classes e métodos adicionais — isso não é “inchaço”, é cuidado com o leitor futuro.
- Tente evitar duplicação de código: se você vir dois trechos parecidos — extraia-os para um método separado.
Constantes e “números mágicos”: como fazer certo
Em vez de:
double price = 100 * 0.18;
Melhor:
public static final double VAT_RATE = 0.18;
double price = 100 * VAT_RATE;
E se você frequentemente tiver conjuntos fixos de valores — use enum:
public enum Status {
NEW, IN_PROGRESS, DONE
}
6. Erros típicos no estilo e na legibilidade do código
Erro nº 1: Ignorar as convenções de código.
Se a equipe não tem um estilo unificado, o código rapidamente se torna ilegível e difícil de manter. Mesmo que você escreva sozinho, daqui a um ano você vai agradecer a si mesmo.
Erro nº 2: Nomes muito curtos/longos.
Variável a ou temp — ruim. Variável theCurrentUserNameThatIsUsedForAuthorizationInTheSystem — também não. Encontre um equilíbrio: userName, age, bookList.
Erro nº 3: “Números mágicos”.
Inserir números e strings diretamente no código dificulta a manutenção e aumenta a probabilidade de erros.
Erro nº 4: Métodos e classes enormes.
Quanto maior o método, mais difícil é testá-lo e entendê-lo. Quebre em partes lógicas.
Erro nº 5: Estrutura ruim da classe.
Campos espalhados por todo lado, métodos declarados em ordem aleatória — tudo isso dificulta encontrar rapidamente o lugar certo.
Erro nº 6: Comentários em excesso ou inexistentes.
Um comentário “inicialização de variável” ao lado de int x = 0; não é necessário. Um comentário que explica uma lógica de negócio complexa — é muito necessário.
Erro nº 7: Formatação inconsistente.
Em uma parte do projeto — quatro espaços, em outra — tabulação; aqui as chaves na linha nova, ali — na mesma linha. Isso parece desleixado e irrita os colegas.
GO TO FULL VERSION