Primeiro, adapte meu estilo de codificação re: espaço em branco. Há muito tempo, um palhaço escreveu um artigo de piada sobre práticas recomendadas, fornecendo exemplos de código com 12 guias completas de espaço em branco em todos os lugares que podia; tornando impossível a leitura do código sem uma tela ampla de 12 pés ou no tamanho de fonte .0001. Muitos programadores assumiram que era credível e começaram a fazê-lo - mesmo que obviamente não fosse uma boa prática. Me deixa louco. Vamos lá pessoal, eu digo, você é mais inteligente que isso. 50% ou mais de espaço em branco na página de 240 colunas não faz sentido. Coloque o primeiro colchete na mesma linha da assinatura da função ou da classe (com um espaço ou dois, não uma guia ou duas no meio). Use 3 espaços para recuar para os níveis de código (5 se você tiver um membro da equipe parcialmente cego). Em seguida, use uma linha em branco aqui e ali no código para colocar as coisas em blocos lógicos menores.
Aqui está outro exemplo de algo que é estúpido. Primeiro, vou lhe dizer que isso não vem de uma inteligência inexperiente. Está em um código muito bom de um cara que foi capaz de obter uma técnica muito avançada trabalhando enquanto a maioria do resto do mundo ainda está coçando a cabeça sobre isso. Isso é o que é frustrante para mim. Por que bons programadores estão tão preocupados em formatar seu código?
for (Iterator<Byte> iterator = collection.iterator(); iterator
.hasNext();) {
byteArray[i++] = iterator.next();
}
Agora, basta olhar para o formato da condição for. Se você realmente pensa sobre isso, não é um lugar totalmente ilógico para colocar uma quebra de linha? Por um lado, eu tinha muito espaço para ver o todo por ... {em uma linha. (Felizmente, esse cara não usa várias guias para recuar.) Mas se ele absolutamente não podia viver sem quebrá-lo, por que há no meio de uma especificação de função? Há um delimitador perfeitamente bom antes disso - o ponto-e-vírgula - que faria mais sentido como um ponto de interrupção. Meu voto é colocar toda a condição e a abertura {(que acompanha o for) na mesma linha. Ele também termina bem - fácil de combinar a chave de fechamento com o "for" que abriu. (Algumas pessoas - e ferramentas (isso é redundante?) - também gostam de colocar isso em lugares estranhos.)
Segundo - anote o foco da experiência de cada programador e, se houver uma diferença significativa, verifique se isso reflete em qual parte do código cada programador trabalha. Um especialista em controle industrial de robótica, um engenheiro que trabalha principalmente em bits matemáticos complexos e o cara com o diploma de CS que se impressiona com a construção de código totalmente obscura (quanto menos compreensível, mais sofisticado, certo?) São todos vai escrever código de forma diferente. Onde houver diferenças significativas, interrompa o trabalho para que cada força individual corresponda ao trabalho.
Quando não houver diferenças, concorde com o estilo de codificação e, em qualquer caso - revisão de código, revisão de código, revisão de código. Francamente, eu já passei por um monte de código esparguete desleixado em minha vida (12 vezes na linha em depuração e alterações pelo grupo de manutenção, ou o resultado da integração de olhos arregalados) e estava no meu caminho para ser um especialista em código após 2 minutos conversando com o último sujeito que trabalhou nele. (Observação: de fato, há um ponto em que é melhor reescrever o código do que continuar adaptando.)
Pessoalmente, prefiro trabalhar em casa sozinho. Eu nunca conheci um programador que prefere ou trabalhe melhor em um ambiente cúbico cercado por muitos outros programadores, discussões e interrupções. Mas você precisa se acostumar a trabalhar em equipe, e isso significa reservar um tempo para se reunir e discutir (não brigar) o que está fazendo. Na verdade, isso faz parte do trabalho - é mesmo. Muito melhor aceitá-lo e fazê-lo de forma sistemática, eficiente e eficaz. E enquanto estamos nisso - também faz parte do trabalho gastar tempo transferindo conhecimento e informações para as pessoas que escrevem a documentação (algumas das quais você pode precisar escrever por conta própria). E quando você tiver experiência suficiente para aumentar seu nível de responsabilidade, poderá até conversar com mais frequência com gerentes e pessoas em marketing etc.
Codificar sozinho é um hobby. A engenharia de software profissional é uma ocupação multifacetada.