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?

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.

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 )

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.

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"?

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.

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.

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

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.

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:

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).

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.

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.

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.

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?

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"