[
Lists Home |
Date Index |
Thread Index
]
Steven J. DeRose wrote:
> 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
>>>> maintain.
>>>
>>>
>>>
>>> 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.
>
> Steve
>
it was mostly the data tables bit i was interested in - being doing the
rest 30 years :) (have all the degrees, <gripe>but that seems to be a
disadvantage here in oz</gripe>) - just needed the "trick" or hint,
which i'm pursuing.
in this particular case the xslt is producing postscript - which is a
language with its own set of problems.
it's an intriguing problem because we mostly think of xsl as
transforming one static document into another. and while the outcome in
this case is indeed a static document, the process is to use xsl to
write a program (!) which produces the document.
at the moment the problem is at two levels (which i'm sure people who
have written xsl-fo implementations have already faced and solved) -
building a dom in either postscript code or structures - and
paramterising the xsl to cope with dom elements with the same attributes
- eg almost everything has a set of "background" attributes.
and yes i could do the job quicker with languages i know well (like C :)
), but i want to end up with a stylesheet because that can be easily
deployed anywhere at the cost of it being almost impossible to protect
the ip.
rick
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
