From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10ad19,23963231b5359f74 X-Google-Attributes: gid10ad19,public X-Google-Thread: 107a89,23963231b5359f74 X-Google-Attributes: gid107a89,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-ArrivalTime: 2001-06-05 13:30:17 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!news-hog.berkeley.edu!ucberkeley!newshub.sdsu.edu!csulb.edu!/news!news.fsu.edu!bellenot From: bellenot@math.fsu.edu (Steve Bellenot) Newsgroups: comp.lang.ada,comp.lang.awk,comp.lang.clarion,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml Subject: Re: Long names are doom ? Date: 5 Jun 2001 20:27:48 GMT Organization: Florida State University Department of Mathematics Message-ID: <9fjfc4$qdv$1@news.fsu.edu> References: <83WP6.3874$yc6.728572@news.xtra.co.nz> NNTP-Posting-Host: newton.math.fsu.edu X-Trace: news.fsu.edu 991772868 27071 128.186.104.21 (5 Jun 2001 20:27:48 GMT) X-Complaints-To: abuse@fsu.edu NNTP-Posting-Date: 5 Jun 2001 20:27:48 GMT Xref: archiver1.google.com comp.lang.ada:8192 comp.lang.awk:2790 comp.lang.clarion:21147 comp.lang.java.programmer:73823 comp.lang.pl1:784 comp.lang.vrml:3521 Date: 2001-06-05T20:27:48+00:00 List-Id: In article <+FWVg+noA0yk@eisner.encompasserve.org>, Larry Kilgallen wrote: >In article , Jon Skeet writes: >> Blaikie wrote: >>> >>> > > the sake of length seems a bit pointless (sometimes, other times if a >>> > > certain part of the code serves an independant function to the rest of >>> the >>> > > code, yet is still only used once, it may still be nice to seperate it) >>> > It doesn't always work like that, but it can. Code repetition isn't the >>> > only reason for refactoring. >>> >>> i agree, thats why i put the exception in the brakets at the end, but there >>> are times when the code just simple isn't divisible, which is the point i >>> was making, yes if u have a routine that reads in and creates a simple >>> object., but one of its fields is an int, yes, have a seperate method that >>> reads and parses an int, but such a case is not always possible >> >> Not *always* possible - but your inclusion of it just in brackets makes >> it appear that you believe it's normally the case. >> >> I'd suggest that *very* few methods which are ten pages of code which >> *can't* be broken down further are well-designed. > >How about a case statement for 137 possible cases ? Depends on the language of course, but I think it is likely that this is the wrong solution. At some point, it would make sense to replace the case statement with a config file and some program that automatically generated the case code from the config file. If the language supported it, a jump table might make more sense than a case statement. Again the jump table could be loaded from a config file. >Even if it only calls a separate subprogram for each, that is longer >than most people's screenful. -- http://www.math.fsu.edu/~bellenot bellenot math.fsu.edu +1.850.644.7189 (4053fax)