Abas versus espaços - qual é o caractere de indentação adequado para tudo, em todas as situações, sempre? [fechadas]

Os padrões de codificação para o código hospedado em drupal.org sugerem o uso de dois espaços para recuar o código; outros sites sugerem usar guias para recuar o código.

Qual é o caráter de indentação adequado para tudo e em todas as situações? Por favor, explique a resposta que você dá.

Espaços

Uma guia pode ter um número diferente de colunas, dependendo do seu ambiente, mas um espaço é sempre uma coluna.

Em termos de quantos espaços (ou tabulações) constituem recuo, é mais importante ser consistente em todo o código do que usar qualquer valor específico de parada de tabulação.

Guias

Agora, é claro, a consistência importa mais do que qualquer uma delas, e um bom IDE torna as diferenças desprezíveis. Dito isto, o objetivo deste tópico é ser uma guerra santa, portanto:

Eu prefiro tabs:

• Eles são um personagem especificamente destinado a indentação
• Eles permitem que desenvolvedores com preferências diferentes em tamanho de recuo alterem a aparência do código sem alterá-lo (separação de dados e apresentação para a vitória proverbial!)
• É impossível recuar pela metade algo com guias. Portanto, quando você copia o código de um site que usa 3 espaços no arquivo recuado de 4 espaços, não precisa lidar com o desalinhamento.

Use as guias para recuar o início da linha, uma guia por nível de recuo e permitir que todos escolham a largura que desejam.

Use espaços se estiver alinhando caracteres em uma linha, para que eles sempre se alinhem, independentemente do tamanho da guia.

E encontre e dê um soco em todos os primeiros autores de software que deixaram essa coisa estúpida se tornar um problema em primeiro lugar.
(Sério, por que isso é discutido? Em seguida, você me dirá que também deseja usar vários caracteres para quebras de linha!)

Guias

• Para permitir que os erros sejam mais visíveis , é irritante gerenciar micro espaços.
• são consistentes , eles são usados ​​apenas para indentação, a menos que você esteja comentando errado.
• são personalizáveis , você pode especificar nas opções do editor qual a sua largura.
• são mais produtivos , por que digitar 4 espaços quando você pode pressionar 1 guia.
• tome menos tamanho que vários espaços.
• ocupe mais espaço que um espaço.
• leve menos tempo para passar .
• tendem a funcionar melhor nos IDEs.

Os espaços devem ser usados ​​onde as guias são completamente inúteis.

Mesmo para alinhar parâmetros e comentários, as guias ainda funcionam melhor .

Todos os argumentos para abas são ótimos em teoria. Mas...

Em teoria, prática e teoria são iguais. Na prática, eles não são.

Sim, com guias você pode decidir o seu nível de indentação. E sim, você pode usar uma combinação de guias e espaços para alinhar as coisas. E em um mundo ideal seria

Na realidade, você não pode ver a diferença entre espaços e guias, eles sempre parecem confusos ao mover o código, e visualizar o código em outro programa que possui guias com 8 colunas é um incômodo.

Eu costumava usar guias. Então comecei a trabalhar como parte de uma equipe e a compartilhar código. Eu rapidamente me tornei um defensor dos espaços. Portanto, embora eu possa simpatizar com a utopia das guias, não consigo imaginar não usar espaços.

Algumas opiniões relevantes que podem ser interessantes:

• Guido diz espaços
• Joel diz espaços
• Atwood diz espaços
• Zawinski diz espaços, mais ou menos

Guias para a vitória.

Eu absolutamente. ódio. 4. espaços.

Por quê? Principalmente porque estou cansado de navegar no meu código com um teclado e ter que pressionar constantemente left left left leftpara passar por um recuo. Isso nasceu das versões anteriores do Notepad ++ e até do bloco de notas simples do Windows, onde não havia um botão de formatação. Eu tinha tantos problemas quando as pessoas só usavam 3 quando eu usava 4 em qualquer outro lugar, entre outras coisas.

A outra razão é que o caractere de tabulação existe especificamente para indentação e só foi adotado posteriormente para navegação. Por que estamos fazendo space space space spacequando um simples tabfuncionaria? Por que os IDE devem lidar com 2-5 códigos e formatos espaçados corretamente quando uma guia simples e uma opção de preferência funcionariam?

Infelizmente sou minoria.

Pessoalmente, gosto de usar guias em tudo, pois cada desenvolvedor pode controlar a quantidade de indentação por guia. Dessa forma, você obtém flexibilidade na exibição.

Dito isto, eu geralmente imitamos qualquer estilo de codificação que esteja no arquivo para começar (já que passo muito tempo realizando trabalhos de manutenção).

Não acho que exista recuo adequado (pelo menos não sem uma guerra menor).

Pessoalmente, gosto de quatro espaços. Eles me permitem ler código muito mais rápido e têm a mesma aparência em todos os editores - até o Vi.

Espaços, porque quando você alinha comentários à direita do código, listas de parâmetros de funções ou expressões complexas de várias linhas ou coisas dessa natureza, deseja que seu belo trabalho apareça certo para todos . Se você usar guias e permitir que as pessoas definam seus tabstops de maneira diferente, elas quebrarão o alinhamento para todos, exceto os casos mais simples de recuo de código.

Além disso, é óbvio que todos no mundo devem usar o vim, o que torna trivial recuar, desassossegar e navegar por "tab stops", mesmo em arquivos com recuo de espaço.

As guias são a escolha natural e ortodoxa, pois são usadas por definição para indentação.

Infelizmente, as guias são implementadas de maneira desigual, portanto, a única solução do mundo real são 4 espaços.

Você obviamente precisa de uma abordagem combinada.

Se você está compartilhando código com outros desenvolvedores, precisa padronizar e, como isso é impossível (koff koff), você precisa fazer com que todos façam quatro espaços.

Então você precisa de um editor inteligente o suficiente para não ser estúpido quanto a isso, para saber que ele deve tratar uma linha com quatro espaços na frente como se fosse um recuo. Qualquer IDE moderno ou editor de programadores pode fazer o fluxo automático de código com espaços em vez de guias.

Por que alguém não pode implementar isso:

• código é armazenado em um formato compacto benéfico para o sistema em questão
• como cada desenvolvedor abre o código, ele é formatado exatamente como ele deseja
• quando eles terminarem, de volta ao formato compacto

Todo mundo está feliz, pois todos vêem seu formato 'próprio'

Isso é tão difícil?

Espaços ou guias - o que Atwood realmente diz é escolher uma coisa e ser consistente em seu projeto. O único santo graal da formatação de código é garantir que seja consistente, para que o psicopata que mantém seu código depois de você não se sinta obrigado a remediar a situação permanentemente.

Dito isto, se você estiver trabalhando em Python ou em qualquer outra linguagem em que espaço em branco seja uma construção de programação real, não consigo imaginar usar abas.

Eu sou um tipo de cara de quatro espaços, as abas simplesmente não são consistentes.

Aparentemente, as guias estragam as coisas no Delphi, então eu não as uso no Delphi.

No entanto, faço todo o resto usando o Emacs e sempre uso guias porque minhas guias vão exatamente para onde eu quero.

A resposta é que não pode haver um único caractere de indentação adequado para cada situação. A formatação usando caracteres é inflexível e pode causar conflitos quando estilos diferentes são usados ​​em uma equipe.

O único método para formatar o código de maneira impecável e flexível com diferentes estilos de formatação é fazê-lo virtualmente, ou seja, sem nenhum caractere de recuo. O único editor de código que conheço que suporta isso é o usado no exemplo abaixo:

Para demonstrar a formatação virtual , a captura de tela abaixo é de um editor XSLT * que usa esse método de indentação (também há um pequeno vídeo aqui ). Cada caractere no XSLT foi destacado em amarelo, para fins ilustrativos, para permitir que os únicos caracteres de tabulação ou espaço no conteúdo sejam vistos claramente. O recuo do código é tratado pelo sistema de renderização do editor, ajustando a margem esquerda (que tem um fundo branco).

Os únicos caracteres de espaço à esquerda precedem as linhas Livros , porque esse é o conteúdo literal do texto, não o código; esses caracteres de espaço devem ser preservados.

Com a formatação virtual, você escolhe a largura do recuo para se adequar ao ambiente e ao estilo do recuo sem afetar nenhum caractere no arquivo de origem. Você pode até definir a largura do recuo como 0, se precisar de uma visualização nivelada do código, como mostrado abaixo:

Para contrastar isso com a formatação de caracteres de espaço, o mesmo XSLT aberto em um editor sem formatação virtual é transformado pelo formatador automático desse editor para:

Os blocos amarelos em branco maiores na captura de tela acima mostram claramente os caracteres de espaço adicionados pelo formatador do editor convencional. Infelizmente, agora eles não podem ser distinguidos do conteúdo real, portanto o XSLT precisaria ser modificado para corrigir esse problema.

Sumário

O XSLT é possivelmente um caso extremo, mas esse princípio é válido para muitas linguagens de programação: Os caracteres devem ser usados ​​para o conteúdo e um método alternativo procurado quando se trata de formatação.

** Divulgação: o XSLT Editor com formatação virtual foi desenvolvido por minha própria empresa *

Não mencionado até agora: existem idiomas (Python, Haskell) em que a indentação é importante. Mas 1 caractere conta como 1 caractere, seja um espaço ou uma guia, portanto, o recuo visto pelo compilador pode não ser o mesmo que você vê na tela se você usar as guias.

Portanto, em idiomas como Haskell, os espaços são obrigatórios. Nos Makefiles, os TABS são obrigatórios. Em todos os outros, é uma questão de gosto pessoal e hoje em dia não muito - todo editor decente tem um comando "(guia) para abas para espaços" e "(guia) para abas".

Eu costumava usar espaços, mas tenho usado guias recentemente porque é para isso que o Eclipse foi definido quando finalmente notei. Todos os outros desenvolvedores da minha equipe usam o Eclipse, por isso fazia sentido padronizar as guias quando percebemos que já as usávamos há muito tempo e não havia motivo para mudar de espaço. Fiquei surpreso com o quanto isso não é problema.

Definir o tamanho da guia exibido como 3 ou 5 caracteres no IDE simplifica bastante a distinção entre as seções de código que são recuadas por espaços (quase sempre 4 atualmente) e aquelas que são recuadas por tabulação.

Muitos argumentos já foram apresentados, mas ninguém mencionou para onde poderíamos ir no futuro .

Abas nem espaços!

Idealmente, o código deve ser considerado dados e não deve ser armazenado em nenhuma formatação de texto específica. Qualquer desenvolvedor pode aplicar sua própria visão preferida. Além disso, essa visualização não deve se limitar apenas ao texto , mas pode incluir tabelas, seletores de cores e fórmulas matemáticas.

Essa idéia não é exagerada. Foi o editor de programação orientada a linguagem do JetBrain, Meta Programming System (MPS), que primeiro me fez perceber que isso resolve toda a discussão, adicionando simultaneamente muitas possibilidades extras. (Sim, isso é possível com plug-ins de editor, mas trabalhar diretamente com texto adiciona muitas complexidades desnecessárias, em oposição à abordagem adotada pelo MPS.)

Ao contrário de tabulações e espaços, há poucas desvantagens que podem ser mencionadas para trabalhar diretamente em árvores de sintaxe abstratas . Tudo o que é necessário é que a tecnologia amadureça e se torne um produto comercialmente viável. Os primeiros sinais disso estão aparecendo. Amplamente construído sobre o MPS, um editor de ações comerciais, Realaxy foi criado.

Eu adoraria ver um dos grandes jogadores pular no conceito dessa tecnologia e ver o que acontece!

Nem é melhor, nem é pior. A única coisa importante é ser consistente.

Se você é um time único, escolha o que quiser pessoalmente. Considere qual é o comportamento padrão do seu editor favorito, mas escolha o que quiser.

Se você estiver em uma equipe, faça o que a equipe faz. Período.

Nos meus vários trabalhos, usei dois espaços, quatro espaços, oito espaços, tabulações, espaços e tabulações, acho que também posso ter usado um espaço. Eu digo ao meu editor o que fazer, então não penso mais nisso, o editor elabora os detalhes.

A única outra coisa é ter certeza de escolher um editor inteligente. Emacs ou vi? Agora que é uma guerra santa, estou disposto a lutar :-)