Cart
[Home] [By Thread] [By Date] [Recent Entries]
On the other hand, the kind of complexity that extra lines in a table cause is trivial, perhaps negligible after the first entry. (You wouldn't implement a large lookup table as an if-then-else chain, surely.) I think it is only sound to use the Source Lines of Code metric to measure code complexity when it is, for example, a reasonably proxy for Decision Point Analysis or some other complexity with risk attached: in the case of a lookup table (not used for jump vectors), SLOC clearly isn't a reasonable proxy. (It might be consideration if you had to type numbers in by hand, due to the possibility of transcription error, but I don't expect your would be doing that either.) The line argument is a little strange to me: if the absolute number of lines is the problem rather than complexity (because you only have a a certain number of sheets of paper in your printer? because you are programming on an android phone screen?), you could just have multiple entries per line. Reduced to the absurd, I guess it means we could simplify the whole program by over 4000 times by putting everything on one line? :-) Cheers Rick On Fri, Jun 1, 2012 at 6:15 AM, John Cowan <cowan@m...> wrote: > There are 2236 entities in the current draft of the W3C entity set, but > only 2117 lines of Java in my parser. I don't think I want to double > its size.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
