Stavo leggendo Code Complete e nel capitolo su layout e stile, prevedeva che gli editor di codice avrebbero usato una sorta di formattazione rich text. Ciò significa che al posto del codice appare così

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.

potrebbe assomigliare a questo:

Procedura ResolveCollisions

Esegue una risoluzione delle collisioni a posteriori attraverso l'algoritmo di partizionamento spaziale

parametri

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

Variabili locali

• Collider : Sprite
• Collidee : Sprite
• Collision : SpriteCollision

    DoStuff();

Ho visto la colorazione e l'evidenziazione della sintassi e persino la colorazione tra parentesi, ma nulla di simile a questo nel codice reale. Mi chiedevo se questo genere di cose fosse realmente esistito, o forse se fosse stato deciso che non aveva abbastanza benefici o che fosse una cattiva idea.

Qualcuno di voi ha mai visto un codice così formattato come questo prima o sa se l'idea è mai stata presa in considerazione e alla fine respinta?

Non vi è alcun motivo tecnico per cui non sia possibile. Se gli editor di testo possono evidenziare la sintassi, possono altrettanto facilmente cambiare altri aspetti del display per evidenziare il codice.

Tuttavia, una cosa è che qualsiasi cosa venga digitata cambia colore mentre l'editor capisce cosa stai scrivendo. Avere il testo cambia improvvisamente dimensioni e saltare mentre stai scrivendo diventerebbe davvero odioso.

Tuttavia, per una visualizzazione del codice "statico", è possibile abbellire facilmente il codice sorgente. Ad esempio, prendi qualsiasi convertitore source-> html a metà strada decente e aggiungi le dimensioni e gli stili dei caratteri che ti piacciono ai fogli di stile e avrai un ricco codice formattato.

Motivo semplice: indipendenza dell'editor / strumento.

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

Allo stesso modo, il rich code non funzionerebbe bene con gli strumenti diff. Ad esempio, se hai appena cambiato un po 'di formattazione, il diff mostrerà una differenza, ma non è nemmeno una differenza di cui ti preoccupi di meno.

E il controllo delle versioni? Come diresti di ignorare tutte le modifiche nella formattazione e di vedere i file modificati solo quando c'è un cambiamento "reale".

Infine, immagino che l'intero punto del rich code sia la leggibilità - e per questo, penso che saranno sufficienti (e più) commenti, nomi di identificatori logici e rientro coerente.

In sostanza, il testo di programmazione è meglio gestito come un semplice testo: quello che vedi è la realtà. ( che è anche in linea con l'idea Pythonic di esplicito meglio di implicito )

Forse il codice riccamente formattato non ha preso piede perché non è una buona idea. Personalmente, non mi piace quello che vedo nell'esempio che hai fornito. Uso la colorazione e l'evidenziazione della sintassi, ma quella 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 attuali editor sono in grado di soddisfare le esigenze dei programmatori con l'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 apice vengono ridimensionati in modo appropriato e puoi anche avere piccole anteprime di matematica (e forse altri ambienti come Algorithmic).

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

Un'altra cosa che Emacs può fare è sostituire simboli come ->e forallcon →e ∀rispettivamente in Haskell. Ci sono pochi motivi per cui questo genere di cose non può essere esteso alla formattazione come stai suggerendo, tranne per il fatto che non è affatto necessario in Haskell.

Qualche tempo fa, ho posto questa domanda sulla formattazione del codice, chiedendo se i programmatori avrebbero voluto che il loro codice fosse formattato durante la digitazione.

La mia domanda riguardava solo l'aspetto del rientro della formattazione, ma alcune risposte potrebbero applicarsi alla formattazione del codice in generale. Il sentimento generale nelle risposte suggerisce che i programmatori si oppongono alla perdita del controllo assoluto sul modo in cui il loro codice è rappresentato.

La mia esperienza personale è stata abbastanza diversa. Anche se normalmente utilizzo strumenti disponibili pubblicamente, a volte ho bisogno di scrivere XSLT nel mio editor su misura. Questo editor formatta il codice mentre digito indentando il margine sinistro, quindi non ho problemi con spazi bianchi indesiderati (significativi in ​​XSLT) e consente al mio codice di racchiudere le parole e mantenere comunque la formattazione. Trovo l'esperienza abbastanza naturale, lo stile di formattazione è controllato dal contesto e dalla posizione dei soli 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 effettivamente a mostrare dove si trova il problema. Ci è voluto un po 'di tempo per adattarsi allo spostamento del codice in orizzontale durante la digitazione, ma non è più una distrazione per me. Tuttavia, ho scoperto che le funzionalità di formattazione che influivano sulla spaziatura verticale della mia XSLT rendevano l'editor praticamente inutilizzabile, quindi le ho disabilitate.

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

Anche in più di alcune lingue (Haskell, Ruby, Python, Erlang, CoffeeScript alcune altre), il rientro è importante. Quindi, se stai modificando le dimensioni del carattere, potrebbe essere molto difficile da capire.

Principalmente la sua tradizione. Ho programmato professionalmente per quasi 20 anni e 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 per C / C ++ e Pascal. - Dovresti dare un'occhiata anche se ... è abbastanza pulito. Esistono due programmi: ctanglee cweaveche combinano / separano i file CWEB rispettivamente in TeX e C.

Qualcuno di voi ha mai visto un codice così formattato come questo prima o sa se l'idea è mai stata presa in considerazione e alla fine respinta?

Sicuro. Xcode supporta stili oltre alla semplice colorazione per diverse sintassi:

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

Tuttavia, non vuoi esagerare con gli stili: 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 tutto ciò che impedisce alle colonne di non allinearsi è fastidioso. C'è un motivo per cui la maggior parte dei programmatori utilizza ancora caratteri a spaziatura fissa.

Una domanda diversa è se il testo con stile debba essere usato come parte della sintassi del linguaggio stesso. Ad esempio, il compilatore dovrebbe usare il fatto che parte del testo è 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à il rientro come sintassi. Tuttavia, penso sia più probabile che continueremo a vedere lo stile guidato dalla sintassi piuttosto che viceversa. Ci sono molti vantaggi che derivano dalla possibilità di utilizzare il testo normale (compilatori più semplici, indipendenza dalla piattaforma, preferenze del programmatore) e altre tradizioni si sono evolute per rendere leggibile il codice in assenza di stili (rientro, righe vuote, caratteri marcatori e funzioni dell'editor come la piegatura del codice e i menu di navigazione).

Penso che la formattazione avanzata 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 anche più facili da digitare). Fontificazione, simboli extra speciali e spazi bianchi aggiungono solo rumore visivo non necessario. Tuttavia, potrebbe essere appropriato per la documentazione generata.

Non esiste una guerra alla fiamma senza fine sullo stesso argomento nel mondo della 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à una formattazione avanzata del codice di testo. Aggiungono anche ipertesto di codice ai fini della navigazione. Non è necessario inserire tag speciali per la formattazione di base.

Questo non è WYSIWYG però.

Ho paura di dire che esiste.

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

Anche se può sembrare una buona idea avere un file sorgente formattato in questo modo, ho scoperto che lo sviluppo è piuttosto restrittivo e doloroso.

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

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

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

Penso che questo sia perché 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 toccato molto tempo fa o il codice creato da altri sviluppatori. Probabilmente dovrai dedicare molto tempo fino a quando non sei pronto per cambiare un singolo byte in questa sorgente. Potrebbe trattarsi della modalità "lettura" che può fare tutto ciò che è necessario per una più facile comprensione (dimensione del carattere, riformattazione, sotto-script, super-script ecc.). Quando sei pronto, l'editor può passare alla modalità "scrittura" ed essere meno restrittivo e obbedire più "alla regola della minima sorpresa"