Como você se sentiria se o seu editor de código formatasse o seu código para você enquanto você digitava, sem tabulações / espaços? [fechadas]

Como na maioria das coisas, tenho certeza de que esse conceito já foi tentado antes - não encontrei editores que usem o que denominei 'Formatação virtual'. O princípio é que existe uma margem esquerda flutuante que simula o efeito dos caracteres de espaço / tabulação preenchidos convencionalmente inseridos pelo desenvolvedor ou pelo próprio editor para formatar o código. O editor analisa continuamente o código (mesmo quando comentado) enquanto você digita e calcula o recuo necessário com base no contexto em que cada feed de linha é encontrado

Estou desenvolvendo essa idéia trabalhando especificamente com um editor XML, pois o XML tem alguns problemas peculiares com a formatação de caracteres e tende a ser muito aninhado, no entanto, acredito que muitos dos princípios ainda se aplicam ao código convencional.

Você já experimentou codificar com essa ferramenta ou tem uma idéia de se isso ajudaria ou dificultaria? Causaria problemas com os sistemas de controle de versão? (detecta e retira todos os caracteres de preenchimento existentes)

A menos que você tenha tentado, o comportamento de uma ferramenta desse tipo é difícil de descrever, parece convencional até que você comece a editar. Eu coloquei um vídeo screencast mostrando um protótipo em ação que demonstra a edição de XML, alterando sua hierarquia e fazendo operações de arrastar / soltar e copiar e colar e, em seguida, como a formatação é interrompida / corrigida quando caracteres inválidos são digitados.

Editar Todas as respostas / comentários até agora foram negativos - para tentar corrigir o equilíbrio, alguns benefícios da formatação virtual para pensar:

• Não há mais debates sobre os padrões de formatação, basta colocar feeds de linha onde estiverem de acordo com a convenção escolhida / obrigatória
• Onde o espaço é escasso (em um livro / blog / documentação), você pode quebrar o texto, mas ainda assim conseguir um recuo perfeito
• Cada bloco de código pode ter uma 'alça de mouse' imediatamente adjacente ao local de início, não pressionada na borda da tela - clique aqui para selecionar o bloco inteiro ou o bloco interno
• Arrastar, soltar e esquecer - torna-se viável pela primeira vez
• Sem tempo gasto reformatando o código de outras pessoas
• Nenhum código formatado incorretamente (no sentido de que não há nenhum - apenas a renderização)
• Usar Backspace em vez de Ctrl + Backspace mantém os dedos nas teclas-guia do teclado
• Renderização flexível - adapte a formatação renderizada ao seu ambiente, alguém tentou ler código em um telefone celular / tablet de tela pequena?
• Considere que existem aproximadamente 25% menos caracteres editáveis ​​(em uma amostra XSLT), isso não traz benefícios de eficiência?

Editar - Conclusões até o momento

1. Os desenvolvedores estabeleceram ferramentas e métodos de trabalho que superam com eficiência a maioria das desvantagens inerentes ao uso de caracteres de preenchimento usados ​​para indentação.

2. Existe uma preocupação de que a remoção de caracteres de formatação afete prejudicialmente algumas ferramentas de diferenciação.

3. Os desenvolvedores desejam a flexibilidade de 'ajustar' a formatação de forma que a renderização automatizada não possa lidar.

4. A remoção dos espaços / guias iniciais significa que é necessária uma ferramenta 'com reconhecimento de código' capaz de formatar código para revisar esse código com eficiência - um editor de texto sem formatação não mostraria formatação.

5. Aqueles que acham que pode haver alguns benefícios hipotéticos (para o recuo virtual), têm uma visão de que as desvantagens superam esses benefícios em potencial - conclusivamente .

Editar - Veredicto

A percepção dos obstáculos e dos poucos (se houver) benefícios é tal que seria imprudente para mim, como desenvolvedor único, perseguir esse conceito de edição sem espaço para linguagens gerais. Para XML / XSLT, no entanto (por causa de seu tratamento especial de espaço em branco), parece haver pelo menos alguma concordância em potencial.

Editar - produto enviado

Apesar do sentimento geralmente negativo encontrado aqui, fui em frente e enviei o editor. Fiz uma versão gratuita na esperança de que isso traga críticas na forma de questões mais concretas, com base na experiência real. Um tanto frustrante, até o momento não houve reclamações (na verdade, quase nenhum feedback considerando o volume de downloads). Gostaria de pensar que isso ocorreu porque os usuários se adaptaram tão bem à idéia que veem isso como um 'e daí?' tipo de recurso - mas não há como dizer ...

O maior problema seria como os arquivos apareceriam para outras ferramentas, principalmente as ferramentas de controle de versão. As terminações de linha são significativas para essas ferramentas. Eu não gostaria de ver uma tela de mesclagem em que tenho uma classe inteira em uma linha e tentar mesclar parte do texto na coluna 347.

Isso seria bom. O Emacs faz mais ou menos isso e, principalmente, acerta. Você já experimentou o modo nXML do Emacs? Como você melhoraria isso?

Você não pode criar um novo editor até experimentar o que já está disponível.

De qualquer forma, o recuo deve ser salvo no arquivo de saída, para que o arquivo possa ser visualizado com outras ferramentas. Não é provável que eu adote um novo editor, a menos que ele suporte a personalização em tempo de execução como o Emacs.

Já vi essa ideia antes, mas nunca a vi realmente funcionar. Na maioria das vezes, quando eu vi a ideia de vir para cima, ele foi derrubado por todos os desenvolvedores lá fora - ou quando tenha sido implementado, ele fez o controle de versão praticamente inútil como meramente vendo código dobrado mudaria o arquivo e ainda confundem a ferramenta diff. (Um exemplo de quão ruim é isso é o Witango Development Studio.)

Posso pensar em vários obstáculos que seu editor teria que superar para ser útil para muitos desenvolvedores:

• Alterações em um arquivo não devem criar ruído no diff -uwcomando * nix . (Sem diferenças espúrias!)
• A edição de um arquivo (anteriormente não formatado) não deve complicar as mesclagens nas ferramentas do SCM.
• Ele deve funcionar bem com outros editores usados ​​pela equipe de desenvolvimento.
• Os usuários devem poder personalizar a formatação para o conteúdo de seus corações - algumas pessoas são bastante apaixonadas pela aparência do código.
• As edições no código existente não devem alterar a formatação existente. É crucial que o editor não reformate repentinamente um arquivo inteiro sem motivo aparente e não mude a formatação de uma linha para pequenas edições simples - isso confundirá as ferramentas de diferenças e irritará os outros membros da equipe.
• Provavelmente não deve retirar o excesso de espaço em branco - provavelmente irritará alguém . Melhor não arriscar.
• Novas linhas adicionadas a um arquivo devem estar de acordo com as configurações de modelines existentes ou com a formatação local (com +/- 3 linhas) existente.
• O editor deve ter um painel de configurações que permita ao usuário definir a política de formatação de código da equipe que é separada do que o editor realmente mostra.

Escusado será dizer que é óbvio que isso exigirá uma certa quantidade de metadados sobre a formatação existente do arquivo. Você provavelmente desejaria mantê-lo separado das fontes, mas mantê-lo sincronizado com um repositório em constante mudança provavelmente seria bastante difícil.

Como usuário do Vim, eu também opino que o editor deve respeitar as modelagens de Vim, Emacs e outros editores e preservar a formatação proscrita da modelo, independentemente do que for exibido.

Na minha opinião, os requisitos para esse software o tornam insustentável. Muitos usuários esperam muito disso para que esse projeto seja bem-sucedido.

Solução, usando arquivos de configuração do formatador baseado em texto (por exemplo, XML):

• Tenha um formatador pessoal configurado pelo desenvolvedor individual.

  • Armazene este formatador localmente.

  • Os arquivos são carregados e editados com formatação local.

  • Eles podem alterar livremente seu estilo de formatação sem interromper nada.

  • A formatação automática pode ser desativada para exibir e editar arquivos não processados.

• Tenha um formatador de equipe mínimo configurado para o padrão da equipe.

  • Armazene esse formatador no controle de versão da equipe.

  • Os arquivos são salvos com a formatação da equipe como substituto de outras ferramentas.

  • Diffs não sofrem de problemas de formatação.

É ridículo se preocupar com a economia de salvar arquivos sem espaços em branco externos, para que você não perca nada salvando os arquivos com alguma formatação definida por um padrão de equipe. No caso de um desenvolvedor solo, você pode oferecer a capacidade de ter a formatação salva (para a "equipe" de uma) espelhamento exibida.

Quando o formatador é insuficiente, você tem duas opções viáveis:

• Exponha uma interface para formatadores personalizados.

  • Feito corretamente, esta é a melhor solução.

  • Feito errado, é o pior.

• Permitir substituição manual da formatação automática.

  • A usabilidade não sofre - considere Ctrl- (Enter | Tab | Espaço).

  • Sanidade - onde você salva essa formatação? Você?

Eu ficaria bem com código que está sendo Autoformatted se o idioma não foi formatar sensível tosse Python tosse .

O Emacs faz a formatação Lisp muito legal, e na hora eu ficaria muito feliz. Não suporto a inserção automática de parênteses ou outros delimitadores: nenhum dos autoinserters que eu tentei conseguiu aproximar-se da maneira como digito.

Eu amo a ideia em conceito . E, embora você tenha sucesso, ainda não encontrei um editor que faça tudo o que quero em termos de formatação. Aqui estão alguns obstáculos (IMO):

• Idiomas exigentes em espaço em branco
• O que é salvo na saída? (Você precisará, até certo ponto, salvar pelo menos parte do recuo para que fique legível para outras pessoas sem a ferramenta)
• Deve absolutamente jogar bonito com a fonte existente / versionamento produtos de controle já em vigor
• Ele deve ser altamente personalizável, especialmente para aqueles de nós (inclusive eu) que são muito, muito, muito exigentes sobre como o código é formatado e recuado (e para onde essa vírgula deve estar em uma lista, mas se a lista for realmente longa, como linhas devem ser quebradas, etc.)
• Ele deve realmente entender a linguagem. Com isso, quero dizer que ele deve seguir a linguagem exatamente como o compilador a entenderá. Já tive muitos editores com sintaxe colorida que interpretam a sintaxe errada, porque há uma faceta noz do idioma que não pode ser simplesmente manipulada com um RegExp. É verdade que você indicou que analisaria continuamente o idioma, mas quem diria que o que você analisa está em conformidade com o compilador que estou usando? (Acredite, existem muitos padrões por aí e muitos negócios engraçados acontecem na maioria dos idiomas, incluindo código que parece errado para um analisador simples, mas é perfeitamente correto para o compilador.)
• Deve ser rápido . E é aqui que a borracha encontra a estrada - você não pode executar uma compilação completa no meu código a cada pressionamento de tecla (especialmente em um projeto grande), a menos que você possa otimizar seu analisador até o enésimo grau. Se houver uma pitada de lentidão no editor, ninguém a usará. (Eu sou um exemplo perfeito de abandonar editores lentos em favor de editores mais rápidos. Se ficar no mínimo, estou fora.)

Você poderia criar algo que atenda razoavelmente bem à maioria dos critérios? Provavelmente. Mas nós, programadores, somos meticulosos, exigentes e detestam mudar e daremos um salto ao primeiro sinal de problema. Aqui você terá problemas se a saída marcar alguém na equipe de desenvolvimento, ou se não funcionar 100% com o sistema de controle de versão, ou se não formatar meu código exatamente assim ou se entende mal o idioma e indenta incorretamente meu código ou se atrasa um milissegundo além do que eu esperava. Porque, por mais que eu pense na idéia, vou direto para meus editores preferidos em um piscar de olhos.

Existe uma abordagem ainda mais radical - um editor semântico puro. Um IDE lida com um código que é representado internamente como um AST, não como um texto sem formatação. Veja JetBrains MPS para exemplo.

Agora que publiquei o editor XML descrito na minha pergunta, estou em uma posição melhor (mas não ideal) para tentar responder a isso sozinho - então vou:

Depois de mais de 500 downloads em menos de 2 semanas, a reação a esse novo conceito inovador na formatação dinâmica de código foi ...

NADA

Sem queixas, sem elogios. Minha interpretação (esperançosa) disso é que as pessoas só querem e esperam um editor que pareça normal e não atrapalhe seu código. Os usuários mal notam que sua formatação é totalmente virtual e as evidências sugerem que eles se importam ainda menos.

Seria um erro, porém, ler muito sobre essa não reação, essa ferramenta é gratuita e, infelizmente, isso significa que pelo menos alguns usuários estarão menos inclinados a criticar. Se eles não gostaram, eles podem simplesmente descartá-lo e usar outra coisa.