Erros típicos no código Java.

Este material contém os erros mais comuns que vi no código Java de pessoas que trabalham comigo. A análise estática (usamos qulice ), por motivos óbvios, não consegue detectar todos esses erros, por isso decidi listá-los aqui. Todos esses erros estão relacionados à programação orientada a objetos em geral e ao Java em particular.

Nomes de classes

Sua classe deve ser uma abstração de um objeto da vida real sem " validadores " , " controladores " , " gerentes " , etc. Se o nome da sua classe terminar com "-er", o design é ruim. E, claro, classes auxiliares antipadrão como StringUtils , FileUtils e IOUtils do Apache são ótimos exemplos de padrões de design terríveis. Nunca adicione sufixos ou prefixos para diferenciar interfaces e classes. Por exemplo, todos esses nomes são terríveis: IRecord , IfaceEmployee ou RecordInterface . Normalmente, o nome da interface é o nome do objeto da vida real, enquanto o nome da classe deve explicar os detalhes da implementação. Se nada específico puder ser dito sobre a implementação, os nomes " Default ", " Simple " ou algo semelhante servirão. Por exemplo: class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};

Nomes de métodos

Os métodos podem retornar “ alguma coisa ” ou retornar “ void ”. Se um método retornar algo, então seu nome deverá explicar o que será retornado. Por exemplo (não use o prefixo " get "): boolean isValid(String name); String content(); int ageOf(File file); Se " void " for retornado, o nome deverá esclarecer o que o método faz. Por exemplo: void save(File file); void process(Work work); void append(File file, String line); Há apenas uma exceção a esta regra - métodos de teste JUnit . Eles são descritos abaixo.

Nomes de métodos de teste

Os nomes dos métodos nos testes JUnit devem ser construídos como uma frase em inglês sem espaços. Isso é mais fácil de explicar com um exemplo: É /** * HttpRequest can return its content in Unicode. * @throws Exception If test fails */ public void returnsItsContentInUnicode() throws Exception { } importante iniciar a primeira frase do seu JavaDoc com o nome da classe que você está testando seguido de “ can ”. Portanto, a primeira frase deve ser sempre como a frase “ alguém pode fazer alguma coisa ”. O nome do método indicará a mesma coisa, mas sem o assunto do teste. Se eu adicioná-lo ao início do nome do método, obtenho uma frase completa em inglês, como no exemplo acima: “ HttpRequest retorna seu conteúdo em unicode .” Observe que o nome do método de teste não começa com “ can ”. Somente comentários JavaDoc começam com " can ". Além disso, os nomes dos métodos não devem começar com um verbo ( Do tradutor: aparentemente, o autor se refere ao modo imperativo do verbo ). É uma boa prática indicar que uma exceção é lançada ao declarar um método de teste.

Nomes de variáveis

Evite nomes de variáveis ​​compostos como timeOfDay , firstItem ou httpRequest . Quero dizer variáveis ​​de classe e variáveis ​​de método. O nome da variável deve ser longo o suficiente para evitar ambiguidade no seu escopo, mas não muito longo, se possível. O nome deve ser um substantivo no singular ou no plural. Por exemplo: Às vezes pode haver colisões entre parâmetros do construtor e campos de classe se o construtor armazenar dados de entrada no objeto criado. Nesse caso, recomendo criar uma abreviatura retirando as vogais. Exemplo: Na maioria dos casos, o melhor nome de variável será o nome da classe correspondente. Basta colocá-lo em maiúscula e você ficará bem: no entanto, nunca faça o mesmo para tipos primitivos como ou . Você também pode usar adjetivos quando houver diversas variáveis ​​com características diferentes. Por exemplo: List names; void sendThroughProxy(File file, Protocol proto); private File content; public HttpRequest request; public class Message { private String recipient; public Message(String rcpt) { this.recipient = rcpt; } } File file; User user; Branch branch; Integer number String string String contact(String left, String right);

Construtores

Sem exceção, deve haver apenas um construtor que armazene dados em variáveis ​​de objeto. Todos os outros construtores devem chamar este com parâmetros diferentes: public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }

Variáveis ​​únicas

Evite variáveis ​​únicas a todo custo. Por “descartáveis” quero dizer variáveis ​​que são usadas uma vez. Como neste exemplo: String name = "data.txt"; return new File(name); Uma variável é usada apenas uma vez, e o código pode ser simplificado para: return new File("data.txt"); Às vezes, em casos muito raros - principalmente devido a uma melhor formatação - variáveis ​​únicas podem ser usadas. No entanto, tente evitar tais situações.

Exceções.

É claro que você nunca deve “engolir” exceções; elas devem ser lançadas o mais alto possível. Exceções de métodos privados devem ser tratadas externamente. Nunca use exceções para controlar o fluxo. O código no exemplo está incorreto: int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; } Sério, e se o IOException disser "disco cheio", você assumirá que o tamanho do arquivo é zero e continuará?

Recuo.

Para recuo, a regra geral é que o parêntese deve terminar a linha ou fechar na mesma linha (a regra oposta se aplica ao parêntese de fechamento). No exemplo abaixo, o código está incorreto porque o primeiro parêntese não está fechado na mesma linha e há caracteres depois dele. O segundo colchete tem o mesmo problema porque há caracteres antes dele e não há colchete de abertura na linha atual. final File file = new File(directory, "file.txt"); O recuo correto deve ser assim: StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" ); A segunda regra importante de recuo é que você deve colocar o máximo possível em uma linha - dentro de 80 caracteres. O exemplo acima não é válido porque pode ser compactado: StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );

Constantes redundantes.

Constantes de classe devem ser usadas quando você deseja compartilhar o acesso a informações entre métodos de classe, e esta informação é uma característica( ! ) da sua classe. Não use constantes como substitutos de strings ou literais numéricos - prática muito ruim, pois leva à poluição do código. Constantes (como outros objetos OOP) devem ter significado no mundo real. Qual é o significado dessas constantes no mundo real: class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice } Outro erro comum é usar constantes em testes de unidade para evitar a duplicação de strings/literais numéricos em métodos de teste. Não faça isso! Cada método de teste deve operar com seu próprio conjunto de valores de entrada. Use novos textos e números em cada novo método de teste. Os testes são independentes. Então, por que eles deveriam compartilhar as mesmas constantes de entrada?

Teste de acoplamento de dados.

Aqui está um exemplo de conexão com um método de teste: User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff")); Na última linha, concatenamos " Jeff " com a mesma string literal especificada na primeira linha. Se, alguns meses depois, alguém quiser alterar o valor da terceira linha, terá que gastar mais tempo procurando onde mais " Jeff " é usado neste método. Para evitar esse problema de dados, você deve introduzir uma variável.