IMHO, this kind of refactorization actually makes the code less readable,
for everyone but the programmer that just wrote it. Though it may seem
obvious at first what functions like "CopyFile" do, an outsider reading the
code will have to check the source to know for sure what is going on.
When this kind of "factoring for simplification sake" is frequent enough,
the simplest linear algorithm becomes a maze of sub-functions.
I, for one, really like the check/handle proposal, because I think it is
easier to read than the current code with interleaved ifs, while being as
explicit:
handle err {
return fmt.Errorf("copy %s %s: %v", src, dst, err)
}
r := check os.Open(src)
defer r.Close()
w := check os.Create(dst)
handle err {
os.Remove(dst)
}
check io.Copy(w, r)
check w.Close()
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
