Tabs contra espaços na programação Python

https://stackoverflow.com/questions/119562

02-07-2019
|

Pergunta

Eu sempre abas usadas para recuo quando eu faço programação Python. Mas, em seguida, me deparei com uma pergunta aqui no SO onde alguém apontou que a maioria dos programadores Python usar espaços em vez de separadores para minimizar os erros editor-a-editor.

Como é que faz a diferença? Há outras razões pelas quais pode-se usar espaços em vez de tabulações para Python? Ou é simplesmente não é verdade?

Devo mudar meu editor para inserir espaços em vez de tabulações imediatamente ou manter em curso como eu costumava fazer?

Solução

PEP-8 nos diz para espaços de uso.

Outras dicas

Cansado de correr atrás erros de recuo (8 espaços? Não, 7 oops 9 ...) eu mudei minhas fontes para 'apenas guias'.

1 guia == 1 nível de avanço, ponto final

O ponto é:. Se você deseja exibir o recuo como 4, 8 ou largura pi / 12 caracteres, basta alterar as configurações em seu editor de texto, não mexer com o código

(Pessoalmente, eu uso 4 de char largura guia ... mas alguns preferem 3 ou 8 espaço, ou até mesmo usar fontes de largura variável.)

Assim falou o Senhor: Tu travessão com quatro espaços. Nem mais nem menos. Quatro será o número de espaços tu travessão, e o número do teu recuo será de quatro. Oito tu não travessão, nem quer travessão tu dois, com exceção de que tu então proceder para quatro. Tabs são para fora da direita -. Georg Brandl

usar um editor que os personagens DISPLAYS TAB (todos os espaços em branco, para que o assunto). Você está programando, não escrever um artigo.

Eu uso guias. Não há espaço para um erro de um espaço nas guias (se você pode vê-los). O problema é que as pessoas usam diferentes editores, e a única coisa comum no mundo é: guia == travessão, como acima. Um cara vem com o conjunto de chaves guia para o número errado de espaços ou fá-lo manualmente e faz uma bagunça. OAT e usar um editor real. (Este não é apenas contrário à PEP, é sobre C / C ++ e outras linguagens de espaço em branco-agnóstico também).

/ desce do palanque

A minha principal razão para usar guias sobre espaços é a tecla de retrocesso. Se eu estou em uma linha e eu quero backspace-remover um recuo em apenas que uma linha que tem que bater backspace 4x se fosse espaços; enquanto, eu só precisa acertar uma vez se é um guia.

Vou continuar a usar guias porque, como foi dito antes, é mais fácil converter de tabulações para espaços, mas não o contrário.

Eu estou pensando que eu quero escrever um programa simples que o código convertidos com espaços em código com abas, porque eu que Freaking o espaços de ódio. Eles me levar até a parede!

Oh! E usando as setas do teclado para navegar esquerda e direita é sempre uma dor na bunda quando é espaços.

UPDATE: Sublime Texto 3 agora exclui um soft tab completa com a tecla de retrocesso; embora, seta-tecla de navegação ainda é tedioso.

UPDATE: Eu agora uso vscode e também escreveu um TabSanity extensão para ele para resolver backspace, apagar e flecha-tecla de navegação.

A maneira mais "pythônico" é usar 4 espaços por nível de recuo. O interpretador vai no entanto reconhecer espaços ou abas. A única gottcha é você não deve misturar espaços e guias , escolher um ou outro. Dito isto, a especificação recomenda espaços, a maioria dos desenvolvedores usar espaços, a menos que você tem uma boa razão para não, eu diria que ir com espaços.

Tanto quanto eu posso dizer, aqui estão os prós e contras de guias vs espaços.

Pros de guias:

keystrokes Menos necessário para travessão, unindent, e atravessar o recuo. (Mesmo que o seu IDE tem alguma esperteza espaço-recuo, nunca será tão bom como guias.)

Diferentes programadores podem usar diferentes tamanhos de tela guia como quiserem.

Você pode nunca ter o cursor "dentro" um caráter recuo. Por exemplo, dizer que você está copiando algumas linhas, com abas que você pode clicar vagamente perto do início de uma linha para iniciar a sua seleção e você terá toda a primeira guia. Com espaços é provável que você perca o primeiro caractere de espaço, a menos que você bateu o pequeno-alvo entre ele e a margem. Da mesma forma para remover um recuo de uma linha, a maioria dos editores não lidar com pressionando backspace bem se o seu cursor estiver no meio de um personagem recuo de quatro espaço. Em geral, ele irá remover um espaço. Com abas funciona como esperado.

Coerência com outras línguas, para que você não tem que definir o seu editor até o uso, por exemplo, guias para C ++ / Java e espaços para Python.

recortes errada pode ser mais óbvia (ou seja, uma guia extra é muito maior do que um espaço extra).

contras de guias:

A maioria dos programadores Python usar espaços para que você estaria indo contra a convenção.

Usando espaços para alinhar declarações multi-line é mais fácil do que usando guias. Você poderia Usar guias-de-recuo, espaços-para-alinhamento, mas parece um pouco arriscado em Python!

Há alguns não-questões que são exagerados por algumas pessoas:

Você pode ter espaços dispersos em recuo com abas que os parafusos as coisas: Praticamente todos os IDEs / editores suportam a visualização de espaços em branco, e é quase tão provável que você vai ter abas perdidas em recortes espaciais! Eu não posso ver este ser um qualquer maneira erro comum. Além disso, mais erros de recuo será pego de Python, e boas IDEs deve ser capaz de destacar diferentes recortes.

Você pode coisas se alinham facilmente com guias: Isso é verdade se você estiver indo para o alinhamento personagem-perfeito, mas PEP-8 recomenda contra isso, e Python não jogar bem com as declarações de várias linhas de qualquer maneira.

As pessoas têm configurações de diferença para o tamanho de exibição da guia em seus editores para que o seu código será diferente em diferentes lugares:. Sim, isso é realmente uma característica benéfica de guias

Eu comecei a usar espaços para ser consistente com outro código Python, mas para ser honesto, é bastante frustrante que eu provavelmente vai mudar de volta para guias. Depende muito das capacidades do seu IDE, mas na minha experiência nenhuma quantidade de suporte IDE para recuo espaço é tão bom como apenas usando guias.

Então, se você realmente não gostam de ser inconsistente com a maioria (presumivelmente não todos!) De código, guias usar Python e ligue visualização espaços em branco e recuo destacando (se acessível). A maior razão para me é a facilidade de selecção ea redução (bastante significativo IMO) em teclas. Algumas convenções são estúpidos.

Atualização : Eu descobri que há um editor em todo o mundo (excluindo disparates como Vim) que suporta adequadamente espaços como recuo: Atom. Ele tem uma opção chamada "tabstops atômicas", que faz 4 espaços comportam-se como se fosse um guia em todos os aspectos (exceto ser capaz de redimensioná-la). Infelizmente Atom é um editor muito lento e inchado, mas esta é uma grande característica e se você é forçado a espaços de uso que poderia ser uma boa opção. Esperemos que um dia outros editores vão começar a apoiá-lo. Aqui está o problema para VSCode .

Recentemente, deparei com um artigo intitulado Python: Mitos sobre Indentation que discute este e outras questões relacionadas. O artigo tem boas razões para recomendar o uso de espaços Ao escrever código Python, mas certamente há espaço para discordância.

Eu acredito que é verdade que a maioria dos programadores Python usar somente espaços.

Use um editor que permite que você insira espaços até o tabstop quando você pressiona a tecla TAB, em vez de inserir um personagem \ t. E depois esquecê-la.

Você pode misturar tabulações e espaços ... mas um guia é considerado o mesmo recuo de 8 espaços, a menos que seu editor está configurado para considerar uma guia para ser de 8 espaços que você está pedindo para ter problemas quando misturá-los .

A única experiência inconveniência I com o uso de espaços em vez de separadores é que você não pode facilmente remover um nível de recuo; você tem que remover quatro espaços em vez de apenas um guia.

regra Tabs. Mesmo argumento para loops aninhados e você quiser trazer o loop externo "back" 1 nível. Dica: Se você quiser converter o código python espaço crivado de idade em abas usar o utilitário TabOut disponível como um executável em http://www.textpad.com/add-ons/ .

Eu me sinto muito fortemente que qualquer que seja a convenção histórico, abas são simplesmente a melhor escolha e deve substituir os espaços em cada linha futuro do código Python escrito. Como chutar para fora um tirano incompetente. Minha razão para isto é: simplicty como um valor fundamental . Use dois ou talvez quatro caracteres para a tarefa semântica de um? Não há nenhuma justificação além da tradição, IMO.

erro editor-to-editor ocorre quando você tem recuo misturado dentro de um arquivo . Isto ocorre como se segue: um bloco de código é recortado com espaços 4, e em seguida um nível de recuo "no", que é recortado com abas. Agora as nações que fez isso (mistura de tabulações e espaços) tiveram tão seus guias também são 4 espaços, por isso ele não vê problemas, e Python não vê problemas.

Agora, a nossa vítima vem depois, e ele tem seus guias definido como 8 espaços. Agora nossas vítimas acha que o código é tudo ripado, e correções it por remover um nível de recuo , que agora torna o código olhar como ele é ainda 2 níveis de recuo, mas é realmente um nível . Neste ponto ele explodir.

A lição aqui é que você deve nunca, nunca, misture tabulações e espaços. Se você mantiver a este, então é fácil de reindent seu código em espaços ou tabulações, independentemente de qual você usa pessoalmente. A melhor maneira de garantir que você não misture tabulações e espaços é sempre correr python com -tt, que irá produzir um erro quando tabulações e espaços são misturados.

Como para tabulações e espaços, eu pessoalmente usar guias de modo recuo separado da aparência - é muito mais fácil de alterar a aparência do código quando ele é recortado com abas do que é com espaços. Eu sei que isto funciona ao contrário do que 99% dos programadores Python fazer, mas essa é a minha pessoal preferência, e é fácil em qualquer caso, para converter um arquivo com guias para um espaçadas. O inverso nem sempre é verdade, pois você pode acidentalmente bater a 4 espaços em cordas, etc.

Quando eu estava começando a aprender Python, fui colocado fora de um pouco com a idéia de espaço em branco significativo, como a maioria das linguagens de usá-lo são inflexíveis. Dito isto, fiquei impressionado com a capacidade do Python para entender uma variedade de estilos de recuo. Ao considerar o estilo a ser usado para um novo projeto, eu acho que é importante manter duas coisas em mente.

Em primeiro lugar, é importante entender como Python interpreta recuo. Bryan Oakley mencionou a possibilidade de off-por-um erro ao usar guias, mas isso realmente não é possível com as configurações de intérprete padrão. Há uma explicação melhor para isso em Aprender Python , de O'Reilly mídia .

Basicamente, há uma variável (que pode ser alterado através da inclusão de um comentário no topo de um arquivo de origem # tab-width:) que define a largura da tabulação. Quando Python encontra um guia, que aumenta a distância recuo para o próximo múltiplo de guia de largura . Assim, se um espaço seguido por um guia é introduzido ao longo da esquerda do arquivo, o próximo múltiplo de guia de largura é de 8. Se um guia por si só é inserido, a mesma coisa acontece.

Desta forma, é seguro, se o seu editor está configurado corretamente, usar guias, e até mesmo para misturar tabulações e espaços. Contanto que você definir guia do seu editor pára para a mesma largura que a declaração tab-width Python (ou 8 se ele está ausente). É geralmente uma má idéia usar um editor com uma largura de guia de diferente de 8 espaços, a menos que você especifique a guia de largura no arquivo.

Em segundo lugar, muito do projeto sintático do Python é incentivar a legibilidade do código e estilo consistente entre programadores no mesmo projeto. Dito isto, a questão torna-se, para qualquer projeto particular, o que vai tornar o código mais legível pelas pessoas que trabalham no projeto . Certamente é uma boa idéia para manter um estilo de recuo consistente, mas, dependendo da plataforma e do editor usado pelo projeto, um estilo diferente pode fazer sentido para diferentes projetos. Se não há razão para não estar de acordo com PEP 8 , então ele faz sentido fazê-lo, porque ele vai estar de acordo com o que as pessoas esperam.

Eu encontrei projetos que utilizam uma mistura de tabulações e espaços com sucesso. Basicamente espaços são utilizados para pequenas seções travessão, se o fato de que ele está em uma seção recuado é relativamente sem importância; enquanto guias são usadas para chamar a atenção do leitor para uma grande característica estrutural. Por exemplo, as aulas começam com um guia, que verificações condicionais simples dentro de um uso função de dois espaços.

Tabs também são úteis quando se lida com grandes blocos de texto recuado vários níveis. Quando você desistir de 3-4 níveis de recuo, é muito mais fácil de alinhar com a guia adequada do que está a alinhar com o número adequado de espaços. Se um projeto não usa o estilo recomendado PEP 8, é provavelmente melhor para escrever um guia de estilo em um arquivo em algum lugar para que o padrão de recuo permanece consistente e outras pessoas podem ler explicitamente como configurar o seu editor para corresponder.

Além disso, Python 2.x tem uma -t opção de emitir avisos sobre tabulações e espaços mistos e -tt para emitir um erro. Isto só aplicada a abas mistos e espaços dentro do mesmo âmbito. Python 3 assume -tt e, tanto quanto eu encontrei, não há nenhuma maneira para desativar essa verificação.

Eu sou essencialmente programador de C ++, mas às vezes meus projetos incluem pequenas quantidades de Python. Eu uso guias para travessão meu código C ++. Isso significa que eu tenho três opções aqui:

Usar guias em C ++ e espaços em Python. Isso permite que os meus arquivos C ++ para permanecer como estão e eu seguir a recomendação PEP-8, mas eu sou inconsistente dentro do meu projeto.

Alterar código meu C ++ para espaços de uso. Isso permite que todos os meus arquivos dentro do meu projeto para ser consistente, e eu seguir a recomendação PEP-8, mas me obriga a voltar atrás e mudar todos os meus arquivos C ++. Eu considero isso uma coisa ruim porque eu prefiro guias.

Usar guias no meu código C ++ e código Python. Isso faz com que todo o meu projeto consistente e me permite usar o meu estilo de recuo preferido: guias. A desvantagem é que não estou seguindo o padrão PEP-8.

Para os meus projetos, eu geralmente ir com a opção 3.

PEP-8 tanto concluir claramente que a mistura espaços e TABs deve ser evitado. Se você quiser misturar a eles que você tem que visualizar espaços em branco no IDE - mas então você perde a vantagem de fazer o recuo do Python escopos facilmente visível. Visualizar espaços em branco em um tumultua IDE visor.

Se é ou OAT ou espaços, então deve ser espaços para uma razão simples: Um pode mudar quase todos os IDEs e editores de texto para substituir automaticamente guias com espaços, mas o contrário não é verdadeiro.

Embora existam IDEs que podem ser convertidos automaticamente espaços principais numa linha de abas, isso vai levar a que tem uma mistura de abas e espaços. Considere múltiplas declarações de linha, tais como chamadas de função com lotes de parâmetros ou doc ??strings. Enquanto "ascii-art" também deve ser evitado isso pode facilmente acontecer por acaso que um único espaço que sobra após os guias principais.

Outras respostas trouxe vários argumentos a favor de guias:

Bater TAB é mais eficiente. Claro que isto é verdade, mas todos os editores de texto permitem imediatamente inserir o número de espaços queria quando uma tecla TAB é pressionada

recuo / Dedenting é mais fácil quando apenas ter que remover uma página em vez de 2/3/4/8 espaços. É verdade, mas a maioria dos editores de texto permitem fazer isso automaticamente de qualquer maneira: Bloco selecionar, travessão / dedent são as funcionalidades básicas de um editor de programação, como comentar / descomentar. Se um editor de texto não tem esta implementado, ele deve ter pelo menos um fácil de usar a funcionalidade de macro com que se pode conseguir a mesma coisa.

Diferentes programadores como diferentes larguras recuo. Isso é verdade, e uma clara vantagem de usar apenas TABs. O problema é a interação com outros indivíduos e / ou equipes. Para que isso funcione no mundo real, todo mundo teria que concordar em apenas todos os TABs usando. Uma vez que este não aconteceu, ele não funciona de qualquer maneira. Em um cenário do mundo real há um conjunto de diretrizes de codificação que um projeto concorda em cima de qualquer maneira, e o método de recuo é certamente um deles - mesmo em outras linguagens de programação, onde as implicações são "apenas" em um nível visual
.

IMHO, o principal ponto que a maioria (se não todos) respostas estão faltando aqui é a interação entre equipes ou indivíduos, especialmente em cenários onde a lista de participantes não é saber no início. Quando o código atende código ou todos tem que usar guias ou todos tem que usar espaços. Ele não pode ser misturado sem finalmente correr em problemas de funcionalidade. As pessoas não são perfeitas. Ferramentas não são perfeitos. É por isso que imho não devemos usar TABs em tudo.

Sem resposta é completa sem o link que Greg fornecido na sua resposta já : Python: Mitos sobre Indentation

Todo mundo tem diferentes preferências sobre a quantidade de código deve ser recuado. Vamos dizer que você compartilhar código com alguém e ele ou ela tem diferentes preferências em relação recuo. Se os recortes estão em abas, o seu amigo pode sempre alterar a largura guia em suas configurações do editor. No entanto, se os recortes estão em espaços, o seu amigo realmente tem que mudar o código fonte, se ele ou ela deseja configurá-lo com sua preferência. Então, quando você começa alterações do seu amigo, você pode decidir alterá-lo de volta para sua preferência. Neste caso, você terá que lidar com o tédio de alteração dos níveis de recuo frente e para trás, ou uma pessoa deve adotar as outras preferências das em nível de recuo. Se você e seu uso amigo abas, o fato de que você tem preferências diferentes é um não-problema, como você pode ver cada diferentes níveis de recuo enquanto o código permanece inalterado. É por isso que, na minha opinião, as guias são melhores do que espaços de recuo em todas as linguagens de programação.

Há um cenário em que as abas simplesmente não funcionam, a saber: dependendo do estilo de codificação que você está usando, você pode precisar recuar algumas linhas de código para a precisão de um espaço, ou seja:

def foobar(): x = some_call(arg1, arg2)

Nesse caso, utilizando puramente guias não irá funcionar em todos; usando guias para travessão principal e espaços para a sub-travessão vai funcionar, mas vai violar a regra dura de não misturar os dois.

Este não será o caso, no entanto quando se utiliza um estilo de codificação / Convenções do documento, que evita situações como no exemplo de código acima.

O problema com o uso de espaços em vez de separadores é o tamanho do arquivo torna-se tão incrivelmente grande ... Por exemplo, um arquivo de espaço-recuado 500 KB poderia ser reduzido para 200 KB ao trocar espaços para guias que é por isso que eu sempre usar abas .

menor significa arquivo de tamanho mais rápido carregamento, compilação, execução (em alguns casos), etc.

Para mim, não há nenhum ponto de usar espaços, mas se alguém usa um editor que tem problemas com abas, então eles podem substituir "\ t" com "" ou "" ou o que quer ...

Além de todos os argumentos já listados, eu encontrar um presente bastante importante (de Mitos sobre recuo ):

Além disso, guias muitas vezes são destruídas ou mal convertido durante copiar e colar as operações, ou quando um pedaço de código-fonte é inserido em uma página web ou outro tipo de código de marcação.

Outro argumento (específico ambiente fortemente, embora) contra abas é que eles são às vezes falta em teclados de telefone . Este provavelmente poderia ser remediado através da instalação de um teclado alternativo, sempre que possível.

Um argumento guias que ninguém parecia ter mencionado ainda é que um guia é de 1 caractere (0x09, 1 byte no arquivo), enquanto 4 espaços são 4 caracteres (4 vezes 0x20, 4 bytes no arquivo); Assim, usando espaços resulta em desperdício de 4x de espaço.

Para concluir esta lista incoerente de argumentos, eu gostaria de citar Tim Peters resposta nos Edição 7012: Tabs é melhor do que espaços de recuo :

O Python "espaços apenas" padrão é para código distribuída. Anos de experiência inicial nos ensinou além da dúvida que tabs causou problemas intermináveis ??para compartilhada código (...)

Como é que faz a diferença?

Alguns editores são configurados por padrão para substituir um único caractere de tabulação com um determinado número de caracteres de espaço, mas alguns não são. Se espaços todo mundo usa, esta diferença de configurações do editor padrão pode ser ignorado.

Existem outras razões pelas quais pode-se usar espaços em vez de tabulações para Python? Ou é simplesmente não é verdade?

Sim, há outras razões válidas como apontado por muitas respostas antes de mim. "PEP-8" diz isso, no entanto, não é uma dessas razões. Isto vem da auto perpetuar o mito de que PEP-8 é o padrão de codificação para todas código Python, quando na verdade é apenas o padrão de codificação para o conjunto padrão de bibliotecas Python. Alguns afirmam que PEP-8 é amplamente aceito, e alguns afirmam que a maioria dos programadores Python usar espaços em vez de separadores. Gostaria de pedir provas dessas alegações, como o número de votos neste site mostra claramente que as abas são preferidos pelas massas. Acho que é bastante lamentável que você aceitou "PEP8 diz assim" como a resposta à sua pergunta, quando, na verdade, existem muitas outras respostas que realmente explica as vantagens e desvantagens relativas de espaços e tabulações.

Devo mudar meu editor para inserir espaços em vez de tabulações imediatamente ou manter em curso como eu costumava fazer?

Depende, e a resposta a esta última pergunta é onde eu pensei que eu poderia realmente adicionar algum valor para esta discussão. IMHO, independentemente do idioma a ser utilizado, o padrão melhor codificação para utilização depende da situação que você está em:

Se você começou a trabalhar em uma base de código já existente: não ser difícil, seguir o padrão de codificação existente

Se uma equipe está começando em um novo projeto a partir do zero: discutir, decidir sobre um padrão de codificação no início como uma equipe, e cumpri-lo

Se você está indo só: fazer o que faz você se sentir mais feliz e mais produtiva

Então, qual situação você se enquadram?

Finalmente, para fazer a minha decisão clara, para os meus próprios projetos solo, eu uso guias porque guias fazer mais sentido para mim, e eu sou mais produtivo com guias.

Eu acredito que há uma solução para ter os dois:

Compatibilidade com PEP-8 e usando espaços

conveniência de usar guia em vez de 4 espaços

Em Notepad ++, vá em "Preferências" -> "Configurações da guia" e escolha "Python" na lista à direita. Em seguida, certifique-se "tamanho da guia: 4", e marque a caixa "substituir [guia] pelo espaço". Neste caso, você pode simplesmente usar a tecla Tab para recuar, mas Notepad ++ realmente transformá-lo para 4 vagas para você.

Esta é PEP 8 a partir de julho de 2017:

Parece que esta declaração não deixa espaço para qualquer outra escolha.

Mas este não é apenas o PEP 8 nos diz, algumas linhas depois:

No exemplo acima, a primeira declaração expressa um preferência para espaços, e a segunda declaração reconhece a existência de código recuado com guias e essa preferência para alguns programadores.

Então : PEP 8 é guia recuo tolerante. Não guia e espaço misturado para recuo tolerar, porém, que, desde o recuo em si é obrigatório, é compreensível.

Pode valer a pena mencionar que Python estilo de codificação do Google também segue a regra 4-espaço.

Existem outras vários argumentos e justificativas em favor de qualquer guias ou 4-espaço.

Se você trabalha em uma empresa que impor PEP 8, ou regularmente compartilhar seu código com outros que seguem PEP 8, então o senso comum manda 4-espaço. Sou (era, talvez) utilizado para as guias de C / C ++. Mas com um IDE corretamente set, a diferença torna-se mínima.

Use espaços no lugar de guias, para a única razão que você vai ganhar mais dinheiro:)

Ref .: desenvolvedores que usam os espaços fazem mais dinheiro do que aqueles Usar guias Who (blog pós Stack Overflow).

Então aqui estou lendo todas as respostas e se perguntando como posso cumprir PEP-8 sem o incómodo de batendo meu botão backspace repetidamente apenas para remover o recuo, e eu olho para o meu teclado para jogos Logitech com todas as macro sua fantasia botões e uma lâmpada se acende na minha cabeça.

Eu abri software da Logitech, definido um par de macros para os botões ao lado do botão guia, e que o problema está resolvido.

Um botão adiciona quatro espaços, e o outro faz backspace quatro vezes. Surpreendente. Simplesmente incrível. Tão fácil de apertar os botões com meu mindinho, também.

Veja, veja isso:" "<- quatro espaços! Com um toque de um botão! Se eu pudesse mostrar-lhe as backspaces eu faria isso também. Vai ter um teclado Logitech G105 e todos os seus problemas vão embora!

Eu estou apenas começando mas acho que é muito mais fácil de usar guias de espaços, e não entendem o PEP-8 advocation de apenas espaços. Sublime Text 2 faz um ótimo trabalho de visualizar abas com a linha vertical, pontilhada off-white e, embora existam casos de me misturar um espaço ou dois para alinhar elementos de uma lista ou dicionário, eu não experimentou uma situação em que ser coisa prejudicial.

Eu amo guias mas é de algum modo incompatível com outra regra que eu gosto:. O limite de 80 colunas

Se se escolhe 4 espaços abas e das inserções 10 separadores, em seguida, há espaço deixado por 40 caracteres para satisfazer o limite de 80 coluna. Se outro codificador prefere 8 espaços separadores, na mesma linha aparecerá como 120 caracteres e não aparecerá como um válido linha 80 colunas!

Se você quiser definir um limite de 80 colunas, então você tem que escolher um comprimento de uma guia. Neste caso ter espaços x ou uma guia de comprimento x realmente não fazer a diferença.

Editar: rosca relacionada: Manter Linha Comprimento máximo ao usar guias em vez de espaços?

Eu acho que uma das principais vantagens de usar espaços é que você remova variabilidade na forma como o seu código-fonte é processado através da multiplicidade de ferramentas externas que têm de interagir com a fonte além de seu editor de escolha e configurações que eles configurado na.

Como alguns exemplos concretos considerar a prestação de docstrings do Python em uma dica de ferramenta em Visual Código Estúdio , ou em uma ferramenta de comparação como Beyond Compare ou , de desempenho ou de cobertura de código ferramentas WinMerge, etc. Basicamente todas essas várias outras ferramentas de interface cada um pode ter configurações diferentes para como guias são interpretados e pode ser irritante e às vezes desorientador para encontrar coisas muito diferentes ou empurrado maneira fora da tela entre os conjuntos de ferramentas que você pode mergulhar dentro e fora de.

Em poucas palavras você define o alinhamento na fonte em vez de disputas por uma configuração uniforme para o conjunto de ferramentas em seu arsenal. Espaços são estritamente interpretado de uma fonte monoespaçada para dar alinhamento confiável e consistente em toda a extensão completa de ferramentas devido à definição da fonte, não de um terceiro prestação guia de implementação / configuração.

Um outro ângulo para isso é em copiar fonte principal abas para ser executado em um terminal onde o caracter de tabulação pode desencadear uma conclusão da aba inadvertida. Por exemplo, se você copiar o seguinte fonte Python (tabs usado como recuo),

cmd_create_db = '''CREATE TABLE test ( Col1 INTEGER, Col2 INTEGER, Col3 TEXT)'''

Você pode ver algo como segue (visto no terminal integrado Visual do Código Studio) ...

>>> cmd_create_db = '''CREATE TABLE test ( ... .DS_StoreCol1 INTEGER, ... .DS_StoreCol2 INTEGER, ... .DS_StoreCol3 TEXT)''' >>> cmd_create_db 'CREATE TABLE test (\n.DS_StoreCol1 INTEGER,\n.DS_StoreCol2 INTEGER,\n.DS_StoreCol3 TEXT)'

(Aparte:. Eu tinha se perguntou se esta observação da consistência entre ferramental é uma marca de uma mente discriminar de um desenvolvedor forte procura de ordenar o mundo que pode indicar uma dica para a diferença salarial encontrado na Stack Overflow)

Eu uso dois recuo espaço e um editor (kwrite) que insere espaços em vez de tabulações quando eu bati a tecla Tab.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow