Por que o Python pep-8 recomenda fortemente espaços sobre tabulações para indentação?

Vejo no Stack Overflow e no PEP 8 que a recomendação é usar espaços apenas para indentação em programas Python. Consigo entender a necessidade de um recuo consistente e senti essa dor.

Existe uma razão subjacente para os espaços serem preferidos? Eu teria pensado que as abas eram muito mais fáceis de trabalhar.

A resposta foi dada ali mesmo no PEP [ed: esta passagem foi editada em 2013 ]. Eu cito:

A maneira mais popular de recuar o Python é apenas com espaços.

Que outra razão subjacente você precisa?

Para ser menos franco: considere também o escopo do PEP, conforme declarado no primeiro parágrafo:

Este documento fornece convenções de codificação para o código Python que compreende a biblioteca padrão na distribuição principal do Python.

A intenção é tornar todo o código que está presente na distribuição oficial do python formatado de forma consistente (espero que possamos concordar que isso é universalmente uma Good Thing ™).

Como a decisão entre espaços e guias para um programador individual é a) realmente uma questão de gosto eb) facilmente tratada por meios técnicos (editores, scripts de conversão etc.), existe uma maneira clara de encerrar toda a discussão: escolha uma .

Guido foi quem escolheu. Ele nem precisou dar uma razão, mas ainda o fez referindo-se a dados empíricos.

Para todos os outros propósitos, você pode tomar este PEP como uma recomendação ou pode ignorá-lo - sua escolha, a de sua equipe ou os líderes de sua equipe.

Mas se eu puder lhe dar um conselho: não misture ;-) [ed: Misturar guias e espaços não é mais uma opção.]

Bem, parece que todo mundo está fortemente inclinado para os espaços. Eu uso guias exclusivamente. Eu sei muito bem o porquê.

As guias são na verdade uma invenção interessante, que veio após os espaços. Ele permite que você recue sem pressionar o espaço milhões de vezes ou usando uma guia falsa (que produz espaços).

Eu realmente não entendo por que todo mundo está discriminando o uso de guias. É como os idosos discriminando os mais jovens por escolher uma tecnologia mais nova e eficiente e reclamando que a discagem por pulso funciona em todos os telefones , não apenas nesses novos sofisticados. "A discagem por tom não funciona em todos os telefones, é por isso que está errado".

Seu editor não consegue lidar com as guias corretamente? Bem, pegue um editor moderno . Pode ser que seja o momento, estamos agora no século 21 e o tempo em que um editor era um software complicado de alta tecnologia já passou muito tempo. Agora temos muitos editores para escolher, todos eles compatíveis com guias. Além disso, você pode definir quanto deve ser uma guia, algo que não pode ser feito com espaços. Não consegue ver guias? O que é isso para uma discussão? Bem, você também não pode ver espaços!

Posso ter a ousadia de sugerir um editor melhor? Um desses de alta tecnologia, que foram lançados há cerca de 10 anos, exibem caracteres invisíveis ? (sarcasmo desligado)

Usar espaços causa muito mais trabalho de exclusão e formatação. É por isso que (e todas as outras pessoas que sabem disso e concordam comigo) usam guias para Python.

Misturar separadores e espaços é um argumento de não-não e não há sobre isso. Isso é uma bagunça e nunca pode funcionar.

Pessoalmente, não concordo com os espaços sobre as guias. Para mim, as guias são um caractere / mecanismo de layout do documento, enquanto os espaços são para conteúdo ou delineamento entre comandos no caso de código.

Eu tenho que concordar com os comentários de Jim que as abas não são realmente o problema, são as pessoas e como elas querem misturar abas e espaços.

Dito isto, eu me forcei a usar espaços para o bem da convenção. Valorizo ​​a consistência sobre a preferência pessoal.

O motivo dos espaços é que as guias são opcionais. Os espaços são o denominador comum mais baixo real na pontuação.

Todo editor de texto decente tem um "substituir abas por espaços" e muitas pessoas usam isso. Mas não sempre.

Embora alguns editores de texto possam substituir uma série de espaços por uma guia, isso é realmente raro.

Bottom Line . Você não pode dar errado com espaços. Você pode dar errado com as guias. Portanto, não use guias e reduza o risco de erros.

O problema das guias é que elas são invisíveis e as pessoas nunca podem concordar com a largura das guias. Quando você mistura abas e espaços e define tabstops em algo diferente de Python (que usa tabstops a cada 8 espaços), verá o código em um layout diferente do que o Python vê. E como o layout determina os blocos, você verá uma lógica diferente. Isso leva a erros sutis.

Se você insiste em desafiar o PEP 8 e usar abas - ou pior, misturar abas e espaços - pelo menos sempre execute python com o argumento '-tt', que gera recuo inconsistente (às vezes uma aba, às vezes um espaço para o mesmo recuo) nível) um erro. Além disso, se possível, configure seu editor para exibir guias de maneira diferente. Mas, na verdade, a melhor abordagem é não usar guias, ponto final.

Os principais problemas com o recuo ocorrem quando você mistura abas e espaços. Obviamente, isso não indica qual você deve escolher, mas é uma boa razão para recomendar uma, mesmo que você a escolha jogando uma moeda.

No entanto, IMHO existem algumas razões menores para favorecer espaços em vez de guias:

• Ferramentas diferentes. Às vezes, o código é exibido fora do editor de um programador. Por exemplo. postado em um grupo de notícias ou fórum. Os espaços geralmente se saem melhor do que as guias aqui - em todos os lugares os espaços ficam mutilados, as guias também, mas não vice-versa.

• Os programadores veem a fonte de maneira diferente. Isso é profundamente subjetivo - é o principal benefício das guias ou um motivo para evitá-las, dependendo do lado em que você estiver. No lado positivo, os desenvolvedores podem visualizar a fonte com o recuo preferido, para que um desenvolvedor que prefere o recuo de 2 espaços possa trabalhar com um desenvolvedor de 8 espaços na mesma fonte e ainda assim ver o que quiser. A desvantagem é que há repercussões nisso - algumas pessoas gostam do 8-space porque dá um feedback muito visível de que estão profundamente aninhadas - elas podem ver o código verificado pelo 2-indentador constantemente envolto em seu editor. Fazer com que todos os desenvolvedores vejam o código da mesma maneira leva a mais consistência nos comprimentos das linhas e outros problemas também.

• Recuo de linha continuada. Às vezes, você deseja recuar uma linha para indicar que ela é carregada da anterior. por exemplo.

  def foo():
      x = some_function_with_lots_of_args(foo, bar, baz,
                                          xyzzy, blah)

  Se você estiver usando guias, não há como alinhar isso para pessoas que usam diferentes paradas de tabulação em seu editor sem misturar espaços e guias. Isso efetivamente mata o benefício acima.

Obviamente, porém, essa é uma questão profundamente religiosa, com a qual a programação é atormentada. A questão mais importante é que devemos escolher uma - mesmo que não seja a que você favorece. Às vezes, acho que a maior vantagem de um avanço significativo é que pelo menos somos poupados das guerras de colocação de braçadeiras.

Também vale a pena ler este artigo de Jamie Zawinski sobre o assunto.

Observe que o uso de guias confunde outro aspecto do PEP 8:

Limite todas as linhas a um máximo de 79 caracteres.

Suponhamos, hipoteticamente, que você use uma largura de tabulação 2 e eu use uma largura de 8. Você escreve todo o seu código para que suas linhas mais longas atinjam 79 caracteres, e então começo a trabalhar no seu arquivo. Agora eu tenho um código difícil de ler porque (como afirma o PEP):

O agrupamento padrão na maioria das ferramentas interrompe a estrutura visual do código

Se todos nós usamos 4 espaços, é sempre o mesmo. Qualquer pessoa cujo editor possa suportar uma largura de 80 caracteres pode ler confortavelmente o código.Nota: O limite de 80 caracteres é uma guerra santa por si só, então não vamos começar por aqui.

Qualquer editor que não seja péssimo deve ter a opção de usar espaços como se fossem guias (inserindo e excluindo), para que realmente não deva ser um argumento válido.

A resposta para a pergunta é: O PEP-8 quer fazer uma recomendação e decidiu que, como os espaços são mais populares, ele recomenda fortemente espaços sobre tabulações.

Notas sobre PEP-8

O PEP-8 diz 'Use 4 espaços por nível de indentação'.
É claro que esta é a recomendação padrão.

'Para códigos realmente antigos que você não quer estragar, você pode continuar usando as guias de 8 espaços.'
É claro que existem ALGUMAS circunstâncias em que as guias podem ser usadas.

'Nunca misture abas e espaços.'
Esta é uma proibição clara de mixagem - acho que todos concordamos com isso. O Python pode detectar isso e geralmente engasga. O uso do argumento -tt torna esse erro explícito.

'A maneira mais popular de recuar o Python é apenas com espaços. A segunda maneira mais popular é apenas com guias.
Isto afirma claramente que ambos são usados. Para ser mais claro: você nunca deve misturar espaços e guias no mesmo arquivo.

'Para novos projetos, somente espaços são recomendados em guias.'
Essa é uma recomendação clara e forte, mas não uma proibição de guias.

Não consigo encontrar uma boa resposta para minha própria pergunta no PEP-8. Eu uso guias, que usei historicamente em outros idiomas. Python aceita fonte com uso exclusivo de guias. Isso é bom o suficiente para mim.

Eu pensei em trabalhar com espaços. No meu editor, configurei um tipo de arquivo para usar espaços exclusivamente e, portanto, ele insere 4 espaços se eu pressionar tab. Se eu pressionar tab muitas vezes, tenho que excluir os espaços! Arrgh! Quatro vezes mais exclusões que guias! Meu editor não pode dizer que estou usando 4 espaços para recuos (embora o editor AN possa fazer isso) e obviamente insiste em excluir os espaços, um de cada vez.

Não se poderia dizer ao Python que considerasse as guias como n espaços quando seus recuos de leitura? Se pudéssemos concordar com 4 espaços por recuo e 4 espaços por guia e permitir que o Python aceitasse isso, não haveria problemas.
Devemos encontrar soluções em que todos saem ganhando.

Eu sempre usei guias no meu código. Dito isto, recentemente descobri uma razão para usar espaços: ao desenvolver no meu tablet Internet Nokia N900, agora eu tinha um teclado sem uma tecla tab. Isso me forçou a copiar e colar guias ou reescrever meu código com espaços. Encontrei o mesmo problema com outros telefones. É verdade que esse não é um uso padrão do Python, mas algo a ser lembrado.

A JWZ diz o melhor :

Quando [as pessoas estão] lendo código e quando terminam de escrever um novo código, elas se preocupam com quantas colunas de tela pelas quais o código tende a recuar quando um novo escopo (ou sexpr, ou o que for) é aberto ...

... Minha opinião é que a melhor maneira de resolver os problemas técnicos é exigir que o caractere TAB ASCII # 9 nunca apareça nos arquivos do disco: programe seu editor para expandir as TABs para um número apropriado de espaços antes de gravar as linhas no disco. ..

... Isso pressupõe que você nunca use guias em locais onde elas são realmente significativas, como em constantes de cadeia ou de caracteres, mas eu nunca faço isso: quando importa que é uma guia, eu sempre uso '\ t'.

Como o python depende da indentação para reconhecer a estrutura do programa, é necessária uma maneira clara de identificar a identificação. Esse é o motivo para escolher espaços ou tabulações.

No entanto, o python também tem uma forte filosofia de ter apenas uma maneira de fazer as coisas; portanto, deve haver uma recomendação oficial para uma maneira de fazer o recuo.

Os espaços e as guias representam desafios únicos para um editor manipular como recuo. O tratamento das próprias guias não é uniforme entre os editores ou até mesmo as configurações do usuário. Como os espaços não são configuráveis, eles representam a escolha mais lógica, pois garantem que o resultado terá a mesma aparência em todos os lugares.

A vantagem mais significativa que posso dizer dos espaços sobre as guias é que muitos programadores e projetos usam um número definido de colunas para o código-fonte, e se alguém comete uma alteração com o tabstop definido como 2 espaços e o projeto usa 4 espaços como o ponto de tabulação das linhas longas será muito longo para a janela do editor de outras pessoas. Concordo que as guias são mais fáceis de trabalhar, mas acho que os espaços são mais fáceis de colaboração, o que é importante em um grande projeto de código aberto como o Python.

Você pode ter seu bolo e comê-lo. Defina seu editor para expandir as guias em espaços automaticamente.

(Isso seria :set expandtabno Vim.)

Meu palpite é que a maioria dos editores de texto linux faz com que os padrões pareçam ridiculamente grandes por padrão. Não consigo pensar em outro bom motivo para usar espaços sobre tabulações.

Além de todas as outras razões já nomeadas (consistência, nunca misturando espaços e tabulações etc.), acredito que há mais algumas razões para a convenção de 4 espaços observar. Isso se aplica apenas ao Python (e talvez a outras linguagens em que a indentação tenha significado). As guias podem ser melhores em outros idiomas, dependendo das preferências individuais.

1. Se um editor não mostrar guias (o que acontece, dependendo da configuração, em poucas), outro autor pode assumir que seu código usa 4 espaços, b / c quase todo o código Python disponível ao público; se esse mesmo editor tiver uma largura de tabulação de 4, podem acontecer coisas desagradáveis ​​- pelo menos, essa pessoa pobre perderá tempo com um problema de indentação que seria muito fácil de evitar, mantendo-se na convenção. Então, para mim, a razão número um é evitar erros com consistência.

2. Reformulando a questão de qual é o melhor, abas ou espaços, deve-se perguntar quais são as vantagens das abas; Já vi muitas postagens elogiando guias, mas poucos argumentos convincentes para eles; bons editores como emacs, vi (m), kate, ... fazem recuo adequado, dependendo da semântica do seu código - mesmo sem tabulações; os mesmos editores podem ser facilmente configurados para descontrair no backspace etc.

3. Algumas pessoas têm preferências muito fortes quando se trata de liberdade para decidir a aparência / layout do código; outros valorizam a consistência sobre essa liberdade. O Python reduz drasticamente essa liberdade, ditando que o recuo é usado para blocos, etc. Isso pode ser visto como um bug ou um recurso, mas meio que vem com a escolha do Python. Pessoalmente, gosto dessa consistência - ao começar a codificar em um novo projeto, pelo menos o layout está próximo ao que estou acostumado, por isso é bastante fácil de ler. Quase sempre.

4. Usar espaços para recuo permite "truques de layout" que podem facilitar a compreensão do código; alguns exemplos destes estão listados no PEP8; por exemplo.

   foo = long_function_name(var_one, var_two,
                            var_three, var_four)
   
   # the same for lists
   a_long_list = [1,
                  2,
                  # ...
                  79]
   
   # or dictionaries
   a_dict = {"a_key": "a_value",
             "another_key": "another_value"}

   Obviamente, o que foi dito acima também pode ser escrito bem

   foo = long_function_name(
       var_one, var_two,
       var_three, var_four)
   
   # the same for lists
   a_long_list = [
       1,
       2,
       # ...
       79]
   
   # or dictionaries
   a_dict = {
       "a_key": "a_value",
       "another_key": "another_value"}

   No entanto, o último exige mais linhas de código e, por vezes, menos linhas são consideradas melhores (porque você obtém mais em uma única tela). Mas se você gosta de alinhamento, os espaços (de preferência assistidos por um bom editor) oferecem, em certo sentido, mais liberdade no Python do que as guias. [Bem, acho que alguns editores permitem que você faça o mesmo com guias;) - mas com espaços, todos eles fazem ...]

5. Voltando ao mesmo argumento que todo mundo faz - o PEP 8 determina (ok, recomenda fortemente) os espaços. Se estiver vindo para um projeto que usa apenas guias, é claro, você tem poucas opções. Porém, devido ao estabelecimento das convenções do PEP 8, quase todos os programadores de Python estão acostumados a esse estilo. Isso torna muito mais fácil encontrar um consenso sobre um estilo aceito pela maioria dos programadores ... e fazer com que as pessoas concordem com o estilo pode ser muito difícil.

6. As ferramentas que ajudam a reforçar o estilo geralmente estão cientes do PEP 8 sem esforço extra. Essa não é uma ótima razão, mas é bom ter as coisas funcionando prontas.

O problema universal das guias é que elas podem ser representadas de maneira diferente em um ambiente diferente.
Em um determinado editor, uma guia pode ter 8 espaços ou 2.
Em alguns editores, você pode controlar isso, enquanto em outros não.

Outro problema com as guias é como elas são representadas na saída impressa. Acredito que a maioria das impressoras interpreta uma guia como 8 espaços.

Com espaços, não há dúvida. Tudo vai alinhar como o autor pretendia.

Sobre a discussão entre Jim e Thomas Wouters nos comentários.

O problema era ... como a largura das guias e os espaços podem variar - e como os programadores não podem concordar com as duas larguras - por que as guias são responsáveis?

Eu concordo com Jim nisso - as abas NÃO são más por si mesmas. Mas há um problema...

Com espaços, posso controlar como "MEU PRÓPRIO CÓDIGO" fica em TODOS os editores do mundo. Se eu usar 4 espaços - não importa em que editor você abrir meu código, ele terá a mesma distância da margem esquerda. Com as guias, estou à mercê da configuração de largura da guia para o editor - mesmo para MEU PRÓPRIO CÓDIGO. E eu não gosto disso.

Portanto, embora seja verdade que mesmo os espaços não podem garantir consistência - eles pelo menos oferecem mais controle sobre a aparência do seu código OWN em qualquer lugar - algo que as guias não podem.

Eu acho que NÃO é a consistência nos programadores que escrevem o código - mas a consistência nos editores que mostram esse código - que os espaços facilitam o alcance (e a imposição).