Por que a formatação de código avançado não é mais comum?

29

Eu estava lendo Code Complete e, no capítulo sobre layout e estilo, ele previu que os editores de código usariam algum tipo de formatação rich text. Isso significa que, em vez de código parecido com este

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

poderia ser algo como isto:

Procedimento ResolveCollisions

Executa uma resolução de colisão a posteriori através do algoritmo de particionamento espacial

Parâmetros

  • CurrentMap : SpriteContext
  • PotentialColliders : SpriteList

Variáveis ​​locais

  • Collider : Sprite
  • Collidee : Sprite
  • Collision : SpriteCollision
    DoStuff();

Eu vi sintaxe colorindo e realçando e até parênteses, mas nada que se parecesse com isso no código real. Fiquei me perguntando se esse tipo de coisa realmente existia, ou talvez se foi decidido que não tinha benefícios suficientes ou que era uma idéia totalmente ruim.

Algum de vocês já viu um código de formato rico como esse antes ou sabe se a idéia já foi considerada e, eventualmente, rejeitada?

Peter Olson
fonte
8
Você viu a web de Knuth? www-cs-staff.stanford.edu/~uno/cweb.html
greyfade
12
Então agora você quer o Word como seu editor IDE?
5
você nunca brigou com o Word quando faz uma formatação estranha, da qual é impossível se livrar. Seu exemplo supõe que o editor oculte algumas partes do código-fonte real. Como espectador, com certeza seria bom, eu acho, como editor, por favor .. tenha piedade da minha pobre alma!
Newtopian

Respostas:

38

Não há motivo técnico para você não conseguir. Se os editores de texto puderem realçar a sintaxe, eles poderão alterar facilmente outros aspectos da exibição para destacar o código.

No entanto, uma coisa é que o que está sendo digitado altere as cores conforme o editor descobre o que você está digitando. Se o texto mudar de tamanho repentinamente e pular enquanto você digita, seria realmente desagradável.

No entanto, para uma exibição de código 'estático', você pode embelezar facilmente o código-fonte. Por exemplo, use qualquer conversor de código-fonte html parcialmente decente e adicione os tamanhos e estilos de fonte que você gosta nas folhas de estilo, e você terá um código formatado rico.

whatsisname
fonte
14

Razão simples: independência do editor / ferramenta.

Depois que você codificar "rich" - ele será vinculado ao editor que você usou - ou àqueles que entenderão o código rich. Todos os outros editores que não conseguem lidar com a riqueza exibem sem sentido.

Na mesma linha, o código rico não funcionaria bem com as ferramentas diff. Por exemplo, se você acabou de alterar alguma formatação, o diff mostrará uma diferença, mas não é nem uma diferença que você menos se preocupa.

E o controle de versão? Como você diria para ignorar todas as alterações na formatação e ver os arquivos como modificados somente quando houver alguma alteração "real".

Por fim, acho que o objetivo principal do código rico é a legibilidade - e, para isso, acho que melhores (e mais) comentários, nomes de identificadores lógicos e indentação consistente serão suficientes.

Em essência, o texto de programação é melhor tratado como texto simples - o que você vê é o que é a realidade. ( que também está de acordo com a ideia pitônica de explícito melhor do que implícito )

codificador de árvore
fonte
28
Isso não é necessariamente verdade. Se os editores podem fazer destaque de sintaxe, com certeza pode fazer sintaxe "negrito" ou sintaxe "font-sizing", etc.
Whatsisname
4
O Emacs pode ser configurado para fazer isso, mas a IMO alterar o tamanho da fonte seria um desperdício de espaço na tela.
Kevin cline #
4
Se o autor tivesse que fazer a formatação manualmente, seria uma perda de tempo. Claramente, o editor de texto faria isso automaticamente, ou talvez você pudesse usar uma folha de estilo.
Peter Olson
7
@greegit: os editores não deixam informações de cores nos arquivos de origem quando terminam, não precisam deixar outras marcas de formatação, podem regenerá-las sob demanda. Não há diferença fundamental entre o realce da sintaxe e a formatação da sintaxe. Se as ferramentas podem criar diagramas de classe esparsos e diagramas UML a partir do código-fonte automaticamente, uma ferramenta com certeza pode atrapalhar as coisas de tempos em tempos.
Whatsisname
9
Esta resposta com certeza tem muitas votações por estar incorreta.
Jordan
11

Talvez o código ricamente formatado não tenha entendido porque não é uma ideia tão legal. Pessoalmente, não gosto do que vejo no exemplo que você forneceu. Uso cores e realces de sintaxe, mas essa formatação é muito complexa e desvia muito da maneira como estou acostumada a ver e escrever código.

Mike Nakis
fonte
11

Por que isso não existe? Não há demanda / necessidade.

Os editores atuais são capazes de satisfazer as necessidades dos programadores com destaque de sintaxe e algumas outras opções estilísticas menores. Isso já não é "rich text"?

user478148
fonte
7
+1 Para nenhuma demanda. Eu odiaria codificar assim. Parece que estou digitando o relatório TPS no Word, não escrevendo código.
1
@ Nelson Nelson: eu concordo. Evito o Word mesmo para digitar documentos normais, se eu puder (eu uso o LaTeX). Eu gosto de destacar a sintaxe, mas a formatação de código rica seria realmente intrusiva para mim.
Giorgio
5

Isso já existe para o LaTeX no modo AucTeX para o Emacs. Os títulos das seções são maiores em tamanho, os sub e sobrescritos são redimensionados adequadamente e você pode até ter pequenas visualizações de matemática (e possivelmente outros ambientes como Algorítmico).

Isso é bom para o LaTeX porque o mapeamento do código para a saída geralmente é muito mais direto do que em outros programas; Eu acho que não gostaria disso em idiomas de uso geral.

Outra coisa que o Emacs pode fazer é substituir símbolos como ->e forallpor e respectivamente em Haskell. Há poucas razões para que esse tipo de coisa não possa ser estendida para a formatação como você sugere, exceto que não é necessário em Haskell.

Tikhon Jelvis
fonte
2

Há algum tempo, fiz essa pergunta sobre formatação de código, perguntando se os programadores gostariam que seu código fosse formatado à medida que digitavam.

Minha pergunta abordou apenas o aspecto de recuo da formatação, mas algumas respostas podem se aplicar à formatação de código em geral. O sentimento geral nas respostas sugere que os programadores se opõem a perder o controle absoluto da maneira como seu código é representado.

Minha experiência pessoal foi bem diferente. Embora eu normalmente use ferramentas publicamente disponíveis, às vezes preciso escrever XSLT no meu próprio editor personalizado. Este editor formata o código enquanto digito recuando a margem esquerda, para não ter problemas com espaços em branco indesejados (significativos em XSLT) e permite que meu código seja quebrado por quebra de linha e ainda assim mantenha a formatação. Acho a experiência bastante natural, o estilo de formatação é controlado apenas pelo contexto e pela posição dos feeds de linha (a experiência é especialmente gratificante ao usar dispositivos de entrada sensíveis ao toque).

Se o XSLT não estiver bem equilibrado, a formatação realmente ajudará a mostrar onde está o problema. Demorou um tempo para ajustar a alteração horizontal do código enquanto você digita, mas isso não é mais uma distração para mim. No entanto, achei que os recursos de formatação que afetavam o espaçamento vertical do meu XSLT tornavam o editor praticamente inutilizável, então os desativei.

Voltando à sua pergunta, acho que a razão pela qual a formatação rica de código não é mais comum é que leva muito tempo para que as percepções mudem no mundo da programação. Chegará a sua hora, possivelmente coincidindo com a hora em que a edição do código é feita predominantemente sem teclado.

pgfearo
fonte
2

Também em mais de algumas linguagens (Haskell, Ruby, Python, Erlang, CoffeeScript algumas outras) a indentação é importante. Portanto, se você estiver alterando o tamanho da fonte, pode ser muito difícil descobrir.

Principalmente sua tradição. Tenho programado profissionalmente por quase 20 anos e suspeito que isso me deixaria maluco. Escrevo livros no Emacs ou VI com o docbook, por isso não sou fã do WYSIWIG

Zachary K
fonte
2

O CWEB de Knuth faz isso, mas funciona apenas para C / C ++ e Pascal. - Você deveria dar uma olhada ... é bem legal. Existem dois programas: ctanglee cweaveque combinam / arquivos CWEB separados em TeX e C, respectivamente.

muito tolo
fonte
1
nowebfunciona com praticamente qualquer idioma possível. E também existem inúmeros sistemas de programação especializada disponíveis para muitas outras linguagens (lhs e similares). Algumas línguas tinham uma capacidade de digitar pronta para uso desde o início da década de 1960 - veja en.wikipedia.org/wiki/Stropping_(programming)
SK-logic
3
@ SK-logic - Arrgh, por favor, não me lembre do horror que é a programação alfabetizada . Transformando cada revisão rápida de código em uma revisão tediosa e demorada de documentos , criticando cada última mudança de frase e vírgula extraviada. Por que algumas partes da indústria de defesa pensaram que era uma boa idéia que eu nunca saberei. Eu não acho que os editores do WYSIWYG teriam melhorado isso.
Mark Booth
@ Mark Booth, tudo pode se transformar em horror se for feito de maneira errada. A programação alfabetizada é uma ótima ferramenta quando combinada com uma disciplina adequada. Eu não tenho idéia de como seria capaz de anotar meu código com fórmulas complexas, plotagens e gráficos formatados em TeX sem uma ferramenta de programação alfabetizada. E o código não será mais legível e passível de manutenção sem essas anotações.
SK-logic
2

Algum de vocês já viu um código de formato rico como esse antes ou sabe se a idéia já foi considerada e, eventualmente, rejeitada?

Certo. O Xcode suporta estilos além da simples coloração para diferentes sintaxes:

código fonte com texto estilizado

Já faz muito tempo desde que eu o usei, mas acho que o Metrowerks CodeWarrior também suportava textos com estilo, e isso foi há mais de 10 anos.

Porém, você não deseja exagerar nos estilos - qualquer texto, código fonte ou outro pode ser mais difícil de ler quando os estilos variam muito. Em particular, acho que misturar tamanhos é perturbador, e qualquer coisa que faça com que as colunas não se alinhem é irritante. Há uma razão pela qual a maioria dos programadores ainda usa fontes monoespaçadas.

Uma questão diferente é se o texto estilizado deve ser usado como parte da própria sintaxe do idioma. Por exemplo, o compilador deve usar o fato de que algum texto é estilizado de uma certa maneira para determinar que o texto é uma declaração de função? Isso pode parecer louco no começo, mas linguagens como Python e Fortran já usam indentação como sintaxe. No entanto, acho que é mais provável que continuemos a ver o estilo impulsionado pela sintaxe, e não o contrário. Existem muitos benefícios em poder usar texto sem formatação (compiladores mais simples, independência de plataforma, preferências de programadores) e outras tradições evoluíram para tornar o código legível na ausência de estilos (recuo, linhas em branco, caracteres de marcador e recursos do editor, como dobragem de código e menus de navegação).

Caleb
fonte
1

Penso que a rica formatação do código-fonte não é muito popular porque se destina à entrada de informações, onde a estrutura e o significado são muito mais importantes (e mais fáceis de digitar). Fontificação, símbolos especiais especiais e espaços em branco apenas adicionam ruído visual desnecessário. Pode ser apropriado para a documentação gerada.

Nunca há guerra de chamas sobre o mesmo tópico no mundo tipográfico entre aqueles que preferem editores WYSIWYG (como o MS Word) e sistemas como o TeX (LaTeX).

Em geral, não há resposta definitiva. Tudo depende de ferramentas, casos de uso e preferências pessoais.

Oleg Kolosov
fonte
1

Ferramentas como Doxygen ou JavaDoc já realizam formatação de código rich text. Eles também adicionam hipertexto ao código para fins de navegação. Você não precisa inserir tags especiais para formatação básica.

Este não é o WYSIWYG.

mouviciel
fonte
0

Tenho medo de dizer que isso existe.

No passado, trabalhei em algum código do Centura (também conhecido como Gupta ou SQL / Windows - um antigo " 4GL "). Não era realmente possível editar o código do Centura em um editor padrão, como o bloco de notas, para o nível extremo de formatação necessário.

Embora possa parecer uma boa idéia ter um arquivo de origem formatado assim, achei o desenvolvimento bastante restritivo e doloroso.

Além disso, a formatação geralmente causava problemas ao mesclar no controle de origem.

Michael Arnell
fonte
0

Além das outras respostas, gostaria de salientar que, além das dificuldades técnicas do uso da formatação avançada, também é objeto de preferência pessoal.

Se você editar texto sem formatação, poderá escolher as fontes e cores que desejar e elas serão definidas automaticamente. Se você editar texto rico, e se não gostar de cores e fontes específicas definidas manualmente?

corvinus
fonte
1
Eu não acho que isso seja verdade. Tenho certeza de que, se os programadores usassem rich text, haveria um gerador que fizesse algum tipo de marcação semântica que descreve a estrutura do programa e, em seguida, uma folha de estilo personalizável pelo usuário que contém as informações de fonte e cor.
Peter Olson
@ PeterOlson, então você não poderá ler programas sem a sua folha de estilo, pois simplesmente não reconhecerá a designação de cadeias de texto. Isso significa que ninguém pode mostrar ou escrever nada quando se encontra pessoalmente. Pelo contrário, atualmente as fontes e cores são totalmente opcionais e intercambiáveis ​​sem causar danos ao significado.
Corvinus
0

Eu acho que isso ocorre porque ninguém ainda separou a leitura e a escrita do código. Pelo menos não se torna mainstream. Às vezes, você precisa ler o código que tocou há muito tempo ou o código criado por outros desenvolvedores. Você provavelmente terá que gastar muito tempo até estar pronto para alterar um único byte nesta fonte. Este poderia ser o modo "ler" que pode fazer o que for necessário para facilitar o entendimento (tamanho da fonte, reformatação, sub-script, super-script etc). Quando estiver pronto, o editor poderá alternar para o modo "gravação" e ser menos restritivo e obedecer "à regra da menor surpresa"

Maksee
fonte