Non c'è una ragione tecnica che non potresti. Se gli editor di testo possono fare l'evidenziazione della sintassi, possono semplicemente cambiare altri aspetti del display per evidenziare il codice.

Tuttavia, una cosa è avere qualsiasi cosa venga cambiata, cambiare i colori mentre l'editor capisce cosa stai scrivendo. Avere il testo cambia improvvisamente dimensioni e saltare mentre si sta digitando diventerebbe davvero odioso.

Tuttavia, per una visualizzazione del codice "statico", è possibile abbellire facilmente il codice sorgente. Ad esempio, prendi qualsiasi convertitore di codice sorgente e gt; decente e aggiungi le dimensioni e gli stili dei caratteri che preferisci ai fogli di stile e avrai un codice formattato ricco.

Semplice motivo: editor / indipendenza dello strumento.

Una volta che rendi il tuo codice "ricco" - sarà legato all'editor che hai usato - o a quelli che possono comprendere il codice ricco. Tutti gli altri editor che non sono in grado di gestire la ricchezza mostreranno parole senza senso.

Allo stesso modo, il ricco codice non funzionerebbe bene con gli strumenti diff. Ad esempio, se hai appena modificato la formattazione, il diff mostrerà una differenza, ma non è nemmeno una differenza per la quale sei meno interessato.

E per quanto riguarda il controllo della versione? Come diresti di ignorare tutte le modifiche apportate alla formattazione e di vedere i file modificati solo quando c'è un cambiamento "reale".

Infine, suppongo che l'intero punto del codice ricco sia la leggibilità, e per questo motivo ritengo che siano sufficienti (e anche più) commenti, nomi di identificatori logici e rientri coerenti.

In sostanza, il testo di programmazione è gestito al meglio come un testo normale: ciò che vedi è ciò che è la realtà. ( che è anche in linea con l'idea di Pythonic di esplicitare meglio di implicita )

Forse il codice formattato in maniera estesa non è stato preso in considerazione perché non è un'idea così interessante. Personalmente, non mi piace quello che vedo nell'esempio che hai fornito. Uso la colorazione e l'evidenziazione della sintassi, ma la formattazione è troppo elaborata e si discosta troppo dal modo in cui sono abituato a vedere e scrivere il codice.

Perché non esiste? Non c'è la domanda / necessità per questo.

Gli editor attuali sono in grado di soddisfare le esigenze dei programmatori con evidenziazione della sintassi e alcune altre opzioni stilistiche minori. Non è già "rich text"?

Questo esiste già per LaTeX in modalità AucTeX per Emacs. I titoli delle sezioni sono di dimensioni maggiori, i sottotitoli e gli apici vengono ridimensionati in modo appropriato e si possono anche avere piccole anteprime di matematica (e possibilmente altri ambienti come Algorithmic).

Questo va bene per LaTeX perché la mappatura dal codice all'output di solito è molto più semplice che in altri programmi; Penso che non mi piacerebbe affatto per le lingue più generali.

Un'altra cosa che Emacs può fare è sostituire simboli come -> e forall con → e ∀ rispettivamente in Haskell. Non c'è motivo per cui questo genere di cose non possa essere esteso alla formattazione come stai suggerendo eccetto che non è assolutamente necessario in Haskell.

Qualche tempo fa, ho chiesto a questa domanda sulla formattazione del codice, chiedendo se i programmatori vorrebbero che il loro codice fosse formattato come hanno digitato.

La mia domanda riguardava solo l'aspetto della rientranza della formattazione, ma alcune risposte potrebbero essere applicate alla formattazione del codice in generale. Il sentimento generale nelle risposte suggerisce che i programmatori sono contrari a perdere il controllo assoluto del modo in cui il loro codice è rappresentato.

La mia esperienza personale è stata molto diversa. Anche se normalmente utilizzo strumenti disponibili pubblicamente, a volte ho bisogno di scrivere XSLT nel mio editor personalizzato. Questo editor formatta il codice mentre scrivo rientrando il margine sinistro, quindi non ho problemi con gli spazi vuoti indesiderati (significativi in XSLT) e consente al mio codice di eseguire il wrap di parole e mantenere comunque la formattazione. Trovo l'esperienza abbastanza naturale, lo stile di formattazione è controllato dal contesto e dalla posizione dei feed di riga (l'esperienza è particolarmente gratificante quando si utilizzano dispositivi di input sensibili al tocco).

Se l'XSLT non è ben bilanciato, la formattazione aiuta a mostrare dove si trova il problema. Ci è voluto un po 'per adattarsi al cambio di codice in orizzontale mentre si digita, ma non è più una distrazione per me. Tuttavia, ho scoperto che le funzionalità di formattazione che influivano sulla spaziatura verticale del mio XSLT rendevano l'editor quasi inutilizzabile, quindi ho disabilitato queste.

Per tornare alla tua domanda, penso che il motivo per cui la formattazione avanzata del codice non è più comune è solo che ci vuole molto tempo perché le percezioni cambino nel mondo della programmazione. Arriverà il momento, forse in coincidenza con il momento in cui la modifica del codice viene eseguita prevalentemente senza tastiera.

Anche in più lingue (Haskell, Ruby, Python, Erlang, CoffeeScript pochi altri) è importante l'indentazione. Quindi, se stai cambiando le dimensioni dei caratteri potrebbe diventare molto difficile capirlo.

Per lo più la sua tradizione. Ho programmato professionalmente per quasi 20 anni e ho il sospetto che mi farebbe impazzire. Scrivo libri in Emacs o VI con docbook, quindi non sono un fan di WYSIWIG

Knuth's CWEB lo fa, ma funziona solo con C / C ++ e Pascal. - Dovresti dare un'occhiata a questo però ... è abbastanza pulito. Esistono due programmi: ctangle e cweave che combinano / separano i file CWEB in TeX e C rispettivamente.

Have any of you seen richly-formatted code like this before, or know if the idea was ever considered and eventually rejected?

Certo. Xcode supporta gli stili oltre la semplice colorazione per una sintassi diversa:

È passato molto tempo dall'ultima volta che l'ho usato, ma penso che Metrowerks CodeWarrior abbia supportato anche il testo in stile, e questo è stato più di 10 anni fa.

Non vuoi esagerare con gli stili, però - qualsiasi testo, codice sorgente o altro, può essere più difficile da leggere quando gli stili variano troppo. In particolare, penso che mescolare le dimensioni sia fonte di distrazione e qualsiasi cosa che faccia sì che le colonne non si allineino è fastidiosa. C'è un motivo per cui la maggior parte dei programmatori utilizza ancora i font a spaziatura fissa.

Una domanda diversa è se il testo stilizzato debba essere usato come parte della sintassi del linguaggio stesso. Ad esempio, il compilatore dovrebbe utilizzare il fatto che il testo sia stato disegnato in un certo modo per determinare che il testo è una dichiarazione di funzione? All'inizio potrebbe sembrare folle, ma linguaggi come Python e Fortran usano già indentazione come sintassi. Tuttavia, penso che sia più probabile che continueremo a vedere lo stile guidato dalla sintassi piuttosto che viceversa. Ci sono molti benefici che derivano dall'essere in grado di utilizzare il testo normale (compilatori più semplici, indipendenza dalla piattaforma, preferenze del programmatore) e altre tradizioni si sono evolute per rendere il codice leggibile in assenza di stili (rientro, righe vuote, caratteri di indicatore e funzioni di editor come la piegatura del codice e i menu di navigazione).

Penso che la ricca formattazione del codice sorgente non sia molto popolare perché è intesa per l'input di informazioni, dove la struttura e il significato sono molto più importanti (e più facili da scrivere). Fontificazione, simboli speciali e spazi bianchi aggiungono solo inutili disturbi visivi. Potrebbe essere appropriato per la documentazione generata però.

Ci sono infinite flame war sullo stesso argomento nel mondo di composizione tra coloro che preferiscono gli editor WYSIWYG (come MS Word) e sistemi come TeX (LaTeX).

In generale, non esiste una risposta definitiva. Tutto dipende da strumenti, casi d'uso e preferenze personali.

Strumenti come Doxygen o JavaDoc eseguono già formattazioni di testo ricche di testo. Aggiungono anche l'ipertesto del codice per scopi di esplorazione. Non è necessario inserire tag speciali per la formattazione di base.

Questo non è comunque WYSIWYG.

Ho paura di dire che questo esiste.

In passato ho lavorato su alcuni Centura (noto anche come Gupta o SQL / Windows - un vecchio " 4GL ") codice. Non era davvero possibile modificare il codice Centura in un editor standard come il blocco note al livello estremo di formattazione richiesto.

Sebbene possa sembrare una buona idea avere un file sorgente formattato in questo modo, ho trovato che lo sviluppo è piuttosto restrittivo e doloroso.

Inoltre, la formattazione ha spesso causato problemi durante l'unione nel controllo del codice sorgente.

Oltre alle altre risposte, vorrei sottolineare che oltre alle difficoltà tecniche dell'uso della formattazione avanzata, è anche oggetto di preferenze personali.

Se modifichi il testo normale, puoi scegliere i caratteri e i colori che ti piacciono e sono impostati automaticamente. Se modifichi il rich text, cosa succede se non ti piacciono determinati colori e caratteri che sono impostati manualmente?

Penso che questo sia dovuto al fatto che nessuno ha ancora separato la lettura del codice e la scrittura del codice. Almeno non diventa mainstream. A volte devi leggere il codice che hai contattato molto tempo fa o il codice creato da altri sviluppatori. Probabilmente dovrai passare molto tempo prima di essere pronto a cambiare un singolo byte in questa fonte. Questa potrebbe essere la modalità di "lettura" che può fare tutto ciò che è necessario per una comprensione più semplice (dimensione del carattere, riformattazione, sottocampo, super-script, ecc.). Quando sei pronto, l'editor può passare alla modalità "scrittura" ed essere meno restrittivo e più obbedire alla "regola della sorpresa minima"