views:

213

answers:

9

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?

+7  A: 

I 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.

Tomalak
+1. I do the same except I usually use FileFullPath for the fully qualified name with path.
Mitch Wheat
+1  A: 

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 ) "

Kent Fredric
Point taken -- I've clarified the question.
Roger Lipscombe
This really depends on the size of the method or block. I would agree for class variables, but for three line utility methods, "file" and "filename" are perfectly fine.
Randy Stegbauer
@Randy, it depends on how generic that function is.
Kent Fredric
@Kent, Amen! I've edited my answer to indicate that as well.
Randy Stegbauer
A: 

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

Randy Stegbauer
A: 

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)
Joe
+1  A: 

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 of Folder abstraction in the code.

.NET sometimes uses path to refer to a file, and sometimes uses filename.

Roger Lipscombe
A: 

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.

Paul
+1  A: 

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.

Konrad Rudolph
Yes, but it's also a file with a name, so capitalizing it doesn't hurt. :-)
tvanfosson
I think I must have started programming before the word was added to the dictionary. That makes me feel really old. :-(
tvanfosson
+2  A: 

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.

tvanfosson
A: 

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')
J.F. Sebastian