OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Schema, BNF and parsing

[ Lists Home | Date Index | Thread Index ]

At 08:42 +1100 2005-03-05, Rick Marshall wrote:
>Michael Kay wrote:
>>>My real "beef" is the 2666 line script. It has numerous
>>>redundancies (i.e. duplicate code) and looks like a nightmare to 
>>It's a common problem. I once reduced a 2000-line stylesheet to 20 lines
>>plus some data tables. There are lots of people who learn how to write
>>concrete XSLT code without learning how to write it generically at a higher
>>level of abstraction. The same is probably true of most languages.
>do you have an example? i'm working on a layout engine at the moment 
>that's rapidly approaching that sort of complexity and i'd love to 
>simplify it the way you described.

I don't have examples handy either, but I'll bet Michael's approach 
will apply in your situation. The long form of learning to do this is 
to study software engineering, of course. But a couple "25 words or 
less" steps you can take might be:

1) Look for places where the program does the same conceptual thing, 
in different ways (say, by iterating versus by recursion, or by 
columns versus by rows, doing steps in different orders, etc). Pick 
what seems the cleanest way, and change all the other places to use 
it. Doing the same thing the same way several times, is clearer than 
doing the same thing different ways multiple times.

2) Scan the entire stylesheet for repetitiveness -- places where 
*almost* the same code appears multiple times. Figure out just what 
the differences are ("these are just the same except for..."), and 
then write a more general method that covers all the cases, 
controlled by a switch, parameter, or other variables. It sounds like 
you could get a lot of mileage here.

3) Look for a method that does the same thing as another, *except* 
for not having to bother with one certain block of code. See if that 
block does something coherent in itself, and try to factor it out to 
make the larger method be like the smaller plus one extra method call 
-- then you may be able to collapse them as in #2.

4) Go through and write a one-sentence (no more) description of what 
each individual method does. Then read them all through in various 
orders. This will likely stir ideas for further improvements. Also, 
any methods where it's hard to write the sentence, probably need to 
be re-thought and divided up more cleanly. Oh, you may want to insert 
your sentences as comments over each method, to help the next person 
(who may be you too, of course).

5) Draw out a diagram of what calls what. Switching from text to 
visual modes may give you a whole new perspective on your code, and 
simplifications may become easier to see. Use big paper, maybe with 
post-its so you can re-arrange things several times.

There's my attempt at Software Re-engineering 101 in one page.... I 
hope it's of some help; but this is a kind of situation where 
training and experience can make a big difference. If these methods 
or similar don't work for you, perhaps consider getting some highly 
focused expert help.


Luthien Consulting: Real solutions to hard information management problems
    Specializing in XML, schema design, XSLT, and project design/review/repair
Steven J. DeRose, Ph.D., sderose@acm.org


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS