I’ve decided to follow ScottHans‘ advice, and review the NDepend.Helpers.FileDirectoryPath sources.
Scott said:
I’ll let you go check it out, because you should. I think a class this smart would be a nice addition to the BCL.
I can now elaborate on this. The class is “smart” because it would do neat things.
Resolve Relative Paths
like ./../../dir1 to absolute form. It would do that by splitting all of the “directory” components and resolve each, later reconstruct the whole.
Differential Path
like /root/dirs/a/b/dir1 and /root/dirs/a/dir2 share common path, and it can use it to extrapolate the transitional path, from dir1 to dir2: ../../dir2.
So if you were at the first directory at the command line, you would type cd ../../dir2 and get to the second path.
The Bad
However what I found disturbing is the code aesthetics. With status variables like bNextDoubleDotParentDirIsInnerSpecial, and bNextSingleDotCurrentDirIsInnerSpecial which both are hungarian notation (used only there), and very hard to read and interpret. And method names like GetBrotherFileWithName which supposed to mean “give me a string filename, and I’ll give you a sibling filepath object in the directory.”
There is also extensive use of ‘helper classes’. It seems that all of the ’serious’ logic is contained inside static utility classes. Is that good design?.
If this is a case of just publishing non-refactored source code I take that all back.
