On 2/3/06, Andreas Rønning <[EMAIL PROTECTED]> wrote:
> Hi Anggie, haven't seen you active on this list, so i guess this is
> welcome as well..?
Hehe :) Yes, Andreas, thanks so much. I've been lurking for a few
months and it was my first post.
> I'm not an expert by any standard, but i do have close to 7 years of
> practical Flash experience paying my rent, so at the very least i guess
> that makes me a professional :)
7 years? Wow, you're lightyears ahead of me :)
> When i write these things i tend to go off on a tangent and start
> writing about horses and the gnp of the moon or something, so in
> advance, i apologize for any lack of clarity.
LOL
> Since Flash 5, i have made it my mission in life to never break any of
> the following rules:
>
> * Don't paint yourself into corners - Make sure what you do is flexible
> enough so that the client spec has some lebensraum
> * Don't put code in MovieClips - Debugging hell. Total terror to suss
> out some runtime errors if you have what you call MovieClip spaghetti.
> Sometimes even easy to forget about MC script entirely, which is.. bad.
> * When possible, keep your code externally and #include. Having to click
> on that "actions" frame and pressing f9 to bring up the script editor is
> 2 steps too many. I prefer to alt-tab between Flash and some external
> editor. It is no secret that the Flash IDE isn't the scripter's best
> friend (although it tries valiantly). My vote goes for PrimalScript
> (www.primalscript.com). It's a little pricey but i haven't really seen
> better.
> * Comment informatively and with clear intent, especially when working
> in teams or with something you'll come back to later.As someone else
> stated, don't overdo it, but comment where clarity is needed.
> * Some guys i've worked with think this is a little extreme, but try to
> avoid using frames at all. The longer your root timeline is the more
> convoluted your application gets. The abstraction that timeline script
> adds to your application is something i always personally found a little
> awkward to deal with (When i declare a function on frame 10, is it
> available in frame 1? When the movie replays, will it THEN be available
> at frame 1? What happens when it's redeclared in the next frame loop?
> etc). Some use frames for graphical states (for instance frame 1 is
> login, frame 2 is "login accepted" sequence, frame 3 is "login failed,
> retry?", frame 4 is chat UI), but i prefer to draw everything
> dynamically and keeping the stage resizable. Partially because it's
> smart, but mostly because i simply CAN, and i can't think of a reason
> not to, unless i have 4 hours to deploy it. Pure animations in clips is
> fine, Flash is a rockstar animation package. But keep that _root clean.
> Your brain will thank you.
> * Maintain smart variable naming conventions. Quick, consise,
> descriptive. Something you can understand yourself. Don't overdo it, if
> all your loop does is iterate through an array, a for(var i =
> 0;i<100;i++){} will do. In this case, for(var counting=0) etc is
> overkill, too many letters. Your brain hates letters! Argh! Reading is
> work, keep it to a minimum, but keep that minimum pretty generous. No
> one way to do this but i prefer names such as userName, isVisible,
> isMicAvailable, playerPosX, planeWidth etc. For instance, to some
> extent, it's obvious that the variables starting with "is" are booleans,
> making if(isMicAvailable){} a little more readable. A lot more readable
> than if(micStatus) or if(microphone).
> * Use local variables. Make your functions eminently clean. Don't leave
> stuff lying around, poisoning the air. Write functions that take a
> value, duplicate that into a local variable (especially in the case of
> arrays which are almost always references), and then work with that
> local value before returning a result. Use the return statement. As with
> coworkers, it's always nice to have functions that talk back.
>
> In addition, since MX2K4:
>
> * Use strict type checking. This gives a 2fold bonus: You get a "free"
> comment to your code that's immediatly clarifying, and you get the
> debugging assistance and hand-holding of a compiler that kind of knows
> what you want to do with a variable. This, much like interfaces in OOP,
> is a great way to hold yourself by the neck and keep yourself straight.
>
> On the subject of reusable code, yes, whenever possible. AS2 and OOP
> really brings this to the forefront. An example is a simple static class
> i wrote that does tooltipping. Whenever i need a tooltip on mouseOver
> right now, i'll drop ToolTip.display("This is the friendly assisting
> text"); in the onRollOver and ToolTip.remove onRollOut etc. Since
> writing that stupid little class, i've used it on 3 apps, and i've felt
> a warm fuzziness every time it just worked without screwing with the
> rest of the application. Of course there are limits to just how reusable
> code is,and IMHO there's such a thing as a needlessly "smart" solution.
> I've seen convoluted OOP that makes total sense for scalability, but
> makes almost no sense from an uninitiated developer's point of view. If
> you have to learn the entire class tree to incorporate it into your own
> work, that's a lot of reading up to do.
> Some people like to abstract their code down to the smallest classes,
> like a "user" class that just has the variable userClass, a "namedUser"
> extension that adds "userName" and "userAge" or whatever, and then
> building it up like that. It looks... Retarded. If you're going to do
> OOP, learn a design pattern. My favorite is ModelViewController, but for
> the most part with classes i wind up with an eventbased model. Whatever
> suits you best, but please, swallow your pride and learn conventions,
> smarter guys than me have done OOP for probably longer than i've lived,
> so i'm not about to pretend i have a better methodology :)
>
> Good OOP conventions is a TRUE can of worms though. I'll leave that to
> the brainy folk.
>
> To solve your nuttiness issues with depths and levels, i have one piece
> of advice:
> Don't ever, ever use getNextHighestDepth();
> Declare depth variables such as backgroundDepth, cloudsDepth, UIDepth,
> horseDepth (i had to), and explicitly set them. Referring to depths by
> names like this is just a nice little cushion that reads better.
> I like hardcoding depths for things like UI elements, like a custom
> textbox+scrollbar component with a resize handle and a close button and
> such, like a little window type thing. There's no reason every depth of
> that component needs to be set dynamically, so don't.
>
> To summarize everything into something a little more generic:
> Be gentle with yourself. The smarter you think are doing it, chances are
> you're doing it too hard :)
Mate, your lengthy worthy advice hits my problems precisely!
That's exactly what I need. I'm gonna print out your post and keep it
as reference.
Thank you very much,
--
Anggie Bratadinata
Graphic|Web|Flash
Jl. Raya Langsep 21
Malang - East Java
I N D O N E S I A
www.ibshastautama.com
www.nextrand.co.id
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
