If I've got a variable that contains the fully-qualified name of a file (for example, a project file), should it be called projectFile
, projectFileName
or projectPath
? Or something else?
views:
213answers:
9I usually go with these:
FileName
for the file name only (without path)FilePath
for the parent path only (without the file name)FileFullName
for the fully qualified name with path
I don't think there is such a thing as an accepted standard for this. I depends on your (team's) preferences and whether you need to differentiate between the three in a given situation.
EDIT: My thoughts on these particular naming conventions are these:
- intuitively, a "Name" is a string, so is a "Path" (and a "FileName")
- a "Name" is relative unless it is a "FullName"
- related variable names should begin with the same prefix ("File" + ...), I think this improves readability
- concretions/properties are right-branching: "File" -> "FileName"
- specializations are left-branching: "FileName" -> "ProjectFileName" (or "ProjectFileFullName")
- a "File" is an object/handle representing a physical object, so "ProjectFile" cannot be a string
I cannot always stick to these conventions, but I try to. If I decided to use a particular naming pattern I am consistent even if it means that I have to write more descriptive (= longer) variable names. Code is more often read than written, so the little extra typing doesn't bother me too much.
You should title it after the file it is likely to contain, ie:
system_configuration_file_URI
user_input_file_URI
document_template_file_URI
"file" or "filename" is otherwise mostly useless
Also, "file" could mean "I am a file point" which is ambiguous, "filename" doesn't state whether or not it has context ( ie: directories ), fileURI is contextwise unambiguous as it says "this is a resource identifier that when observed, points to a resource ( a file ) "
All of this depends partly on the size of the method and if the variables are class variables.
If they are class variables or in a large complicated method, then follow Kent Fredric's advice and name them something that indicates what the file is used for, i.e. "projectFileName".
If this is a small utility method that, say, deletes a file, then don't name it "projectFileName". Call it simply "filename" then.
I would never name it "path", since that implies that it's referring to the folder that it's in.
Calling it "file" would be OK, if there were not also another variable, like "fileID" or "filePtr".
So, I would use "folder" or "path" to identify the directory that the file is in.
And "fileID" to represent a file object.
And finaly, "filename" for the actual name of the file.
Happy Coding,
Randy
I don't think there's a consensus on this, just try to be consistent.
Examples from the .NET Framework:
FileStream(string path...);
Assembly.LoadFrom(string assemblyFile)
XmlDocument.Load(string filename)
Even the casing of filename (filename / fileName) is inconsistent in the framework, e.g.:
- FileInfo.CopyTo(string destFileName)
Some thoughts:
projectFile
might not be a string -- it might be an object that represents the parsed contents of the file.projectFileName
might not be fully-qualified. If the file is actually"D:\Projects\MyFile.csproj"
, then this might be expected to contain"MyFile.csproj"
.projectPath
might be considered to be the fully-qualified path to the file, or it might be considered to be the name of the parent folder containing the file.projectFolder
might be considered to hold the name of the parent folder, or it might actually be an implementation of some kind ofFolder
abstraction in the code.
.NET sometimes uses path
to refer to a file, and sometimes uses filename
.
Based on the above answers of the choices being ambiguous as to their meaning and there not being a widely accepted name, if this is a .NET method requesting a file location then specify in the XML comments what you want, along with an example, as another developer can refer to that if they are unsure of what you want.
Notice that “filename” is one word in English! There's no need to capitalize the “n” in the middle of the identifier.
That said, I append Filename
to all my string variables that contain filenames. However, I try to avoid this whole scenario in favour of using strongly typed variables in languages that support a type of files and directories. After all, this is what extensible type systems are there for.
In strongly typed languages, the need for the descriptive postfix is then often unnecessary (especially in function arguments) because variable type and usage infers its content.
System.IO.Path seems to refer to the fully qualified name of the file as the path
, the name of the file itself as filename
, and its containing directory as directory
. I would suggest that in your case projectPath
is most in keeping with this nomenclature if you are using in the context of System.IO.Path. I would then refer to the name of the file as fileName
and it's containing directory as parentDirectory
.
It depends on naming conventions used in your environment e.g. in Python the answer would be projectpath
due to naming conventions of os.path module.
>>> import os.path
>>> path = "/path/to/tmp.txt"
>>> os.path.abspath(path)
'c:\\path\\to\\tmp.txt'
>>> os.path.split(path)
('/path/to', 'tmp.txt')
>>> os.path.dirname(path)
'/path/to'
>>> os.path.basename(path)
'tmp.txt'
>>> os.path.splitext(_)
('tmp', '.txt')