tags:

views:

396

answers:

10

Well, the title says it all. When passing a file name to a method, should I use a FileInfo object or a plain file name (string)? Why would I prefer one to the other?

Some of my colleagues like to write method like this:

  • void Export(FileInfo fileInfo)

Is it better than:

  • void Export(string fileName)

Thanks!

+14  A: 

I'd usually just use a string - it's simpler in most cases. Otherwise you're likely to just create a new FileInfo from the string in the first place.

If you're creating the method, you could always provide overloads to allow both.

Of course, if you know that where you're intending to call it, you usually have a FileInfo rather than a string, that's a different matter.

I can see your colleagues' point of view - in some ways a FileInfo is a "cleaner" way of expressing the parameter. I think string is the more pragmatic approach though :)

Jon Skeet
I also use strings. I'd only consider using FileInfo if I wanted to use something else that it offers- like the CreationTime.
RichardOD
I'm really interested about this. Why represent a file with a string? It kinda feels like representing an XML document with a string.
Esteban Araya
+1 - Forcing the consumer to pass a FileInfo is silly unless you're explicitly working with one, because then you get code like this: Export(new FileInfo(@"C:\File\Path\Here.txt")); UUUGGLYY! That should be in the method, not where you're calling the method!
Daniel Schaffer
@Esteban - You aren't representing a file with a string, you're representing the path of the file, which *is* a string.
Daniel Schaffer
@Esteban: I see nothing wrong with representing an xml document as a string, assuming you are passing it to another function rather than trying to parse it. But XML files usually come from somewhere, so I'd be more apt to have the function which is going to read that xml file load it from such a location. I normally would not pass an xml file around as an xmlreader or whatever, since the creation of some mechanism for parsing the xml file is the responsibility of whatever function is going to do the parsing.
Brian
+3  A: 

I would say it depends :) Many static file operations on the class File allow a number of things with the filename. The abstraction of a File is not that often useful in the .NET Framework, so I am biased towards using a string and denoting in the argument name what it is.

flq
+1  A: 

I think file name will suffice if it is doing the same thing.

Beatles1692
+5  A: 

Typically I would pass the string. However, you could overload the method to make everyone happy.

JTA
+1 My option exactly. The we could also bring in the suggestion from CShartAtl's comment to the question and have an overload accepting a Stream.
Fredrik Mörk
That would definitely be my preference as well.
McWafflestix
+3  A: 

The difference is primarily that there is a little bit of checking going on; the FileInfo constructor does some checking for a null or clearly invalid parameter. There are a few other things it does; taking a FileInfo basically just puts the onus of handling the exceptions from the FileInfo constructor on the calling code, as opposed to your code.

Here's the MSDN reference for the FileInfo constructor that shows what the constructor can throw:

http://msdn.microsoft.com/en-us/library/system.io.fileinfo.fileinfo.aspx

McWafflestix
A: 

I would follow the convention of using Steams. This is how I see most I/O performed. It makes sense to me:

void Export(string s) 
{ 
  Stream fs = new FileStream(s); //think this is correct
  Export(fs); 
}
void Export(Stream s) 
{
  s.Write ( ... );
  ...
}

I agree, FileInfo has never been that useful to me. stick with string or use stream which can be FileStream, MemoryStream, etc.

TheSean
A: 

If you're working on code involving these colleagues, I would use FileInfo. It really doesn't matter much but writing code the way others expect it reduces maintainence, raises consistency, and generally makes people happy.

I will point out that I dislike the idea of using FileInfo for the sake of putting the onus of checks for validity on the calling function, as pointed out by McWafflestix. If something breaks between the calling function and the function that was called, it won't be caught. It won't necessarily be caught if you use a string...but at least it makes it clear where the problem can happen. And you'll want to catch such exceptions in the called method anyways. Surely you aren't going to open the file and start reading/writing until you're in the actual function (if you are, FileInfo and string are probably both the wrong choice, but Stream makes sense, as TheSean suggests).

Brian
Note that this all assumes the class is for internal use. If customers are going to be using your code, FileInfo is a poor choice.
Brian
A: 

A FileInfo does do more to show the intent of the data type than a string. And that's almost always a good thing. However, there's certainly plenty of precedent for passing a file name as a string, including most of the .NET framework itself. A file name IS a string. Presumably, you'd have the caller use the FileInfo object to force the calling code to validate the file name (i.e. handle the exception) rather than burdening yourself with passing back the exception.

Certainly, including a method overload would remove all doubt, so long as you're validating the file name being passed in.

KnownIssues
A: 

As usual, it depends. In all but the most basic of cases, I'd say using FileInfo gives you a lot of benefits with almost no negatives. Strict OO dogma would say that information about a file (path, creation date, modified date, etc) should be encapsulated within a class like FileInfo. This will allow you more flexibility if down the road you need more complex behavior. If you write your code against FileInfo, it will almost always be cleaner and less bug-prone if you need to make changes.

If you absolutely can't think of a scenario where you'd need more complex behavior, and it's going to really throw you off, go ahead and just use a string.

Nick Stamas
A: 
  1. String is not PATH. So string is not the best way to represent path.
  2. FileInfo is also not a PATH, semantically it represents FILE.

So this will be better if MS will provide Path object :) or you can make it yourself, especially if this is your internal code. In this way you will not need to check your PATH arguments every time you will work with them. I often has many structs that represent different stings, NonNullString, IdString(case insensitive), I believe that this makes code simply.

Mike Chaliy