Hi Anggie, haven't seen you active on this list, so i guess this is
welcome as well..?
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 :)
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.
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 :)
- Andreas Rønning
Flash Guy, Rayon Visual Concepts
Anggie Bratadinata wrote:
Hi expert coders,
Just a simple question,
How do you develop your Flash applications? How do you write clean,
readable, and reusable codes?
The reason I'm asking this is because, so often, I got lost in
MovieClips spaghetti. Different depth/levels/timelines drive me nuts
and in the end, after reviewing my codes, I can't help re-writing
everything from scratch in order to make it much cleaner. So, on the
same project, I always work twice. :(
What I do so far is write-then-test every single function in my
codes;if it works then I'll write another function. And I tend to
write everything in a single frame.
I'd be more than happy if you, experts, can tell me the right way to
code/develop Flash applications.
TIA,
--
Anggie Bratadinata
Graphic|Web|Flash
Jl. Raya Langsep 21
Malang - East Java
I N D O N E S I A
www.ibshastautama.com
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
