What is a widely accepted term for a string variable that would probably contain a file path and file name?

Question

For functions that need to index files in a directory and rename them FileName0001, FileName0002, etc... I often need to write a function that splits the file name from the file path and rename the file. When I put the file name and file path back together, I don't have a very good name for the variable that contains both of them and I usually just wind up concatenating them every time I want to use them (usually using them as parameters for functions labeled either filename or filepath) so I never really know what I'm doing until I notice a lot of files being written in the same directory as my binaries.

Anyway, what do I call a file name and a file path? I don't want to call it File, because that usually means the binary information behind the file. I don't want to call it URI because that usually means I've got some sort of protocol, which I don't. I just want a good way to denote "c:\somedir\somedir\somedir\somefile.txt" so as to deconfuse this mess I've just realized I'm in.

---

Please don't just list your personal preference. I think an excellent answer should "'site its sources". (as in, provide a link to a repository with a good example of the code being used as I described)

• yannis: I use filepath and dirpath.
• gnat: I'd consider fqn or FullyQualifiedName
• Erik Reppen: Don't sweat convention. Just make sure you pick an obvious name. I work with guys who hate typing so much they come up with conventions like p_mv1 for var names on the back end stuff. p means it came from a parameter I guess. That's not really the hard part to figure out. What I want to know is what the heck 'mv1' is supposed to stand for.
• Peter Turner: @ErikReppen Yeah, I'm not concerned about convention, only usability. What I've got is not useable and prone to bugs. It seems like we should never, ever have a variable called "FilePath"
• kevin cline: There is no "file path and file name". A file path includes a file name.

Answer 1

A path from the root of the file system to the file, including the file name, is usually called a full path. If the path doesn't go all the way back to the root, it's a relative path. If it doesn't include the file name, it's a directory path.

• Izkata: I've never seen "full path" before. "Absolute path" is pretty common, though.
• user29079: I have always used full path and I believe it is the common de-facto standard name.

Answer 2

Why not call it 'Path'? From Wikipedia:

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

• B Seven: Path sounds like the path to the file, excluding the file name: c:\somedir\somedir\somedir\
• Peter Turner: I wouldn't call it that because I don't ever want a directory name, I always want a file name.
• kevin cline: @BSeven: it may sound like that, the Wikipedia definition is the most common meaning for "path". A file path includes the file name. Without the file name, it's a directory path.
• user29079: Wikipedia can hardly be considered a widely-recognized computer science authority...

Answer 3

I use fileWithPath. It's clunky but explicit.

Answer 4

In the time of clouds and the Internet, I like to use uri. There's even a RFC. The only problem I see with this naming convention is, when you are using a programming language like C#, where Uri is an Object containing an Uri (of course). Then it would be pretty strange to name a String uri. This is why I always use the Uri object if it is available or create one.

That said, I think that uri is the best choice, since the path given could and should be universal.

Answer 5

What is a widely accepted term

There is nothing like that. Choose the name you like best (my personal favorite is fullFileName).

Answer 6

As many others suggested, use something that works for you. If you make up a scheme, stick to it, and explain it in the documentation (you're documenting your work, don't you?). Your scheme will last longer, if you are able to extend it to cover different files and different paths. What seems to work well would be to construct your filename-holding variables in one central configuration place, for example

• MyProjectRoot ... Root of your projects files to prepend to your subdirs
• MyConfigDir = MyProjectRoot + "/conf"
• MyConfigFile = MyConfigDir + "/complicatedconfiguration.xml"

This way, you not only make it obvious what the individual filenames are standing for, but you also gain a place where you (or someone else working with your code later on) can apply changes that will reflect consistently throughout your project.

For your specific project, I'd be more worried about mixing up source and target, so I'd go with

• SourcePath, TargetPath for the pathname component
• FileName (or BaseName) for the filename component common to both, (or SourceBaseName / TargetBaseName if they're not common to both)
• and possible SourceFile and TargetFile for Path+Filename

And I'd explain this in the preamble of the program/script.

If you want to be very explicit that your FileName component doesn't contain any path component, you could call it BaseName.

So your entire thing is basically constructed from

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

combined with qualifiers like Source, or Target

Answer 7

We use

fileName = mystuff.txt 
dirName = c:\data\mydocs
pathName = c:\data\mydocs\mystuff.txt

Answer 8

This differs a lot from time to time, but what I usually do is use names along the lines of absoluteDirectoryPath, absoluteFilePath, relativeDirectoryPath, relativeFilePath, directoryName and fileName. This depends on whether I want to access just the directory or the whole path to where the file is located as well.

In addition to this the names will also most likely reflect e.g. what kind of business logic they are affecting, or the content of the files.

• Peter Turner: Do absoluteFilePath and relativeFilePath in this context only mean the path of the directory? Or do they include the file as well?
• Andreas Johansson: Good call, edited my answer to hopefully make it less ambiguous. :)

Answer 9

For fun, here's another perspective. I worked on the asset management system of a large online game 10 years ago. Here is some of the concepts I concluded to allow for flexibility and scalability.

• a file (for my design at the time) could contain multiple "files" therefore,
• the data that makes up a file is called a record
• the record data is found in a data source (eg : the diskdrive is a type of data source). web/ftp/remote servers are examples of other data sources

A record was accompanied by a 'packing slip' (meta data including its 64 bit MD5 hash, caching rules, etc...). The packing slip also specified the record's "Persistent Name" which was the "fully qualified path + filename" for the local_disk data source.

As the years have passed, I've added to the complexity of this area of study with URI and URL nomenclature. the data source is in effect the "scheme". hence "file:///blablabla

I still battle with this too sometimes. Just keep the file stuff in one place, load the data into memory and the problem kind of goes away :)