Qual è un termine ampiamente accettato per una variabile stringa che probabilmente conterrà un percorso file e un nome file?

4

Per le funzioni che hanno bisogno di indicizzare i file in una directory e rinominarli FileName0001, FileName0002, ecc. Spesso ho bisogno di scrivere una funzione che divide il nome del file dal percorso del file e rinomina il file. Quando rimetto insieme il nome del file e il percorso del file, non ho un buon nome per la variabile che li contiene entrambi e di solito finisco per concatenarli ogni volta che voglio usarli (di solito li uso come parametri per le funzioni con nome file o percorso file), quindi non so mai veramente cosa sto facendo fino a quando non noterò molti file scritti nella stessa directory dei miei binari.

Ad ogni modo, come faccio a chiamare un nome file e un percorso file? Non voglio chiamarlo File, perché di solito significa le informazioni binarie dietro il file. Non voglio chiamarlo URI perché questo di solito significa che ho una sorta di protocollo, cosa che non lo faccio. Voglio solo un buon modo per indicare "c: \ somedir \ somedir \ somedir \ somefile.txt" in modo da sconcertare questo casino che ho appena realizzato.

Per favore non limitarti a elencare le tue preferenze personali. Penso che una risposta eccellente dovrebbe "localizzare le sue fonti". (come in, fornire un collegamento a un repository con un buon esempio del codice utilizzato come descritto)

    
posta Peter Turner 30.05.2012 - 17:12
fonte

9 risposte

14

Un percorso dalla radice del file system al file, incluso il nome del file, è solitamente chiamato percorso completo . Se il percorso non torna alla radice, è un percorso relativo . Se non include il nome del file, è un percorso di directory .

    
risposta data 30.05.2012 - 17:42
fonte
6

Uso fileWithPath . È rozzo ma esplicito.

    
risposta data 30.05.2012 - 17:18
fonte
6

Perché non chiamarlo "Percorso"? Da Wikipedia :

A path, the general form of a filename or of a directory name, specifies a unique location in a file system

    
risposta data 30.05.2012 - 17:15
fonte
6

Nel tempo delle nuvole e su Internet, mi piace usare uri . C'è anche un RFC . L'unico problema che vedo con questa convenzione di denominazione è, quando si utilizza un linguaggio di programmazione come C #, in cui Uri è un oggetto contenente un Uri (ovviamente). Quindi sarebbe piuttosto strano nominare un String uri . Questo è il motivo per cui utilizzo sempre l'oggetto Uri se è disponibile o ne creo uno.

Detto questo, penso che uri sia la scelta migliore, poiché il percorso indicato potrebbe e dovrebbe essere universale .

    
risposta data 30.05.2012 - 18:13
fonte
3

What is a widely accepted term

Non c'è niente del genere. Scegli il nome che ti piace di più (il mio preferito è fullFileName ).

    
risposta data 30.05.2012 - 17:34
fonte
2

Come molti altri hanno suggerito, usa qualcosa che funzioni per te. Se crei uno schema, seguilo e spiegalo nella documentazione (stai documentando il tuo lavoro, vero?). Il tuo schema durerà più a lungo, se sarai in grado di estenderlo per coprire diversi file e percorsi diversi. Ciò che sembra funzionare bene sarebbe costruire le variabili di mantenimento dei nomi dei file in un unico punto di configurazione centrale, ad esempio

  • MyProjectRoot ... Root dei file di progetto da anteporre alle sottodirectory
  • MyConfigDir = MyProjectRoot + "/ conf"
  • MyConfigFile = MyConfigDir + "/complicatedconfiguration.xml"

In questo modo, non solo rendi evidente ciò che i singoli nomi di file rappresentano, ma ottieni anche un posto in cui tu (o qualcun altro che lavora con il tuo codice in un secondo momento) puoi applicare cambiamenti che rifletteranno in modo coerente nel tuo progetto.

Per il tuo progetto specifico, sarei più preoccupato di confondere sorgente e destinazione, quindi mi piacerebbe andare con

  • SourcePath , TargetPath per il componente del percorso
  • FileName (o BaseName ) per il componente filename comune a entrambi (o SourceBaseName / TargetBaseName se non sono comuni a entrambi)
  • e possibili SourceFile e TargetFile per Path + Nome file

E lo spiegherei nel preambolo del programma / script.

Se vuoi essere molto esplicito che il tuo componente FileName non contiene alcun componente di percorso, puoi chiamarlo BaseName.

Quindi la tua intera cosa è fondamentalmente costruita da

  • /AbsolutePath/BaseName.Extension
  • ./RelativePath/BaseName.Extension

combinato con qualificatori come Source o Target

    
risposta data 30.05.2012 - 18:05
fonte
1

Utilizziamo

fileName = mystuff.txt              
dirName = c:\data\mydocs
pathName = c:\data\mydocs\mystuff.txt
    
risposta data 30.05.2012 - 19:33
fonte
1

Questo di tanto in tanto differisce molto, ma quello che faccio di solito è usare nomi lungo le linee di absoluteDirectoryPath , absoluteFilePath , relativeDirectoryPath , relativeFilePath , directoryName e fileName . Questo dipende dal fatto che voglio accedere solo alla directory o all'intero percorso dove si trova il file.

Oltre a questo, i nomi probabilmente rifletteranno anche per es. che tipo di logica aziendale stanno influenzando o il contenuto dei file.

    
risposta data 31.05.2012 - 16:14
fonte
1

Per divertimento, ecco un'altra prospettiva. Ho lavorato al sistema di gestione delle risorse di un grande gioco online 10 anni fa. Ecco alcuni dei concetti che ho concluso per consentire flessibilità e scalabilità.

  • un file (per il mio design al momento) potrebbe contenere più "file", quindi
  • i dati che compongono un file sono chiamati record
  • i dati del record si trovano in un'origine dati (ad esempio: il diskdrive è un tipo di origine dati). i server web / ftp / remoti sono esempi di altre fonti di dati

Un record è stato accompagnato da una "bolla di accompagnamento" (metadati che include l'hash MD5 a 64 bit, le regole di memorizzazione nella cache, ecc ...). Il documento di trasporto ha anche specificato il "Nome persistente" del record che era il "percorso completo + nome file" per l'origine dati local_disk.

Con il passare degli anni, ho aggiunto la complessità di quest'area di studio con la nomenclatura URI e URL. la fonte dei dati è in effetti lo "schema". quindi "file: /// blablabla

Anch'io combatto ancora con questo a volte. Basta tenere i file in un posto, caricare i dati in memoria e il tipo di problema va via :)

    
risposta data 01.06.2012 - 07:35
fonte

Leggi altre domande sui tag