begin quoting Darren New as of Sun, Jan 06, 2008 at 10:35:56PM -0800: > SJS wrote: > >Everywhere, there's a tradeoff. > > > >I think you're correct -- there's a sweet spot. Probably involving more > >than just length, but also complexity, and levels of abstraction. > > I find it's usually how interdependent the part you want to pull out is. > Which is approximately modeled by how many local variables are > shared/passed between different chunks of the function.
Yup. > Sure, I *could* pull out that bit, but then I'd be passing in five "in" > variables and four "out" variables, along with a status saying whether I > should return early with an error, so it probably shouldn't be a > separate function just for the sake of being a separate function. Heh. Yup. And sometimes pulling out just a little bit more makes most of those "in" variables Go Away. That's a good sign. I once worked on a project where one of the programmers ended up with a method that took twenty-seven parameters. Much ... discourse ... ensued; with the result that the twenty-seven parameters were all shoved into a hashtable (or maybe it was an array), turning a 27-line method invocation (if we stacked the parameters vertically) into a 28-line create-and-load-the-hashtable followed by a one-line invocation, and then a further 27 lines of extract-values-from-the-hashtable-into-variables code. (Followed by Yet More Discourse.) Sometimes, a "solution" is just so bad that you *know* you have missed something critical. Of course, getting down to the canonical three-chunk-implementation (setup/verification, task, cleanup/storage) is a good sign too. > Of course, if you can reuse it elsewhere, then sure. Within reason. Having a bunch of conditional code in a function so it can be reused elsewhere is generally a poor sign. When the conditionals go away, that, too, is a good sign. -- Coding horror stories abound Bartender! Another round! Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
