Quais são as desvantagens dos tabuleiros elásticos? [fechadas]


83

Veja aqui: uma típica guerra santa entre abas e espaços .

Agora veja aqui: tabstops elásticos . Todos os problemas resolvidos e um monte de novos comportamentos muito úteis adicionados.

tampas elásticas

As guias elásticas são mencionadas na discussão sobre guias versus espaços? Por que não? Existem desvantagens na idéia elástica do tabstop tão séria que ninguém jamais as implementou em um editor popular?

EDIT : Peço desculpas por colocar muita ênfase em "por que eles não são mencionados". Não era exatamente isso que eu pretendia; essa questão é possivelmente fora de tópico. O que realmente quero dizer é: quais são as maiores desvantagens disso que impedem a adoção mais ampla de uma ideia obviamente benéfica? (em um mundo ideal onde tudo já o suporta)

(Acontece que já existe uma solicitação no Microsoft Connect para uma implementação do Visual Studio de tabstops elásticos e também uma solicitação no Eclipse . Além disso, há uma pergunta sobre outros editores que implementam tabstops elásticos .


4
Essa seria uma ótima pergunta para ux.stackexchange.com
JonnyBoats

11
Eles nunca são mencionados na discussão "abas versus espaços", porque quase não há como um programador trabalhar com essas coisas. Talvez se você tivesse uma implementação do Eclipse, VS, gvim e emacs, isso pode mudar.
Paul Tomblin

2
Eu realmente gosto da idéia, mas é apenas quando você convive com ela por um mês ou mais para que você realmente saiba quais são as armadilhas. Como tudo sempre, não são garantidos para ser alguns casos, onde ele faz coisas que você não esperaria ...
Chris Burt-Brown

3
@ ChrisBurt-Brown Isso é sempre um risco, sim. O IntelliSense também possui suas armadilhas, como substituir textos quando você não queria. No geral, no entanto, o IntelliSense em C # é uma grande vitória.
Roman Starkov

4
Eu quero isso no bloco de notas ++ ... Eu quero isso agora
Ben Brocka

Respostas:


32

As guerras santas são subjetivas

As travas elásticas de Nick são um conceito incrível que poderia ajudar muitas pessoas a concordar com uma solução viável, embora eu duvide que isso acabaria completamente com essa Guerra Santa: afinal, é também uma questão de gosto e muitos programadores não se mexem. polegada de sua posição sobre esse assunto, mesmo à custa do comprometimento. Então essa seria a primeira razão.

Por exemplo, muitas pessoas do lado "espaços" ainda não gostam, pois requer uma parte adicional da lógica do seu software para uma renderização decente (por exemplo, simplesmente visualizando um conjunto de alterações na visualização na 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 por vários anos (se não décadas) em IDEs e editores de texto. Seria necessário reescrever alguns deles para processar linhas de uma maneira relativamente diferente, o que dificulta sistemas mais antigos e maiores que têm maior chance de sofrer um acoplamento profundo e rígido em seu código de processamento de linhas. É, no entanto, muito mais fácil de fazer quando você começar do zero (pense em demonstração de Nick ou de Go 's tabwriter pacote).

Para uma anedota pessoal, lembro-me de abordar o autor um tempo atrás para perguntar se havia algum apoio do emacs à vista e, nesse caso em particular, ele mencionou isso como a razão para não ser trivial. Ele também pediu ajuda da comunidade para ajudar a implementar esse recurso e trazê-lo para as massas.

Nós nos importamos o suficiente?

Uma terceira razão é que alguns desenvolvedores não estão tão preocupados com o assunto e realmente não se importam tanto com o fato de irem além para apoiar o esforço. Na maioria dos casos, o conflito de espaços versus abas 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ê alterar o suficiente, os de código fechado terão que seguir o risco de perder para parte da base de usuários, se for uma parte muito pequena.

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


(fora do tópico) Muitas vezes me pergunto como outros recursos "isso é bom, mas muito pequeno" chegam a produtos como o Visual Studio. Parece que alguém da equipe simplesmente encontrou tempo para implementá-lo por motivos pessoais. Pense em digitar várias linhas por vez no Visual Studio, por exemplo; não é como se dezenas de milhares de pessoas pedissem, mas eu gosto bastante.
Roman Starkov

3
@romkyns: Quanto a muitas coisas, é preciso um membro silencioso ou mil vozes gritando nos portões.
haylem 28/02/12

35

Muitas vezes tive que lutar com um processador de texto para fazer com que o documento tivesse a aparência desejada, sem uma regra automática oculta que controla o posicionamento das minhas palavras. Não quero gastar um segundo tentando descobrir por que o editor está insistindo em colocar essas palavras lá.


11
Eu também não. Eu simpatizo totalmente com esse sentimento, pois essas regras também me frustram. Mas isso é diferente de duas maneiras. Um: assim como os tabstops agora, você não precisa usá-los se não quiser. Você pode deixar o texto de seus colegas em paz se ele os usar. Dois: tabstops elásticos não têm regras ocultas, mas as óbvias. O comportamento é completamente natural - talvez até mais natural do que os tabstops tradicionais, que ocorrem em alguma posição arbitrária, geralmente irrelevante, dentro do texto. É por isso que ninguém mais usa tabstops para outra coisa que não seja recuo.
Timwi

10
@ Timwi: A questão era listar desvantagens. Eu fiz.
28412 mhoran_psprep

14
Pode não ser óbvio a partir do GIF, mas a única conclusão envolvida é que, quando você pressiona "TAB", o que vier depois sai corretamente alinhado verticalmente. Não é nada como um processador de texto. Experimente a demonstração interativa real no link que eu postei e você verá como é natural.
Roman Starkov

3
@mhoran_psprep: É justo, agradeço sua opinião. Acho que estávamos olhando para diferentes interpretações da questão. Você está listando suas desvantagens usando o recurso, enquanto eu pensava que era sobre desvantagens de introduzir o recurso (ou seja, torná-lo disponível e não obrigatório ).
Timwi

27

Esta é a primeira vez que ouvi falar deles. Não tenho certeza se são uma boa ideia, mas parecem pouco úteis, pois temos ferramentas (como recuo) que já formatam automaticamente o código.

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

As principais desvantagens, como eu as vejo, possivelmente quebram as diferenças, o controle de versão e não são compatíveis com editores que não as suportam. Talvez haja muita modificação no código para suportá-los e há coisas mais importantes do que o recurso "mais uma aba para formatar o código". Afinal, todos nós podemos usar o indentque faz todo o acima, se a memória servir.


9
Que atitude de retrocesso. Não vamos progredir porque as ferramentas antigas e desatualizadas favoritas das pessoas ainda não conseguem lidar ! (A ironia, é claro, é que essas ferramentas (como o vim) são de código aberto, por isso, se fosse realmente importante para você, você poderia (e provavelmente deveria ) adicionar suporte elástico ao tabstop)
Timwi

14
@ Timwi: Você está totalmente perdendo o argumento que eu estava fazendo. O que acontece quando seu arquivo de código é analisado por algo que não está ciente das tabulações elásticas? Você acaba com uma bagunça ou eles podem lidar? E o controle de versão e as diferenças? Apenas desejar que todas as ferramentas suportem o recurso $ não é realista, mesmo que essas ferramentas sejam de código aberto.
Sardathrion

14
@ Timwi: Você supõe que todos acham que as abas elásticas são tão impressionantes quanto você pensa que são. Isto pode não ser verdade.
Sardathrion

7
@ Sardathrion está certo. O que acontece quando eu tenho que conectar remotamente no meu servidor * nix sem um sistema de janelas instalado e preciso examinar algum código com o Vim / Emacs / Pico / Whatever? Se existe um mecanismo que seja legível, tudo bem ... caso contrário, seria um pesadelo. Não vejo o benefício da aba elástica deixar de ser tão benéfica assim mesmo. Já posso formatar automaticamente meu código para parecer como deveria nos IDEs que eu uso.
Rig

7
O ponto de controle de versão é bom - não acho que as pessoas gostem de um editor que silenciosamente começa a alterar o posicionamento / formato dos comentários no código arbitrariamente distante do código que está modificando (consulte a seção magenta na animação do OP gif). Seria útil ter uma implementação de referência para jogar, mas o que eu vejo até agora não é notável - o emacs já faz muito disso, apenas com algumas teclas extras (o que sem dúvida é uma coisa boa).
Mcmcc

13

Para ser sincero, não os acho tão úteis assim que você supera a emoção inicial. Por exemplo, de qualquer maneira, não gosto de comentários no final de uma linha - 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, eu apenas recuo todos os argumentos em um nível adicional e isso funciona perfeitamente bem comigo:

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

E eu não vejo qualquer necessidade de mudar isso.

E quanto ao alinhamento de tarefas, eu não faço isso. Coloquei espaços únicos em torno de tarefas, é isso. Eu também tendem a não agrupar muitas tarefas, por isso raramente há problemas de legibilidade.

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

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


Estimado. Parece que você também pode usar uma fonte de largura variável se desejar, pois não alinhará nada além do início da linha. O Visual Studio tem um suporte muito bom para isso, na verdade, e o aumento da legibilidade é bom.
Roman Starkov

1
@romkyns Tivemos discussões sobre isso e, no decorrer de uma , tentei usar uma fonte proporcional para programação por algum tempo. O resultado foi que as fontes monoespaçadas funcionam melhor, mesmo desconsiderando o recuo. Além disso, atualmente estou trabalhando exclusivamente no Vim e no console, nenhum dos quais provavelmente suportará fontes proporcionais.
22912 Konrad Rudolph

1
@romkyns Dito isto, esses problemas são solucionáveis ​​(ou talvez até resolvidos, com uma fonte proporcional projetada para programação). Mas ainda não vejo a necessidade.
27530 Konrad Rudolph

13

Uma desvantagem é que não funciona se você deseja alinhar em um grupo de linhas e depois recuar no próximo, pois agrupa as paradas de tabulação das linhas adjacentes.

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

O que eu queria:

def foo( bar,
         xyzzy ):
    wibble()

Para idiomas com chaves, isso pode ser menos problemático, pois geralmente você pode resolver isso colocando a chave de abertura em uma linha própria (como na animação), mas para idiomas sensíveis a espaços em branco, isso rapidamente se torna um problema, e você acaba tendo que voltar a usar espaços.


Acordado. A implementação de Nick não funciona muito bem para linguagens como Python.
Roman Starkov

3
Por que isso não funcionaria? Esta não é uma limitação fundamental, o algoritmo só precisa ter consciência da linguagem. Mas, até certo ponto, isso é verdade até hoje, por exemplo, o Vim define regras de indentação diferentes, dependendo do idioma. Isso poderia facilmente acomodar o recuo do Python.
21912 Konrad Rudolph

1
@KonradRudolph Não, eles não podiam. O sorteio das paradas elásticas é a capacidade de recuar / desassociar automaticamente grupos de texto juntos. Um exemplo simples é o final de uma instrução "if": você tenta e recuar porque você está saindo da instrução, mas os tabstops elásticos "inteligentes" decidem que você também deve recuar a linha ou duas acima, etc. e assim por diante ... E se você precisar agrupar explicitamente o texto, qual é o objetivo? É mais trabalho para fazer isso do que corrigir os travessões si mesmo ...
Izkata

1
@Izkata O cancelamento da indenização manualmente (deveria) simplesmente encerrava o grupo atual. Por que você controlaria o recuo com a guia elástica para manualmente? Você não iria, então o algoritmo sabe que quando você faz isso, é para terminar um bloco, para não recuar o bloco acima.
21912 Konrad Rudolph

1
Oh, bom argumento. Hmm ... talvez você possa recuar os argumentos? Então, wibble()teria apenas um único recuo e, portanto, não estaria alinhado com os argumentos da função?
precisa saber é o seguinte

12

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 não serve para nada em nenhuma linguagem de programação convencional, mas é analisado como espaço em branco válido em todos eles, o AFAIK.

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

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


10

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

Os espaços são usados ​​para definir a programação desde os dias dos cartões perfurados. As guias apareceram e alguém obviamente pensou que eram uma boa ideia (estavam enganadas: p).

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

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


Eu limpei os comentários enquanto eles estavam caindo em insulto.
ChrisF

1
Apenas pensei em apontar, a principal razão pela qual eu gosto da ideia de tabuleiros elásticos não é porque resolve o problema de guias versus espaços, mas por causa do comportamento mostrado no GIF na pergunta original; alinhamento automático e sem dor. Além disso, para as diferenças de VCS, há o benefício adicional de que não houve alterações de espaço em branco nesse exemplo.
precisa saber é o seguinte

"Ter que instalar mais uma ferramenta ..." não é um argumento bom o suficiente ... Como se ainda não houvesse ferramentas suficientes sendo usadas.
Milind R

@MilindR Se você considera um argumento bom o suficiente ou não, é a razão pela qual (na época, três anos atrás) eu não teria interesse nisso. Existem muitas ferramentas usadas que fazem algo útil não é um motivo para adicionar outra que, na verdade, não adiciona nada ao seu ambiente.
TZHX

Atitudes como essa são o motivo pelo qual empresas como a MS decidem forçar os usuários a novos UXs ... Estremeço ao pensar no que aconteceria se a mesma atitude fosse aplicada à transição de disquetes -> CD.
precisa saber é o seguinte

4

Eu acho que eles teriam muita utilidade se os IDEs os suportassem (Microsoft!). Quando as pessoas descobrirem que podem dar um tapa nas caixas de flores e deixá-las bem legíveis, elas o farão. Você pode adicionar mais comentários ao código-fonte subitamente (o que só pode ser uma coisa boa).

Suponho que também poderíamos adicionar "dicas de ferramentas" de comentários à lista de 'seria bom se ...', para que seus grandes blocos de comentários pudessem ser ocultados e visualizados facilmente quando necessário. Talvez também possamos ter blocos de comentários que fazem parte da documentação (não coisas do tipo castelo de areia, trechos de documentação legíveis pelo usuário apropriados que foram incorporados no código, não apenas os cabeçalhos dos métodos)

Desvantagens: isso pode fazer com que as diferenças de origem pareçam ruins se várias linhas parecerem alteradas quando 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 guias), a visualização da sua fonte fora do editor pode parecer ruim.

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


3

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

Tabstops elásticos, é claro, têm um impacto relativamente baixo. A maioria das pessoas está suficientemente feliz com o status quo e, portanto, não se importa. Um raciocínio semelhante é aplicado a muitas situações em que algumas pessoas ficam felizes com o que têm e não vêem razão para mudar para algo mais avançado. Em outras palavras, o maior problema com tampões elásticos é o mesmo para quase todas as outras boas idéias: ele precisa ganhar tração.

Mas isso não significa que o recurso não possa ser adotado de forma incremental. Cada linguagem de programação foi adotada de forma incremental, mesmo que uma equipe inteira exija um novo compilador e um novo IDE para começar a usá-lo. O mesmo vale para toda arquitetura de hardware e para muitos outros exemplos. Também não é o caso de que a falta de integração com as ferramentas existentes seja um empecilho: o mesmo acontece, por exemplo, com o "formato unificado-diff", que substituiu gradualmente um formato anterior menos legível que, no entanto, era entendido por ferramentas automatizadas (como patch). Essas ferramentas foram atualizadas ao longo do tempo.

Agradeço as questões de interoperabilidade que outros já mencionaram, mas, apesar delas, certamente haverá equipes (como a minha) que adotariam isso sem hesitação em nossa totalidade. Ferramentas externas como difusão, mesclagem etc. inicialmente não o suportam, mas faríamos nossa parte para incentivar os fornecedores a incluir o recurso. É assim que o progresso sempre foi feito. Requer algumas dores por um período transitório temporário, mas no final vale a pena.


O argumento C vs C ++ parece um pouco equivocado. Embora possa ser verdade que este é o caso de "algumas pessoas" (como você disse com razão), há razões óbvias para manter C ou favorecer C ++, dependendo da situação. O tamanho do tempo de execução do C ++ é um deles, em uma configuração padrão.
28512 haylem

Eu estou com haylem. Seu argumento seria mais correto sem a comparação C-versus-C ++. Eles são idiomas bem diferentes. Na minha opinião, C é para programação de sistemas e outros trabalhos de baixo nível em que você precisa de muito controle (uma VM, por exemplo). O C ++ é mais para aplicativos de nível médio, onde a abstração é útil para gerenciar a complexidade (espaços para nome, contêineres e algoritmos STL, modelos), mas o desempenho ainda é uma preocupação (os jogos são o exemplo mais visível).
31412 Jon Purdy

@haylem: Obrigado pelo feedback. Eu removi a referência ao C / C ++.
Timwi

@ JonPurdy: Obrigado pelo feedback. Eu removi a referência ao C / C ++.
Timwi

2

O maior problema que eu teria com isso é o espaçamento inconsistente na documentação. Como programador, eu ficaria irritado ao ver um loop ou declaração no recuo 'padrão' e depois perceber em recuos diferentes. Sei pessoalmente que gosto de ver todos os meus suspensórios alinhados em toda a documentação, não apenas no bloco de código que estou vendo.

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


1

Acabei de experimentar a implementação de tabstops elásticos do jEdit, que funciona surpreendentemente bem com as linguagens de programação com as quais estou familiarizado (principalmente HTML / XML e linguagens C). No entanto, com o código Python, aqui está como ele é renderizado (espaços usados ​​no lugar de 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 uma linguagem como Python que se baseia no espaçamento, isso é um fator decisivo, a menos que você desative a funcionalidade fornecida pelas tabelas elásticas. Editores como Vim e Emacs simplificam a desabilitação da maioria dos tipos de funcionalidade, se você souber o nome da opção e como desabilitá-la, mas seria necessário desabilitar essa funcionalidade para códigos como o descrito acima.

Dito isto, é ó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 dialetos Lisp como Scheme têm suas próprias convenções que também fariam tabstops elásticos renderizar código "feio". 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)))))

É verdade que 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 algo como C # ou C ++, eu abomino a funcionalidade ao codificar em uma linguagem como Python ou Scheme, onde o espaço em branco é funcional e / ou visualmente útil. Tabstops elásticos foram criados especificamente para serem úteis sem a necessidade de um utilitário de indentação separado, mas claramente não se destina a todas as linguagens de programação.


0

O Emacs já lida com recuo na presença de parênteses não fechados e alinha automaticamente o wilma com o fred . Não faço ideia por que o Eclipse não faz o mesmo. Ok, eu tenho uma ideia, mas não é de cortesia.

Você poderia fazer o Emacs alinhar o comentário também, sem muitos problemas, mas AFAIK ninguém, mas você sempre quis isso.


2
Só posso interpretar sua última frase como trolling, já que obviamente pelo menos um outro cara queria bastante criar uma página bem argumentada, uma implementação Java e um GIF para mostrar por que é bom. Se você ler as respostas, descobrirá que Nick também não está sozinho. Oh espere, olhe aqui também.
Roman Starkov

A propósito, o Emacs recua wilmaquando você faz edições, como alterar o tamanho do nome da função? Se isso acontecer, é bem parecido com o que os tabstops elásticos fazem.
Roman Starkov

@romkyns: Eu não tive a intenção de ser corrico, eu só queria dizer que eu nunca tinha visto esse estilo de comentário recuar no Emacs. Geralmente, o EMACS não recua várias linhas à medida que você digita, mas isso também pode ser alterado.
Kevin Cline
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.