Come ti sentiresti se il tuo editor di codice avesse formattato il tuo codice per te mentre hai digitato, senza tab / spazi? [chiuso]

Il problema più grande sarebbe come i file apparirebbero ad altri strumenti, in particolare gli strumenti di controllo della versione. Le terminazioni di linea sono significative per questi strumenti. Non vorrei vedere una schermata di fusione in cui ho un'intera classe in una riga e provare a unire parte del testo nella colonna 347.

Sarebbe fantastico. Emacs lo fa più o meno, e soprattutto lo fa bene. Hai provato la modalità nXML di Emacs? Come miglioreresti su questo?

Non puoi creare un nuovo editor finché non hai campionato ciò che è già disponibile.

In ogni caso, il rientro deve essere salvato nel file di output, in modo che il file possa essere visualizzato con altri strumenti. Non sono propenso ad adottare un nuovo editor a meno che non supporti la personalizzazione in fase di esecuzione come Emacs.

Ho già visto questa idea, ma non l'ho mai vista funzionare davvero. Il più delle volte, quando ho visto l'idea venire fuori, è stata abbattuta da tutti gli sviluppatori là fuori - o quando è stata implementata, rendeva praticamente inutile il controllo della versione semplicemente come la visualizzazione del codice piegato cambierebbe il file e confonderebbe ulteriormente lo strumento diff. (Un esempio di quanto sia pessimo è lo Witango Development Studio.)

Posso pensare a diversi ostacoli che il tuo editor dovrebbe superare per essere utile a molti sviluppatori:

• Le modifiche a un file non devono creare rumore nel comando * nix diff -uw . (Nessuna diff spuria!)
• La modifica di un file (precedentemente non formattato) non deve complicare l'unione negli strumenti SCM.
• Deve giocare bene con altri editor usati dal team di sviluppo.
• Gli utenti devono essere in grado di personalizzare la formattazione in base al contenuto dei loro cuori: alcune persone sono piuttosto appassionate di come viene visualizzato il loro codice.
• Le modifiche al codice esistente non devono modificare la formattazione esistente. È fondamentale che l'editor non riformatti improvvisamente un intero file senza una ragione apparente e non modifichi la formattazione di una riga per semplici modifiche secondarie, il che confonderà gli strumenti diff e la rabbia degli altri membri del team.
• Probabilmente non dovrebbe eliminare gli spazi bianchi in eccesso - probabilmente spaccherà qualcuno . Meglio non rischiare.
• Le nuove righe aggiunte a un file devono essere conformi alle impostazioni delle modeline esistenti o devono essere conformi alla formattazione locale (entro +/- 3 righe).
• L'editor dovrebbe avere un pannello delle impostazioni che consente all'utente di definire la politica di formattazione del codice del team che è separata da ciò che l'editor effettivamente mostra.

Inutile dire che è ovvio che questo richiederà una certa quantità di metadati sulla formattazione esistente del file. Probabilmente vorresti tenerlo separato dai sorgenti, ma tenerlo sincronizzato con un repository in continua evoluzione sarebbe probabilmente piuttosto difficile.

Come utente Vim, vorrei anche considerare che l'editor dovrebbe rispettare le modeline di Vim, Emacs e di altri editor e preservare la formattazione proscritta della modeline, indipendentemente da ciò che visualizza alla fine.

A mio parere, i requisiti per tale software lo rendono insostenibile. Troppi utenti se ne aspetteranno troppo spesso per rendere un tale progetto un successo.

Soluzione, utilizzando file di configurazione del formattatore basati su testo (ad esempio, XML):

• Avere un formattatore personale configurato dal singolo sviluppatore.

  • Archivia questo formattatore localmente.

  • I file sono caricati e modificati con la formattazione locale.

  • Possono cambiare liberamente il loro stile di formattazione senza rompere nulla.

  • La formattazione automatica può essere disattivata per visualizzare e modificare file raw.

• Avere un formatter team minimo configurato per lo standard del team.

  • Archivia questo formattatore nel controllo della versione del team.

  • I file sono salvati con la formattazione del team come riserva per altri strumenti.

  • Gli spread non soffrono di problemi di formattazione.

È ridicolo preoccuparsi dell'economia di salvare i file senza spazi bianchi, quindi non si perde nulla salvando i file con una qualche formattazione definita da uno standard di squadra. Nel caso di uno sviluppatore solista, potresti offrire la possibilità di avere formattazione salvata (per il "team" di una) formattazione del mirroring.

Quando il formattatore è insufficiente, hai due opzioni valide:

• Esporre un'interfaccia per i formattatori personalizzati.

  • Fatto bene, questa è la soluzione migliore.

  • Fatto male, è il peggiore.

• Consenti sovrascrittura manuale della formattazione automatica.

  • L'usabilità non soffre: considera Ctrl- (Invio | Tab | Spazio).

  • Sanity fa-dove salvi questa formattazione? Hai?

Sarebbe ok se il codice fosse autoformato se la lingua non fosse sensibile al formato cough Python cough .

Emacs rende la formattazione Lisp veramente bella, e formattata al volo sarei abbastanza felice. Non sopporto l'inserimento automatico di parentesi o altri delimitatori: nessuno degli auto-inseritori che ho provato lo ha avvicinato a destra per come digito.

Mi piace l'idea nel concetto . E mentre ci riesci, non ho ancora trovato un editor che faccia tutto sufficientemente da fare in termini di formattazione. Ecco alcuni roadblock (IMO):

• Linguaggi in bianco e nero
• Cosa viene salvato in uscita? (Dovresti, almeno in parte, salvare almeno alcuni dei rientri in modo che rimangano leggibili agli altri senza lo strumento)
• Deve assolutamente giocare bene con i prodotti di controllo delle versioni / sorgente già esistenti
• Deve essere altamente personalizzabile, specialmente per quelli di noi (me inclusi) che sono molto, molto, molto schizzinosi su come il codice viene formattato e rientrato (e dove quella virgola dovrebbe andare in una lista , ma se la lista è molto lunga, come devono essere interrotte le linee, ecc.)
• Deve veramente capire la lingua. Con questo intendo che deve seguire la lingua esattamente come il compilatore lo capirà. Ho avuto troppi editor con una sintassi colorata che ha sbagliato la sintassi perché c'è qualche aspetto pazzo del linguaggio che non può essere semplicemente gestito con un RegExp. Certo, hai indicato che avresti continuamente analizzato la lingua, ma chi può dire che ciò che si analizza è conforme al compilatore che sto usando? (Credetemi, ci sono molti standard là fuori, e ci sono molti affari divertenti che avvengono nella maggior parte delle lingue, incluso il codice che sembra sbagliato in un semplice parser, ma è perfettamente corretto per il compilatore.)
• Deve essere veloce . Ed ecco dove la gomma incontra la strada: non è possibile eseguire una compilazione completa sul mio codice ogni volta che si preme un tasto (specialmente con un progetto di grandi dimensioni), a meno che non si possa ottimizzare il parser all'ennesima potenza. Se nell'editor c'è persino un accenno di lentezza, nessuno lo userà. (Sono un perfetto esempio di abbandono di editor lenti a favore di quelli più veloci. Se è in ritardo, sono fuori.)

Potresti creare qualcosa che soddisfi la maggior parte dei criteri ragionevolmente bene? Probabilmente. Ma noi programmatori siamo pignoli e schizzinosi e detestiamo cambiare e salperanno al primo segnale di guai. Qui ci sono problemi se l'output fa tic tac qualcun altro sul team di sviluppo, o se non funziona al 100% con il sistema di controllo delle versioni, o se non formatta il mio codice esattamente così o se fraintende il linguaggio e azzarda il mio codice, o se è in ritardo di un millisecondo rispetto a quello che mi aspetto. Perché, per quanto mi spiace, salterò i miei editor preferiti in un batter d'occhio.

Esiste un approccio ancora più radicale: un puro editor semantico. Un IDE si occupa di un codice che è addirittura rappresentato internamente come un AST, non un testo semplice. Per esempio, vedi JetBrains MPS .

Ora che ho pubblicato l'editor XML descritto nella mia domanda, sono in una posizione migliore (ma non ideale) per tentare di rispondere a me stesso, quindi lo farò:

Dopo oltre 500 download in meno di 2 settimane, la reazione a questo nuovo rivoluzionario concetto di formattazione dinamica del codice è stata ...

NIL

Nessuna lamentela, nessuna lode. La mia (promettente) interpretazione di questo è che le persone vogliono e si aspettano un editore che si senta normale e non rovini il loro codice. Gli utenti noteranno a malapena che la loro formattazione è interamente virtuale e le prove suggeriscono che si preoccupano ancora meno.

Sarebbe un errore leggere troppo in questa non-reazione, questo strumento è gratuito, e sfortunatamente questo significa che almeno alcuni utenti saranno meno inclini a criticare. Se a loro non piacesse, potrebbero semplicemente averlo scartato e usato qualcos'altro.