Ah, a primavera. Que época maravilhosa do ano. Uma época em que as mentes dos jovens programadores se voltam para pensamentos de … intermináveis discussões de última hora sobre formatação de código.
Naturalmente.
E não há argumento mais perene do que o eterno debate entre tabulações e espaços.
Nos sistemas Unix configurados por padrão e nos antigos terminais burros e teletipos, a tradição é que o caractere TAB signifique mover para a direita até que a coluna atual seja um múltiplo de 8. Esse também é o padrão nos dois editores Unix mais populares, Emacs e vi.
Em muitos editores para Windows e Mac, a interpretação padrão é a mesma, exceto pelo fato de que são usados múltiplos de 4 em vez de múltiplos de 8.
Uma terceira interpretação é que o caractere ASCII TAB significa recuo para a próxima parada de tabulaçãoonde as paradas de tabulação são definidas arbitrariamente: elas podem não estar necessariamente distantes umas das outras. A maioria dos processadores de texto pode fazer isso; o Emacs pode fazer isso. Acho que o vi não pode fazer isso, mas não tenho certeza.
Com essas três interpretações, o caractere ASCII TAB está sendo usado essencialmente como um mecanismo de compactação, para fazer com que as sequências de caracteres SPACE ocupem menos espaço no arquivo.
Portanto, a pergunta é: o código* deve ser recuado com espaços..
ou com abas?
De acordo com Cyrus, há uma terceira opção: uma fusão profana de ambas as guias e espaços. Aparentemente, o senhor pode usar tabulação para o alinhamento do recuo primário e, em seguida, espaços em cima disso para o alinhamento detalhado. Assim:
Dessa forma, pelo menos em teoria, o nível de recuo pode ser ajustado dinamicamente sem destruir o alinhamento. Mas estou mais inclinado a pensar nisso como uma combinação de toda a complexidade e das armadilhas de ambas as abordagens.
OK, talvez o senhor seja um programador esclarecido. O senhor foi além de meras questões terrenas como tabulações versus espaços em seu caminho pessoal para o nirvana do código. Talvez o senhor tenha algum tipo de formatador automático sofisticado que seja executado em cada check-in. Ou talvez o senhor esteja usando um próximopróximo-que trata o código como “dados” e o layout (incluindo os espaços em branco) como uma “visualização”, tornando todas essas preocupações irrelevantes.
Mas há uma questão mais profunda a ser considerada. O único projeto de programação sem nenhuma discordância sobre a formatação do código é aquele em que o senhor trabalha sozinho. Sempre que há dois programadores trabalhando no mesmo projeto, há invariavelmente discordâncias sobre como o código deve ser formatado. Às vezes, divergências sérias. Quanto mais programadores o senhor adiciona, mais divididas ficam essas divergências. E lidar com essas divergências pode ser… complicado. Veja este e-mail que recebi de Philip Leitch:
O local onde trabalho atualmente tem um desenvolvedor (que também é o chefe do departamento de desenvolvimento) que “limpa” o código dos outros.
Ou seja, reformatá-lo, normalmente sem alterar o que o código faz, apenas mudando os nomes das variáveis, os nomes das funções, mas principalmente mudando as coisas para a maneira que eles gostam.
Isso é um pouco desconcertante e estou interessado em ver as respostas das pessoas sobre esse assunto.
Um dos piores, pior métodos de teamicide para os desenvolvedores de software é se envolver nesses tipos de guerras de formatação passivo-agressivas. Eu sei porque já passei por isso. Elas destroem as relações entre os colegas e, dependendo do tipo de formatação, também podem prejudicar sua capacidade de comparar efetivamente as revisões no controle de origem, o que é realmente assustador. Não consigo nem imaginar como seria ruim se o líder fosse culpado desse comportamento. Isso é liderar pelo exemplo, sem dúvida. Ruim exemplo.
O mais deprimente de tudo isso é que o senhor a formatação do código é mais importante do que o senhor pensa. Talvez até mesmo o suficiente para justificar as intermináveis guerras religiosas que são travadas por causa disso. Considere o estudo de 1984 de Soloway e Ehrlich citado em Código completo:
Nossos estudos sustentam a afirmação de que o conhecimento dos planos de programação e das regras
do discurso de programação pode ter um impacto significativo na compreensão do programa. Em seu livro chamado The Elements of Programming Style (Os elementos do estilo de programação), Kernighan e Plauger também identificam o que chamaríamos de regras de discurso. Nossos resultados empíricos comprovam essas regras: Não é apenas uma questão de estética que os programas devam ser escritos em um estilo específico. Em vez disso, há uma base psicológica para escrever programas de maneira convencional: os programadores têm grandes expectativas de que outros programadores seguirão essas regras de discurso. Se as regras forem violadas, a utilidade proporcionada pelas expectativas que os programadores criaram ao longo do tempo será efetivamente anulada. Os resultados dos experimentos com alunos programadores iniciantes e avançados e com programadores profissionais descritos neste artigo oferecem um apoio claro a essas afirmações.
Há dados reais de experimentos honestos para apoiar a hipótese de que a formatação consistente do código é pela qual vale a pena lutar. E há dezenas de estudos que comprovam isso também, como observa Steve McConnell:
Em seu artigo clássico Percepção no xadrezChase e Simon relataram um estudo que comparou as habilidades de especialistas e novatos para lembrar as posições das peças no xadrez. Quando as peças estavam dispostas no tabuleiro como poderiam estar durante um jogo, as memórias dos especialistas eram muito superiores às dos novatos. Quando as peças foram dispostas aleatoriamente, houve pouca diferença entre as memórias dos especialistas e dos novatos. A interpretação tradicional desse resultado é que a memória de um especialista não é inerentemente melhor do que a de um novato, mas que o especialista tem uma estrutura de conhecimento que o ajuda a lembrar determinados tipos de informações. Quando as novas informações correspondem à estrutura de conhecimento – nesse caso, o senhor sabe o que está acontecendo,
a colocação sensata das peças de xadrez, o especialista consegue se lembrar dela facilmente. Quando as novas informações não correspondem a uma estrutura de conhecimento – as peças de xadrez são posicionadas aleatoriamente – o especialista não consegue se lembrar delas melhor do que o novato.Alguns anos depois, Ben Shneiderman duplicou os resultados de Chase e Simon na área de programação de computadores e relatou seus resultados em um artigo chamado Exploratory Experiments in Programmer Behavior (Experimentos exploratórios no comportamento do programador). Shneiderman descobriu que quando as instruções do programa eram organizadas em uma ordem sensata, os especialistas conseguiam se lembrar delas melhor do que os novatos. Quando as declarações eram embaralhadas, a superioridade dos especialistas era reduzida. Os resultados de Shneiderman foram confirmados em outros estudos. O conceito básico também foi confirmado nos jogos Go e bridge e em eletrônica, música e física.
Portanto, sim, por mais absurdo que possa parecer, brigar por caracteres de espaço em branco e outras questões aparentemente triviais de layout de código é realmente justificável. Dentro do razoável, é claro, quando isso é feito abertamente, de forma justa e consensual, e sem esfaquear seus colegas de equipe ao longo do caminho.
Escolha guias, espaços, qualquer convenção de layout que faça sentido para o senhor e sua equipe. Na verdade, não importa os estilos de codificação que o senhor escolher. O que o senhor faz importa é que o senhor e todos os demais membros de sua equipe, se atenham a essas convenções e as usem de forma consistente.
Dito isso, somente um idiota usaria tabulações para formatar seu código.
* a menos que o senhor esteja programando em espaço em branco ou Python.