|
I'll investigate the coding conventions. I'm pretty sure that VS.NET will "correct" the curlies by default, but I'll try make sure that my NAnt patches adopt the alternate, untabbed lifestyle. ;)
I have no idea what the internals of the Framework do with that StreamReader overload. For the kilobyte-sized SQL files I'm comparing, it seems to be minimal. I'm more than happy to adopt an alternate route if there's a better performing widget.
UNICODE is a goot kvestion, and somewhat outside my general experience; I'll ask my ESL developers to help me out there on Monday. Whatever the native StreamReader encoding-to-String is/does is what will happen using that overload. I would lean toward throwing an exception if the files being compared had a different encoding scheme... Any thoughts?
Comparing file sizes may have the same problem as you noted with UNICODE -- the sizes may match, but the files are not identical, so that wouldn't solve my problem. One character can make or break SQL syntax. :)
I hadn't considered someone attempting to diff binaries or 20MB files. I would expect binaries-converted-to-strings to compare same-or-not just fine... but short of adding a hard limit on file size that may be overridden by yet-another-property, I'd chalk it up to caveat developer on the oversized load. Fun to see when you reach pagefile exhaustion and the o/s throws an exception to NAnt...
isAMatch and the thatSR.Close() are likely to be an example of why one should not be writing code at 2am local time. Be happy to fix myself there!
I've never used the FileInfo class before, so it's overhead is an unknown to me; I'll see if there's a less painful way to provide some meaningful verbose logging.
I'll investigate the MD5 hash, but unless there's some voodoo involved internal to the Framework, isn't it going to have to read in the whole file anyway just to compute the hash for comparison?
I've no idea what "alternate" streams might be, so I'll leave that case in the corner for another day.
I appreciate the feedback!! Thanks.
-----Original Message-----
A couple of comments and suggestions:
- Check the coding guidelines for the coding style: - use spaces - opening curly braces go on the same line with the if (), else, or while () - By using StreamReader, aren't you taking on on the cost of decoding the bytestream into a character stream ? - How do you deal with binary files? - What happens if comparefile is ANSI while difffile is UNICODE ? I'm guessing that your comparison of thisFileContents != thatFileContents StreamReader may say that they are the same, even though the files are physically different. - What happens when you are comparing two 20 MB files? Will there be enough memory to hold these two strings? - the variable named "isAMatch" seems to be a misnomer. As I read the code, it seems to say that the files are a match when the contents are not equal. - the if statement clauses seem backwards based on "isAMatch". It says that the files are different if isAMatch is true. - thatSR.Close() is outside the foreach loop. I think it should be inside. - constructing a FileInfo to be used just in verbose logging seems like a waste.
[There's also the corner case of alternate streams on Win32. Do you need to compare those streams as well. I think most people just ignore this.]
- May I suggest using the Stream class and just computing the MD5 hash of each of the files you are comparing. A quick shortcut maybe inspecting the filesizes first before investing into actual computing the hash.
- Ants
|
Title: Message
- [nant-dev] Who's the happy moderator who ate my <... David Reed
- RE: [nant-dev] Who's the happy moderator who at... Anthony LoveFrancisco
- Re: [nant-dev] Who's the happy moderator who at... David Reed
- Re: [nant-dev] Who's the happy moderator wh... Ian MacLean
- RE: [nant-dev] Who's the happy moderator who at... Anthony LoveFrancisco
