Robert, To me, code broken up into smaller pieces can “seem” more maintainable, but (actually more importantly to me) often is far less comprehensible. And I must comprehend it in order to maintain it.
I recently returned to a piece of code that someone else had refactored in order to write tests. I found that I no longer understood my own code. Where does the such-and-such get done now??? This calls that, and that calls that, and so forth. Like a Russian Doll. I could have used a diagram. And any errors have to bubble up out of that stuff. Thankfully better error wrapping has been added to Go. I guess everyone doesn’t think the same way. I am very top-down sequence oriented. I don’t like to jump around in code in order to figure out what is going on. Also, I believe that *with* statements could provide two additional benefits (in addition to making tests easier to write without refactoring): 1) Allow someone to read source code from top to bottom, paying most attention to the *with* statements, and come away with a quick understanding of the code. 2) Correct the problem that Go has with the common “err” variable. Err could be redeclared in each section of *with* code — enforcing that each section is dealing with its own “err” values. Err would not drop thru unless specifically listed. Warren -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9840e599-b001-4cfa-b6fd-35227b18b80d%40googlegroups.com.
