domchi.underwood at gmail.com
Thu Oct 15 02:48:50 PDT 2009
On Tue, Oct 13, 2009 at 11:52 PM, Glen <gcanaday at gmail.com> wrote:
> Which got me wondering and from there to curious. How do you all go
> about visualizing these complex relationships? Do you draw them? "Prim
> them out" like I just did?
Unfortunately SL is pretty bad when you want to decouple your code; you can
pretty much isolate code in another function or another script. If I look at
the function, its name should tell me clearly what it does. If there are any
gotchas, I comment the function. If I interact with another script, I
usually document the protocol - what order are messages exchanged, and what
it message means. I usually either put the protocol description inside
comment on top of the script, or in separate file if there's a single script
is not central point of communication. I also comment the hell out of any
part of the script that I think I won't be able to remember what it does on
the glance. On some projects I also have "assembly instructions" on how to
assemble objects and what permissions to give, or steps how to reuse them in
other scripts. For example, for updater I have detailed steps what needs to
be done and checked when creating product itself, and what needs to be done
when I'm creating update for the product.
When I use drawings, it's usually something related to specific product and
mostly about prim placement - for example right now I'm working or product
which has grid of 3x3 prims to display different layers of info on top of
eachother. My essential drawing in this case is the grid with link numbers.
Also, recently I had project with many states where I started by writing all
states and events, but without code - just comments on what each event does
and how it's linked to other events. Then I started replacing comments with
Regarding UML, I hate when someone insists on using UML (though in SL I yet
have to find someone that uses it at all). Basically, I've found that
drawing is fine for high-level concepts, and becomes pointless the more you
approach the code itself. The most accurate visualization of code is code
itself, so the moment you cease to look at abstractions drawings become
unproductive. UML is great because it gives standard and well-understood
elements for visualizations, but drawing every part of system in UML is
usually too much of a bureaucracy for me (that is, process which restricts
instead of helping).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the secondlifescripters