Definitelytyped: Tabs x espaços?

Não há batalha. Use guias.

Eu voto espaços!

Deixe o conflito interno começar! :sorriso:

haha. nós não precisamos disso. Mas você sabe ... não estaríamos tendo essa conversa se estivéssemos usando tabs e cada desenvolvedor ainda teria seu código perfeitamente alinhado da maneira que ele deseja (2 ou 4 espaços). Apenas dizendo.

Eu gosto da guia.
mas acho que devemos aderir às configurações padrão do VisualStudio.

Espaços com tamanho de recuo de 4 (padrões do VS).
Configure seu IDE para fazer guias virtuais para você e para todos felizes.
Só não gosto de ver [tab] [tab] [espaço] [espaço] [espaço] para o código que deseja alinhar com uma palavra na linha acima.

Se alguém quiser escrever uma regra TSLint para impor um estilo consistente (por exemplo: tabulações ou 4 espaços, mas não ambos), então o executaríamos em um novo testador (ele tem suporte para TSLint).

Veja também https://github.com/palantir/tslint/issues/122

Spaces! As bibliotecas FWIW JS usam espaços (angular / jquery)

Isso provavelmente aconteceu por causa de Crockford: http://javascript.crockford.com/code.html

A unidade de indentação é de quatro espaços. O uso de tabs deve ser evitado porque (no momento da redação deste artigo, no século 21) ainda não havia um padrão para a colocação de tabs. O uso de espaços pode produzir um tamanho de arquivo maior, mas o tamanho não é significativo nas redes locais e a diferença é eliminada pela minimização.

Como TS é JS, realmente devemos nos conformar.

Bem, Crockford é um cara meio rabugento, então eu o encaro com cautela.

Houve uma estatística no Reddit um tempo atrás, onde alguém analisou um pedaço decente do Github e era como 60% / 40% a favor dos espaços. Eu e todos os lugares em que trabalhei até agora eram guias (embora grande parte disso fosse AS3). Funciona perfeitamente bem. O alinhamento de código é uma perda de tempo, mas se necessário, as guias inteligentes também funcionam bem.

A verdadeira maldição da qual quero me livrar são os _indents_ mistos. Antes de irmos termonucleares em um ou outro durante todo o repo, pelo menos deve ser consistente _por arquivo_.

Em algum ponto, faremos o # 2228, mas isso é um grande passo (atrapalha várias atribuições para que possamos deixar @ dt-bot fazer isso).

Bem, Crockford é um cara meio rabugento, então eu o encaro com cautela.

concordou

Se você ficar entediado, aconselho a leitura das solicitações pull feitas para JSON.js. invariavelmente, eles são submetidos por pessoas que não conhecem os modos um pouco excêntricos de Doug. Todos são recusados ​​à queima-roupa :-)

Acabei de ver isso: https://github.com/iplabs/typescript/blob/languageService-v2/src/services/languageService.ts#L199 -L213 os padrões são 4 espaços com tabulações convertidas em espaços

    export class EditorOptions {
        public IndentSize: number = 4;
        public TabSize: number = 4;
        public NewLineCharacter: string = "\r\n";
        public ConvertTabsToSpaces: boolean = true;

        public static clone(objectToClone: EditorOptions): EditorOptions {
            var editorOptions = new EditorOptions();
            editorOptions.IndentSize = objectToClone.IndentSize;
            editorOptions.TabSize = objectToClone.TabSize;
            editorOptions.NewLineCharacter = objectToClone.NewLineCharacter;
            editorOptions.ConvertTabsToSpaces = objectToClone.ConvertTabsToSpaces;
            return editorOptions;
        }
    }

Que satisfação @basarat!

Os CRLFs são um pouco estúpidos, mas tanto faz.

Talvez devêssemos ir em frente. Vou tentar executar o formatador de typescript em tudo e ver o que acontece.

Caro senhor, que matadouro .. 562 arquivos .d.ts no total, com 446 arquivos alterados ..

https://github.com/Bartvds/DefinitelyTyped/tree/34907936bfc22562f30bb09ee82282ca0515b8b3

https://github.com/Bartvds/DefinitelyTyped/commit/34907936bfc22562f30bb09ee82282ca0515b8b3

Não foi possível exibir a diferença inteira porque muitos arquivos (446) foram alterados

Heh.

E fiz os testes também:

https://github.com/Bartvds/DefinitelyTyped/tree/46f9d17b2b074c887bff35b06112070b28924248

https://github.com/Bartvds/DefinitelyTyped/commit/46f9d17b2b074c887bff35b06112070b28924248

Não foi possível exibir a diferença inteira porque muitos arquivos (442) foram alterados.

Agradável. Portanto, temos a tecnologia, essa foi a parte fácil. Mas agora precisamos decidir se isso é algo que queremos porque terá um impacto sério.

Por uma linha, a atribuição vai para o inferno. E se aceitarmos isso, provavelmente devemos aplicar a formatação no testador. Eu tenho o TSLint configurado no testador (mas está desabilitado), então isso pode fazer muito.

Talvez devêssemos melhorar o testador para um utilitário CLI que pode executar o formatador e executar os testes, de uma maneira agradável (ele meio que funciona agora localmente, mas deve ser melhorado com a API CLI limpa, etc).

Eu digo que quanto mais cedo melhor. Mas a boa notícia é que você não perderá o histórico de culpas . Eu gostaria que o GitHub também tivesse implementado esse recurso em sua visualização de diferenças.

Sim, mas é uma pena que git blame -w -M não funcione online. Acabei de enviar um e-mail para o suporte do Github sobre isso.

@Bartvds , alguma resposta do GitHub ?!

Ignorar espaços em branco na visualização de culpa do GitHub não é possível atualmente, mas podemos adicioná-lo no futuro. Obrigado pela sugestão, vou adicioná-la à Lista de Solicitações de Recursos para que a equipe possa vê-la.

Portanto, pode demorar um pouco, se nunca.

Eu não me importo com o que qualquer um dos supostos sabe-tudo ou guias de estilo digam - as guias para indentação são a única maneira de preservar a intenção do desenvolvedor quando o alinhamento está envolvido. Veja minha postagem no blog sobre isso .

o conceito de alinhamento de código (alinhar em var e = no seu caso) é bom. Mas difícil de manter em refatorações. Então, eu simplesmente não o uso. Além disso, as ferramentas de formatação automática não o respeitam, por exemplo , o código de formatação automática no TypeScript

Também para

  public string FirstName { get; set; }        =>  public  string  FirstName { get; set; }    
  public string Surname { get; set; }          =>  public  string  Surname   { get; set; }
  public int Age { get; private set; }         =>  public  int     Age       { get; private set; }
  private Address Address { get;  set; }       =>  private Address Address   { get; set; } 

Adicione uma nova propriedade e você precisará _reformatar_ todas essas linhas. Não é uma boa mudança de código para revisar.

Seu fluxo de trabalho pode ser diferente e permitir isso. Isso torna muito mais fácil de ler (codificar como arte), mas não consegui ver as equipes mudando-o.

É a coisa mais estranha. Minha reação instintiva à ideia de misturar tabulações e espaços é tremer e pensar "isso é simplesmente imundo!"

Completamente irracional, eu sei - mas totalmente sincero. Humanos são estranhos ...

@johnnyreilly, você é vítima de um equívoco comum . Usar tabulações para recuo e espaços para alinhamento NÃO é a mesma coisa que _misturar_ tabulações com espaços. Você claramente não leu a postagem do blog.

Usar guias para alinhamento é o motivo pelo qual tantas guias foram desativadas, porque as pessoas estavam fazendo isso errado. Se eles estivessem fazendo isso corretamente em primeiro lugar, ninguém teria notado quando eles mudaram a preferência do editor para exibir a largura da guia em um tamanho diferente. Isso é o que o gif animado acima está tentando demonstrar, como as pessoas estão fazendo isso de maneira errada.

@basarat , concordo totalmente com você. Raramente trabalho em projetos com alinhamento de código, mas vejo isso de vez em quando. Se você pudesse de alguma forma impor que os desenvolvedores em seu projeto não usem alinhamento, então eu diria que vá em frente. Caso contrário, com espaços para indentação, não há como as ferramentas de linting, entre outras, distinguir entre o que foi planejado para indentação e o que foi planejado para alinhamento, fora de analisar o código em CST (overkill de caminho).

Claro, há uma série de outras razões para não usar espaços para indentação nesta era moderna. Os editores lidam bem com guias, mas nunca com espaços. Navegação com as teclas de seta, deletar, backspace - eles simplesmente não tratam um recuo de espaços como uma unidade. Usei Visual Studio, Sublime, PHPStorm e Notepad ++, mas todos eles têm esse problema fundamental com espaços para indentação.

Navegação com as teclas de seta, deletar, backspace - eles simplesmente não tratam um recuo de espaços como uma unidade.

Navegação: eu uso as teclas ctrl + setas. Eles saltam espaços (todos os espaços em branco, na verdade) + palavras.

Para excluir / retroceder: Para seleção de palavras, uso expandir palavra (ctrl + w dos padrões de redefinição) e não expandir seleção (ctrl + shift + w). Raramente preciso selecionar o espaço em branco _inside_, apenas use tab (aumentar indentação) e shift tab (diminuir indentação).

@jedmao na verdade eu entendi seu ponto - eu estava apenas compartilhando minha reação instintiva (e irracional). Eu não disse que fazia sentido: sorria:

@johnnyreilly gotcha.

@basarat Eu uso as Home e End em alguns de seus cenários de espaço em branco. Tentei usar a navegação Ctrl + arrow key mas nem sempre funciona. É por isso que raramente o uso por causa da consistência mental. Considere o seguinte exemplo:

for (var i = 0; i < 10; i++) {
    if (i > 5) {
        console.log('I am greater than 5');
    }
}

Digamos que meu cursor esteja no início da linha 3 e eu queira navegar até o início da linha 2.

Usando sua técnica no Sublime, eu poderia fazer de duas maneiras:

• Up , Hold Ctrl , Left , Release Ctrl (4 etapas lógicas)
• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Left , Release Ctrl (8 etapas lógicas)

No Visual Studio, o segundo cenário pode ser reduzido a 7 etapas lógicas.

• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Release Ctrl (7 etapas lógicas)

Com caracteres de tabulação reais, o caminho mais curto é de apenas 2 etapas lógicas sem teclas modificadoras. Não poderia ser mais simples.

• Left , Up

Não consigo ver como a seleção de palavras ajudaria a excluir ou retroceder um recuo espaçado. Estou tentando no Visual Studio sem sucesso. É por isso que criei o Plugin TabSanity para Visual Studio . Infelizmente, não tenho conhecimento de tais plugins para outros editores.

Com caracteres de tabulação reais, são sempre 2 etapas lógicas sem teclas modificadoras. Não poderia ser mais simples

: +1: Vejo sua vantagem. No entanto, conforme eu edito este comentário, ctrl etc funciona da mesma forma que meu VS, então meus hábitos se mantêm;)

Não consigo ver como a seleção de palavras ajudaria a excluir ou retroceder um recuo espaçado

Minha má, minha descrição foi confusa. Ignore o bit de seleção de "palavra". Concentre-se apenas em I rarely need to select inside whitespace though, just use tab (increase indent) and shift tab (decrease indent). Funciona perfeitamente com recuos espaçados.

Com caracteres de tabulação reais, são sempre 2 etapas lógicas sem teclas modificadoras.

A respeito :

public  string  FirstName { get; set; }    
public  string  Surname   { get; set; }
public  int     Age       { get; private set; }
private Address Address   { get; set; } 

Ir do início de Age para alterar o tipo de Surname ou seja, o string na linha anterior não seria o mesmo que o cenário Ctrl ?

@basarat eu uso Tab e Shift+Tab religiosamente; entretanto, geralmente para várias linhas de código. Eu acho que você poderia dizer que Shift+Tab é um bom apelido para um pressionamento de tecla backspace em uma guia, mas claramente não é tão simples ou intuitivo quanto backspace .

Ctrl+Delete seria o apelido mais próximo da chave Delete , mas tem o potencial de excluir mais de um recuo; ao passo que uma simples tecla Delete em uma guia remove apenas um recuo. Trabalhar às vezes e não outras é porque eu não uso de todo (consistência mental).

Eu, como você, também raramente, ou nunca, preciso selecionar dentro dos espaços em branco. Nunca sugeri que faria. Não estou selecionando o espaço em branco, mas navegando por ele para chegar a algum lugar. Seu exemplo de alinhamento acima é definitivamente quando eu usaria Ctrl + arrow key navegação. É por isso que, como eu disse antes, raramente uso a navegação Ctrl + arrow key porque o cenário que você apontou é provavelmente o único caso em que eu a usaria.

No final das contas, o que mais me incomoda é que você tem que mudar totalmente a sua memória muscular ao alternar entre um arquivo com abas para indentação vs. espaços para indentação. O que é eficiente (menos etapas lógicas) em um arquivo com tabulações para recuo simplesmente não funciona em um arquivo com espaços para recuo. Você poderia culpar os editores por não oferecerem uma experiência perfeita, mas isso não é justo porque é literalmente impossível (sem o CST) que os editores façam suposições em um arquivo com espaços para indentação sobre o que é um recuo e o que é alinhamento.

O que é ainda mais frustrante é que é muito difícil para as pessoas reconhecê-lo. Espaços para indentação são pura maldade ... com chifres.

Conclusão final? Só quero contribuir, o que diabos você está usando?

Conclusão final? Eu só quero contribuir, o que diabos você está usando

Consistente por arquivo. Não misture isso em um arquivo

@basarat o quadrinho está errado. Todos nós sabemos que o cara da Apple usaria espaços e o cara da Microsoft usaria guias.

@jedmao Eu sou um cara da ms e uso espaços :)

Eu acho que o nº 4211 é uma boa proposta.

Eu proporia usar 2 espaços como feito no guia de estilo airbnb / javascript ...

Sugestão: Use os padrões de codificação estabelecidos pela biblioteca que está sendo digitada. Se a biblioteca digitada usar espaços, aspas simples e LFs, faça o mesmo na definição do tipo. Desta forma, podemos evitar o argumento de espaços vs tabs.

O único problema é que não será fácil aplicar essa regra. Se você precisar aplicá-lo e ter total consistência, recomendo seguir as convenções mais populares. De acordo com este site, são espaços e aspas simples.

Minha preferência pessoal são espaços (4) e aspas _duas_, mas não há problema em usar aspas simples se isso significar que tudo é consistente.

Os usuários pro-tab e pro-tab-space podem aceitar um compromisso semelhante?

Minha preferência pessoal são espaços (4) e aspas duplas, mas estou bem em usar aspas simples se isso significa que tudo é consistente.

@ glen-84 puramente para sua diversão ... aqui porque a equipe do compilador usou aspas duplas: https://github.com/Microsoft/TypeScript/issues/5811#issuecomment -160187924

• JSON
• Funciona em todos os idiomas, portanto, menos carga cognitiva

Eu, pessoalmente, uso aspas simples, pois me vejo fazendo mais e mais TypeScript exclusivamente: rose:

Eu acho que também é um pouco mais legível, e era 57% vs 43% (não é uma grande diferença), mas acho que você tem que traçar o limite em algum lugar. =)

Eu gosto do ponto de @jedmao nas guias para indentação e espaços para alinhamento.

Divulgação completa: venho do Go-land onde temos go fmt e nenhuma discussão sobre tabulações ou espaços nunca .. São tabulações para indentação e espaços para alinhamento e funcionam muito bem: +1:

Espaços, é claro. Porque ninguém sabe como as guias são exatamente renderizadas em diferentes editores se forem usadas em outro lugar.

@hinell, por que é importante se as guias são renderizadas de maneira diferente em editores diferentes? Não deveria, contanto que as guias sejam "apenas" usadas para recuo.

Eu prefiro guias, especialmente por causa disso: http://nickgravgaard.com/elastic-tabstops/

Acontece que há um motivo ainda maior para usar guias: acessibilidade do desenvolvedor .

• https://github.com/prettier/prettier/issues/7475
• https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/