Analisi statiche per trovare le incoerenze tra maiuscole / maiuscole nei nomi dei file

0

TLDR; Sto cercando idee su come contrassegnare il codice contenente nomi / percorsi di file che hanno incoerenze incoerenti con il file / directory reale.

Situazione

Sto migrando una base di codice significativa scritta in un linguaggio interpretato da un ambiente di sviluppo Windows / OSX e un ambiente di produzione di Windows in ambiente Linux prod e dev (tramite vagabondo).

Il problema è che ho scoperto nel corso degli anni che vari sviluppatori sono stati negligenti nel garantire che i riferimenti ai file abbiano una capitalizzazione coerente con il file effettivo.

Questo non è solo un problema per includere altri file di codice, ma anche per fare riferimento ai nomi dei modelli e alle classi di caricamento automatico dal loro nome. Ad esempio, qualcuno potrebbe eseguire il rendering di un modello facendo riferimento a mytemplate ma il file effettivo è chiamato myTemplate.html , oppure fanno riferimento a MyClass ma il file è chiamato Myclass .

In precedenza, gli sviluppatori non erano riusciti a notare queste istanze perché utilizzano i file system senza distinzione tra maiuscole e minuscole che nascondono il problema. Ora che l'ambiente di produzione fa distinzione tra maiuscole e minuscole, un mucchio di bug solitamente oscuri è causato da incoerenze del caso.

Domande

  1. Qual è il modo migliore per identificare possibili istanze di questo tramite l'analisi statica del codice.

Mi sono reso conto che occuparsi di questo in modo reattivo (cioè in risposta a segnalazioni di bug) è insufficiente - ho bisogno di trovare tutte le istanze in cui questo è probabilmente un problema e riesaminarlo manualmente, ma trovare ogni istanza è scrupoloso. Speravo che potesse esserci uno strumento di analisi statica esistente per questo tipo di problema, ma non sono riuscito a trovarne uno.

Stavo pensando di mettere insieme qualcosa che elencasse tutti i nomi di file e directory, quindi cercare nel codice qualsiasi riferimento a questi, ma con un caso diverso. Questo non sarebbe particolarmente intelligente, ma probabilmente funzionerebbe (anche se probabilmente ci sarebbe un numero significativo di falsi positivi dai nomi delle variabili, ecc.).

  1. Come posso evitare che ciò accada in futuro

Mentre gli sviluppatori utilizzano ora un ambiente dev di Linux, le cartelle condivise vaganti non fanno distinzione tra maiuscole e minuscole (almeno sui sistemi Windows). In alcuni casi sono stato in grado di aggiungere condizioni di "fast-fail" (quindi controlla esplicitamente il caso e fallisce se non corrispondono, anche se l'operazione del file ha esito positivo), ma non posso farlo dove file i percorsi vengono passati direttamente in una funzione nativa, ad esempio. I test unitari su un ambiente di produzione sono una soluzione, ma alcuni di questi problemi si verificano all'interno dei modelli (ad esempio somefile.js rispetto a someFile.js ) che è difficile da testare.

    
posta thexacre 17.01.2015 - 04:05
fonte

1 risposta

3

Questo è un compito che sfida l'analisi statica. Ad esempio il codice non improbabile

def open_me(dir_path, filename, extension):
    return open(dir_path + filename + extension)

sarebbe difficile da prendere. Di fronte a un problema insolubile, utilizzare l'euristica. Vorrei andare in entrambe le direzioni con questo.

  1. Supponiamo che ogni nome di file nell'albero sia un candidato per essere referenziato in ogni file. Aggiungerei anche ai candidati someFile per ogni someFile.js . Quindi cerca l'intera base di codice per le istanze dei candidati e segnalali come possibili difetti che devono essere esaminati. Raccomando di inserire gli occhi nel ciclo perché non vuoi ricevere commenti e stringhe letterali che potrebbero non essere nomi di file. Noioso? Certo.
  2. La seconda direzione è di esaminare ogni open() o una funzione simile per le cose simili ai nomi dei file. Anche questo è noioso.

C'è un solo modo per impedire che ciò accada in futuro:

  1. Imposta un criterio e applicalo tramite le revisioni del codice. Sei andato su una nuova piattaforma che ha vincoli di portabilità aggiuntivi. A causa del open_me di cui sopra, è necessaria una disciplina aggiuntiva da parte del team di sviluppo.
risposta data 17.01.2015 - 04:47
fonte