Quais são os inconvenientes das paradas de impressão elásticas? [fechadas]

Guerras santas são subjetivas

As paradas elásticas de Nick são um conceito incrível que pode ajudar muitas pessoas a concordar com uma solução viável, embora eu duvido que isso acabe com essa Guerra Sagrada: afinal, também é uma questão de gosto e muitos programadores não se moverão uma polegada de sua posição sobre este assunto, mesmo à custa de comprometimento. Então essa seria a primeira razão.

Por exemplo, muitas pessoas do lado "espaços" ainda não gostam disso, já que requer uma parte adicional de lógica em seu software para uma renderização decente (por exemplo, simplesmente visualizando um changeset em seu Visualização da Web do SCM).

Problemas de implementação

Mas a razão mais óbvia é apenas sua barreira técnica à entrada : é um conceito fundamentalmente diferente do que foi implementado para um número anos (se não décadas) em IDEs e editores de texto. Seria necessário reescrever alguns deles para processar linhas em uma fasão bastante diferente, o que torna difícil para sistemas mais antigos e maiores que tenham uma chance maior de sofrer um acoplamento profundo e rígido em seu código de processamento de linha. É, no entanto, muito mais fácil quando você começa do zero (pense em demo de Nick ou Go do pacote tabwriter .

Nós nos importamos o suficiente?

Uma terceira razão, é que alguns desenvolvedores não estão tão preocupados com isso e não se importam tanto que vão se esforçar para apoiar o esforço. Na maioria dos casos, o conflito entre espaços e tabulações não é um bloqueador de negócios, portanto, não há muita motivação por trás do problema.

Se você quiser, terá que lutar por isso. O que é possível em software de código aberto. E se você mudar o suficiente destes, os de código fechado terão que seguir o risco de perder para alguns de seus usuários, se uma parte tão pequena dele.

Então, se você quiser, dê uma ajuda a Nick.

Muitas vezes tive que lutar com um processador de texto para fazer com que o documento ficasse do jeito que eu queria, sem alguma regra automática oculta controlando o posicionamento das minhas palavras. Eu não quero gastar um segundo tentando descobrir por que o editor está insistindo em colocar essas palavras lá.

Esta é a primeira vez que ouvi falar deles. Não tenho certeza se eles são uma boa ideia, mas eles parecem de pouca utilidade, pois temos ferramentas (como recuo) que formatam código automaticamente.

O que acontece quando abro as suas tabstops elásticas inteligentes no vim e edito-as? A aba limpa automaticamente ou você fica com uma bagunça?

Os principais inconvenientes, como eu os vejo, são, possivelmente, quebrar diffs, controle de versão e não serem compatíveis com editores que não os suportam. Talvez haja muita modificação de código para suportá-los e há coisas mais importantes do que "mais uma coisa de guia para formatar o código". Afinal de contas, todos nós podemos usar indent , que faz todos os itens acima, se a memória servir.

Para ser honesto, não acho isso útil depois que você supera a empolgação inicial. Por exemplo, eu não gosto de comentários no final de uma linha de qualquer maneira - eu sempre coloco meus comentários em uma linha separada. Com isso, as abas elásticas perdem seu uso principal.

Depois disso, é claro que você ainda pode usá-los para alinhar argumentos de função (e parâmetros) e longas listas de atribuições.

Mas para o primeiro, costumo recuar todos os argumentos em um nível adicional e isso funciona perfeitamente comigo:

void foo(
    int x,
    int y,
    string z
)

E eu não vejo qualquer preciso mudar isso.

E quanto ao alinhamento de tarefas, eu não faço isso. Eu coloquei espaços únicos em torno de tarefas, é isso. Eu também tendem a não agrupar muitas atribuições, então raramente há qualquer problema de legibilidade.

Em resumo, as guias elásticas têm absolutamente zero utilidade para mim. Esta é, naturalmente, uma preferência muito pessoal que pode variar, mas acho que funciona bem e acho que a falta de suporte para guias elásticas é porque outras pessoas pensam da mesma forma.

Se um editor os implementasse, eu ainda não os usaria.

Uma desvantagem é que ele não funciona se você quiser alinhamento em um grupo de linhas e, em seguida, indentação no próximo, pois agrupa as paradas de tabulação de linhas adjacentes.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

O que eu queria:

def foo( bar,
         xyzzy ):
    wibble()

Para linguagens de contraventamento isso pode ser um problema menor, já que você pode resolver isso colocando a chave de abertura em uma linha própria (como na animação), mas para linguagens sensíveis a espaços em branco, isso rapidamente se torna uma dor, e você acaba tendo que voltar a usar espaços.

Por que não fazemos apenas o caractere de tabulação vertical (VT, ASCII 11) servir para indicar o uso de tabstops elásticos? Ele serve sem propósito em qualquer linguagem de programação mainstream, mas é analisado como espaço em branco válido em todos eles, AFAIK.

Isso significaria que o uso de tabstops elásticos não é mais uma convenção externalizada (por exemplo, "esse arquivo foi formatado com tabstops elásticos, por favor, ligue-os"), mas algo em que você optará caso a caso.

Editores de texto existentes geralmente exibem um glifo ou um único espaço no lugar de uma guia vertical. Isso não é ideal, mas um pequeno preço a pagar, IMO.

Eles não são mencionados porque não são implementados na maioria dos IDEs de editores de texto; eles são uma novidade de pouco uso real em um projeto.

Os espaços foram usados para esquematizar a programação desde os dias dos cartões perfurados. Tabs surgiram e alguém obviamente pensou que eles eram uma boa ideia (eles estavam enganados: p).

Nos dias em que a maioria dos editores modernos pode converter guias automaticamente em espaços ... eles são bastante inúteis.

Ter que instalar mais uma ferramenta para lidar com algo tão trivial quanto as tabs vs espaços certamente não me agrada, e não acho que seria para a maioria dos meus colegas.

Acho que eles seriam muito úteis se os IDEs os suportassem (Microsoft!). Uma vez que as pessoas acham que podem colocar suas caixas de flores ao lado e tê-las bem legíveis, elas o farão. Você pode adicionar mais comentários ao código-fonte de repente (o que só pode ser uma coisa boa).

Suponho que também poderíamos adicionar "dicas de ferramenta" de comentários à lista de "seria bom se ...", portanto, seus blocos de comentários grandes poderiam ser ocultados e visualizados facilmente quando necessário. Talvez pudéssemos também ter blocos de comentários que fazem parte da documentação (não do tipo de sandcastle, trechos de documentação apropriados e legíveis pelo usuário que foram incorporados no código, não apenas os cabeçalhos do método)

Desvantagens: pode fazer com que seus diffs de origem pareçam ruins se um monte de linhas parecesse que elas foram alteradas quando realmente apenas 1 foi modificado (se o editor salvou o arquivo com as guias convertidas em espaços). Ou, se a guia elástica foi implementada com um único caractere (ou, mais provavelmente, duas paradas de tabulação), a visualização da sua fonte fora do editor pode parecer ruim.

Acho que gosto da ideia, no entanto, a aba 'tabulação' no final de uma linha elimina o bloco de comentários e alinha todos os comentários nas linhas subseqüentes (que têm o espaçamento de tabulação dupla) de acordo.

Veja como eu vejo isso: se a maioria das ferramentas populares já suportava as tabstops elásticas, muitas pessoas as usariam. O mesmo aconteceu com o modo de navegação / edição do vi, com realce de sintaxe e, posteriormente, com o Intellisense. Em cada caso, a sabedoria estabelecida era de que não é útil ou não é necessária, mas foi implementada e decolou.

As tablaturas elásticas têm, claro, um impacto relativamente baixo. A maioria das pessoas está suficientemente satisfeita com o status quo e, por isso, não se importa. Um raciocínio semelhante é aplicado a muitas situações em que algumas pessoas ficam satisfeitas com o que têm e não veem motivos para mudar para algo mais avançado. Em outras palavras, o maior problema com o tabstops elásticos é o mesmo de quase todas as outras boas ideias: ele precisa ganhar força.

Mas isso não significa que o recurso não possa ser adotado de forma incremental. Cada uma das linguagens de programação foi adotada de forma incremental, mesmo que uma equipe inteira precise de um novo compilador e de um novo IDE para começar a usá-lo. O mesmo vale para todas as arquiteturas de hardware e muitos outros exemplos. Também não é o caso de que a falta de integração com as ferramentas existentes é uma demonstração: o mesmo vale, por exemplo, para o “formato unified-diff”, que substituiu de forma incremental um formato anterior menos legível que foi entendido por ferramentas automatizadas. (como patch). Essas ferramentas foram atualizadas ao longo do tempo.

Eu aprecio os problemas de interoperabilidade que outros mencionaram, mas apesar deles, certamente haverá equipes (como a minha) que adotariam isso sem hesitação, em nossa totalidade. Ferramentas externas, como diffing, merging etc., inicialmente não o suportam, mas faríamos nossa parte para incentivar os fornecedores a incluírem o recurso. É assim que sempre houve progresso. Isso requer algumas dores por um período transitório temporário, mas no final, vale a pena.

O maior problema que eu tenho com ele é o espaçamento inconsistente em toda a documentação. Eu sei que como programador eu ficaria irritado ao ver um loop ou se a instrução no recuo 'padrão' e, em seguida, para notar em diferentes indentações. Eu sei pessoalmente, eu gosto de ver todas as minhas chaves alinhou toda a documentação, não apenas no bloco de código que estou olhando.

No geral, acho que é uma boa ideia, mas pessoalmente, eu não gostaria disso.

Acabei de testar a implementação de tabstops elásticos do jEdit, que funciona incrivelmente bem com as linguagens de programação com as quais estou familiarizado (principalmente linguagens HTML / XML e C). Com o código Python, no entanto, aqui está como ele foi renderizado (espaços usados no lugar das guias para ilustrar como as coisas se alinham):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

Para um idioma como o Python que depende do espaçamento, esse é um acordo, a menos que você desabilite a funcionalidade fornecida pelas paradas de tabulação elásticas. Editores como o Vim e o Emacs tornam a desativação da maioria dos tipos de funcionalidade simples, se você souber o nome da opção e como desativá-la, mas será necessário desativar essa funcionalidade para códigos como os acima.

Dito isso, é ótimo para x86 ASM, C, C ++, Go, XML, HTML e outros que não dependem tanto do espaço em branco:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

Eu direi que os dialetos de Lisp, como o Scheme, têm suas próprias convenções, o que também faz com que as tabstops elásticas processem códigos "feios". Se eu alterar minhas configurações de tabstop para corresponder à convenção de 2 colunas e inserir tabstops em locais incomuns (entre uma função e seus argumentos):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

vs. o mais legível:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

Concedido, este não é tão ruim quanto o exemplo do Python, mas definitivamente reduz a legibilidade do código. Embora eu aprecie muito a funcionalidade ao codificar em algo como C # ou C ++, detesto a funcionalidade ao codificar em uma linguagem como Python ou Scheme, em que o espaço em branco é funcional e / ou visualmente útil. As tablaturas Elastic foram criadas especificamente para serem úteis sem a necessidade de um utilitário de recuo separado, mas claramente não é para todas as linguagens de programação.

O Emacs já manipula o recuo na presença de parênteses não fechados e alinhará automaticamente wilma com fred . Não tenho ideia do porque o Eclipse não faz o mesmo. Ok, eu tenho uma ideia, mas é pouco elogioso.

Você pode conseguir que o Emacs alinhe o comentário também, sem muita dificuldade, mas a AFAIK ninguém, mas você sempre quis isso.