Naming variables containing file names?

Question

If I have a variable that contains the full name of the file (for example, a project file), should it be called projectFile , projectFileName or projectPath ? Or something else?

Answer 1

I usually speak with them:

• FileName for file name only (no path)
• FilePath for parent path only (no file name)
• FileFullName for full name using path

I do not think there is an acceptable standard for this. I depend on your preferences (team) and whether you need to distinguish between three in this situation.

EDIT: My thoughts on these specific naming conventions are as follows:

• intuitively, "Name" is a string, so this is "Path" (and "FileName")
• "Name" is relative if it is not "FullName"
• variable variable names should start with the same prefix ("File" + ...), I think this improves readability
• nodules / properties are forked: "File" → "FileName"
• specializations have a fork on the left: "FileName" → "ProjectFileName" (or "ProjectFileFullName")
• A “file” is an object / descriptor representing a physical object, so “ProjectFile” cannot be a string

I cannot always adhere to these agreements, but I try. If I decide to use a specific naming pattern, I agree, even if that means I have to write more descriptive (= longer) variable names. The code is more readable than written, so a little extra typing doesn't bother me too much.

Answer 2

System.IO.Path seems to refer to the full file name as 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 consistent with this nomenclature if you use System.IO.Path in the context. Then I would like to name the file name as filename and contain the directory as parentDirectory .

Answer 3

You should smooth it after the file, which is likely to contain, i.e.

 system_configuration_file_URI user_input_file_URI document_template_file_URI 

"file" or "filename" otherwise basically useless

In addition, “file” can mean “I am a file point”, which is ambiguous, “file name” does not indicate whether it has a context (that is: directories), fileURI is contextually unambiguous because it says: “This is an identifier for a resource that when observed, indicates a resource (file) "

Answer 4

I don’t think there is consensus on this, just try to be consistent.

Examples from the .NET Framework:

• FileStream (path string ...);

• Assembly.LoadFrom (string assemblyFile)

• XmlDocument.Load (string file name)

Even the shell of the file name (file_name / file_name) is incompatible in the structure, for example:

• FileInfo.CopyTo (string destFileName)

Answer 5

Some thoughts:

• projectFile may not be a string - it may be an object that represents the parsed file contents.
• projectFileName may be incomplete. If the file is actually "D:\Projects\MyFile.csproj" , then it may contain "MyFile.csproj" .
• projectPath may be considered the fully qualified path to the file, or it may be considered the name of the parent folder containing the file.
• projectFolder can be considered that it contains the name of the parent folder or may be an implementation of some abstraction of Folder in the code.

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

Answer 6

Please note that " filename " is one word in English! There is no need to use "n" in the middle of the identifier.

Thus, I add Filename to all my string variables that contain the file names. However, I try to avoid all of this scenario in favor of using strongly typed variables in languages ​​that support file and directory types. After all, this is what extensible type systems are for.

In strongly typed languages, the need for descriptive postfix is ​​often not needed (especially in function arguments), because the type of the variable and its use pass its contents.

Answer 7

All this partially depends on the size method and if the variables are class variables.

If they are class variables or a complex method, follow Kent Fredric's advice and name them something that indicates that the file is being used, i.e. "projectFileName".

If this is a small utility method that, say, deletes a file, then do not call it "projectFileName". Call it simply "filename".

I will never call it "path", as this means that it refers to the folder in which it is located.

Calling this “file” will be OK if there was also no other variable, such as “fileID” or “filePtr”.

So, I would use a “folder” or “path” to identify the directory where the file is located.

And "fileID" to represent the file object.

And finally, "filename" for the actual file name.

Happy coding,
Randy

Answer 8

Based on the above selection answers, which are ambiguous with respect to their meaning and are not a common name, if it is a .NET method asking for the location of a file, then indicate in the XML comments what you want, and also, for example, as another developer may refer to this if they are not sure what you want.

Answer 9

It depends on the naming conventions used in your environment, for example. in Python, the answer will be projectpath due to the os.path naming conventions .

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