Un modo semplice per rendere i vecchi file javascript conformi al nuovo standard di quotatura?

3

Abbiamo appena iniziato a mettere le linting sul posto di lavoro, e molti sviluppatori non si sono resi conto che i nostri standard richiedevano il doppio virgolette ovunque. Circa il 50% della base di codice usa virgolette singole, quindi non è più semplice cambiare la regola che rendere il vecchio codice conforme. C'è uno strumento o un'utilità che potremmo usare per correggere automaticamente i vecchi file? Va bene se dobbiamo verificare l'output dopo, è molto più facile trovare problemi in alcuni casi limite che aprire e regolare ogni singolo file in una base di codice di grandi dimensioni.

Prima:

var foo = 'bar'
var bat = 'baz: "stuff"'

Dopo:

var foo = "bar"
var bat = 'baz: "stuff"' //allowed

Sono aperto a qualsiasi metodo, incluso l'utilizzo di uno strumento esistente, usando espressioni regolari in una sorta di file perl o batch, qualsiasi cosa per evitare di spendere grandi quantità di tempo umano per correggere quello che è in definitiva un problema minore scritto su più basi di codice . La vastità del problema dissuade le persone dal tentare di risolverlo, e mi piacerebbe un modo per aiutare in questo. Per favore lasciate la discussione sulla saggezza di questa opzione, poiché questa è solo una delle molte opzioni che sto esaminando - se c'è un modo semplice per affrontarla, allora i responsabili della squadra vorranno saperlo, e se non lo è, ciò influenzerà anche la discussione.

Tieni presente che questa è solo la regola più ovvia ora che gli standard di sfilacciamento sono in vigore. Sarebbe anche utile qualsiasi cosa in grado di correggere anche altri errori (il doppio equo in cui era necessario il triplo).

    
posta Yamikuronue 10.12.2014 - 02:42
fonte

4 risposte

10

Come @MainMa ha ben evidenziato, il problema tecnico potrebbe essere risolto con un certo sforzo, ma non facilmente senza il rischio di introdurre alcuni bug nascosti nella base di codice (e il rischio è alto se il codebase è grande, e probabilmente non avresti fatto una domanda del genere per una piccola base di codice).

Vedi questo in contrasto con il fatto che questa regola standard di codifica sembra servire solo alcuni criteri formali, ma non davvero migliorare la leggibilità. In una situazione del genere, penso che dovresti discuterne con il tuo team e chiedere se la regola è davvero così importante, poiché

  • con o senza la regola, tutti i membri del tuo team devono sapere che le stringhe letterali in javascript possono essere create con virgolette singole o doppie (il tuo esempio lo mostra chiaramente)

  • hai un sacco di problemi senza alcun beneficio con il tuo codice esistente

  • ogni volta che copi e incolli del codice da qualche altra parte, incontrerai la stessa seccatura

Ti suggerisco di chiedere al tuo team di rimuovere quella regola dal tuo standard - gli standard di codifica dovrebbero servirti, non viceversa. Forse lo lasciano come raccomandazione per un nuovo codice scritto, ma non obbligatorio.

    
risposta data 10.12.2014 - 08:04
fonte
2

Dato il tuo esempio, in particolare la parte in cui le virgolette singole non vengono sostituite, non credo che una soluzione pronta per l'uso faccia il lavoro per te. Immagino che scrivere uno strumento personalizzato che usa un tokenizzatore JavaScript sia troppo complicato.

D'altra parte, puoi sostituire automaticamente le virgolette singole con virgolette doppie. Con le espressioni regolari, puoi andare abbastanza lontano da gestire casi in cui una singola stringa tra virgolette contiene virgolette doppie. Naturalmente, ci possono essere casi [praticamente] impossibili da gestire con espressioni regolari, come ad esempio:

var a = "'Hello \\"World's.'"

Il problema che rimane è di evitare regressioni durante la sostituzione dei caratteri.

  • Se hai test unitari con copertura sufficiente, probabilmente stai bene. Esegui questi test molto spesso durante la procedura per individuare la posizione di un errore, se presente.

  • In caso contrario, uno dei modi per trovare le regressioni è utilizzare Closure Compiler . Genera risultati coerenti indipendentemente dalle virgolette che usi (tutte le virgolette singole sono sostituite da virgolette doppie). Durante la sostituzione delle virgolette singole con virgolette doppie, esegui regolarmente il compilatore di chiusura e verifica che l'output sia esattamente uguale a quello che avevi all'inizio.

risposta data 10.12.2014 - 06:43
fonte
1

Ho fatto alcune cose simili (migrando un'applicazione VB3 a VB4, per esempio) con alcuni script perl. Gli script prenderebbero il file originale e produrranno due nuovi file: uno il file di output (con le correzioni) e l'altro un elenco delle modifiche / sostituzioni eseguite, nonché i messaggi che indicano che qualcosa di insolito è stato visto e non è stato modificato. Ho trovato questo più facile da leggere rispetto a un diff (che puoi facilmente generare se preferisci questo). La chiave sembra essere quella di creare un file di esempio con tutte le permutazioni a cui puoi pensare ed eseguire il tuo script contro di esso fino a quando non hai ragione. Quindi eseguilo sul tuo file più grande / più impegnativo e controlla a mano l'output per assicurarti che tutto funzioni correttamente. Se il tuo codice è sotto il controllo del codice sorgente, puoi facilmente tornare alla versione originale se le cose non funzionano correttamente, ma per un problema ben definito un buon script dovrebbe farti ottenere il 99% delle volte.

    
risposta data 10.12.2014 - 19:55
fonte
-1

Come sottolineato da altri, fare tutto automaticamente potrebbe introdurre bug. Lo sviluppo del software è spesso basato sulla valutazione dell'automazione di un processo semplicemente eseguendolo manualmente; spesso finisce un po 'di entrambi. Consiglierei di eseguire manualmente questa particolare attività, magari con qualche ricerca e sostituzione, ogni file uno per uno.

  1. Ottieni un elenco di file da modificare.
  2. Ogni codificatore può eseguire le modifiche su 1-2 file al giorno. Con la svista della modifica delle virgolette, possono correggere anche altri codici non standard.
  3. Contrassegnali come sono cambiati.

Non ho idea di quanti file ci siano, ma se ci sono 100 file, ci vorrebbero meno di 3 settimane per cambiarli tutti con 5 programmatori che lavorano su di essi.

    
risposta data 05.07.2016 - 03:07
fonte

Leggi altre domande sui tag