4 ms·
c# already has the 'chained' API in the standard library: new FileInfo(srcPath).CopyTo(dstPath) On the other hand, it also has the more error-prone F
by gnud 7y ago
c# already has the 'chained' API in the standard library:
new FileInfo(srcPath).CopyTo(dstPath)
On the other hand, it also has the more error-prone
File.Copy(sourceFileName,destFileName);
- Lio 7y agoI know nothing about C# so please pardon my ignorance but how does: new FileInfo(srcPath).CopyTo(dstPath); provide more protection vs CopyFile(src: srcPath, dest: dstPath); Assuming that both path strings are set correctly isn't a typo here going to cause the same error and be just as visible? e.g. new FileInfo(pathA).CopyTo(pathB); CopyFile(src: pathB, dest: pathA); neither would seem to show which is correct without knowing what the path values are if the variable names are ambiguous.
- gnud 7y agoWhen using the FileInfo api, it's obvious which argument is the source and which argument is the destination. When using the CopyFile, it's not. If you can't keep track of your variable names, then using keyword arguments, like others here talk about, won't help much, either.
- Lio 7y agoSorry, not sure if your parent was edited to remove keynamed parameters from the second example or if I've responded to the wrong comment. I'd definitely agree with you that the not having named arguments is worse than your method chained example. To me named parameters seem to be on a par with the chained OO api.
- gnud 7y agoAh, the reason is simple: C# allows named parameters, but do not enforce them. You can call File.Copy both as File.Copy(a,b) and File.Copy(sourceFileName: a, destFileName: b) And confusingly, also as File.Copy(destFileName: b, sourceFileName: a)
- Lio 7y agoOK I see. That explains it and also gives a very concrete reason for using the chained API. Thanks.