Estilos Java conflitantes em uma equipe

Faço parte de uma equipe de desenvolvimento Java com prazo de 6 semanas. Isso requer a criação de uma grande quantidade de código muito rapidamente. No entanto, nossa equipe de desenvolvimento possui diferentes estilos de codificação. Tudo, desde convenções de nomes até métodos de abstração, diferem entre nossa equipe. Alguém sabe de algum documento que dite "padrões" para java?

Para esclarecer, fiquei pensando se havia uma organização que ditaria a convenção de nomenclatura adequada para variáveis ​​e funções, por exemplo. Isso é fundamental, pois com um prazo tão curto que não podemos gastar tempo tentando compreender o código um do outro.

Existe uma organização como essa: Sun / Oracle em si. O documento é chamado de Convenções de Código para a Linguagem de Programação Java e descreve a maioria das convenções necessárias. Basta que todos concordem em ler e seguir suas recomendações.

Estou realmente identificando a resposta de Andres e focando no aspecto de formatar uniformemente o código java.

Se você estiver usando o Eclipse, poderá configurar seu formatador Java para formatar automaticamente para o padrão Java. O formatador do Eclipse também possui outras configurações úteis, como os caracteres por linha (ou seja, quantos caracteres por linha antes de quebrar em uma nova linha) e muitos outros. A padronização de caracteres por linha facilita a difusão do código escrito por diferentes desenvolvedores sem muitas diferenças apenas no espaçamento e nas quebras de linha.

Finalmente, com o Eclipse, depois de definir todas as configurações desejadas, exporte seu formatador como um arquivo que pode ser importado por todos os membros da equipe. Portanto, se você estiver usando o Eclipse, eu recomendo explorar totalmente todas as opções que serão formatadas automaticamente e editadas para você, além de compartilhar as configurações com toda a equipe.

Eu diria que os outros IDEs Java principais (IntelliJ e Netbeans) têm um recurso semelhante para exportar as configurações de formato.

Esse [estilos diferentes de codificação] é fundamental, pois com um prazo tão curto que não podemos gastar tempo tentando entender o código um do outro.

Na realidade. Não é primordial.

Depois de 30 anos como consultor, li muitos códigos de muitos clientes. É importante observar que todos os clientes (e geralmente dentro da organização de um cliente) existem estilos variados.

Depois de ler tantos estilos, aprendi isso.

O estilo não importa

Concentre-se na escrita de código que sempre funciona e na escrita de testes de unidade que provam que sempre funciona.

Depois de enviar o código de trabalho, você poderá usá-lo se ficar sem bugs para corrigir e aprimoramentos para instalar.

Não se preocupe em escolher um padrão universal perfeito. Tudo o que você precisa é que sua equipe aceite um padrão e cumpra-o. Faça o seu próprio, se desejar, mas seja consistente.

A consistência melhora a colaboração, a colaboração aprimora o código.

Mesmo que a consistência real não ajude, o fato de sua equipe trabalhar em conjunto para chegar a um acordo é uma coisa boa. Sua incapacidade de concordar com algo tão simples quanto as convenções de codificação diz que pode haver problemas maiores de trabalho em equipe à espreita.

O Sun Java CC mencionado acima não só tem 13 anos e algumas de suas regras estão desatualizadas (como 80 caracteres por linha), mas também não define convenções de nomenclatura, exceto as mais gerais (revestimento de camelo para classes, maiúsculas e minúsculas) para variáveis ​​finais estáticas e similares).

Você precisa definir seus próprios padrões para diferentes tipos de classes, como DAOs, EJBs, entidades, o que você usar. O Sun Java CC é como uma classe base abstrata destinada a estender :)

Conforme mencionado por outros aqui, você pode pesquisar on-line um dos poucos 'guias de estilo' populares para Java e convencer todos da equipe a cumpri-los. Algumas ferramentas de verificação de código no seu IDE favorito podem ajudar a lembrá-lo quando você não estiver fazendo isso.

No entanto, às vezes a política está envolvida. Já estive em uma situação em que o desenvolvedor mais sênior da equipe continua fazendo o que quer, mesmo depois que alguém mencionou a necessidade de padronizar. Em tal situação, talvez seja melhor observar seu estilo de código e segui-lo, pois ele provavelmente tem mais conhecimento sobre a base e os requisitos de código e você pode não querer perder tempo pisando nos dedos dos pés, mesmo que esteja sendo difícil. Foi o que o resto de nós fez nessa situação em particular e eu relutantemente o segui.

Portanto, é importante considerar sua situação também.

Tio Bob mostra um estilo de codificação mais moderno e atual em seu livro "Clean Code". Infelizmente, não contém uma lista de itens. Você tem que ler isso. Ele diz a si mesmo que, para ver suas convenções, você precisa ler o código dele. O tio Bob é sem dúvida um tipo de instituição. De qualquer maneira, o livro é uma excelente leitura, portanto, mesmo que seja tarde demais para lê-lo agora, leia-o o mais rápido possível.

O que realmente importa no código é baixa complexidade ciclomática, escopo pequeno, alta coesão e escolha de identificadores expressivos. Diante disso, o código se torna fácil de entender e é bom.

Eu sugiro que você analise a programação espartana .

A maioria dos padrões de codificação informa como fazer com que o código mal escrito pareça bonito e a maioria das discussões sobre o "estilo de codificação" são realmente sobre formatação. A formatação de código é sobre representar visualmente a estrutura do seu código. É trivial e automatizável e quase não tem nada a ver com o estilo de codificação, porque o estilo de codificação não é sobre como você representa a estrutura do código, mas sobre como você o estrutura.
Também existem muitas guerras religiosas sobre convenções de nomenclatura, embora na verdade elas sejam apenas um truque para contornar o design deficiente. Um nome é bom, se diz o que significa. Quanto menor e mais claro o seu escopo, mais fácil é escolher esse nome.