Axel, I think it was a different kind of efficiency that first prompted my thinking on this.
The (my) original prompting code was written quickly, debugged, and working. No tests. Such is life. The refactored "testable" code (no functionality added) became 162 lines and 9 funcs -- averaging only 18 lines per func. From my standpoint, it cannot be read top-down -- the one public func is 21 lines. I am comparing that to something I quickly wrote yesterday (deadline is soon, so has no tests), 7 funcs which average 66 lines per func. I am sure that if I restructured it for tests that it would head towards 20 lines per func like above and therefore become 21 different funcs. Like being hit with a hand-grenade! :-) Feels like there must be a better way. Warren Note to others: Software *Engineers* must operate with the 3-way tradeoff in mind (pick 2 is the old joke): 1. quality (good) 2. time (fast) 3. cost (cheap) Folks that *always* emphasize quality over time or cost may have an unrecognized bias that could be hurting their projects. Recently my company archived lots of repos -- and my bet is that a great deal of the code worked fine and had few tests. As Buddha said "The future is always other than you imagine it". One sign of possibly excessive quality bias is developers who don't want to show their code to anyone until it is "finished". -- 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/418fafbb-6377-4851-9476-3be967c0da00%40googlegroups.com.
