Steven Sacks | BLITZ wrote:
As a relative newcomer to Actionscript, I have found the entirety of
this thread very useful. I want to thank all of you for sharing this
code, as well as providing a considerable amount of insight to those
of us lurking in the shadows.
Glad to hear it.
I was fairly surprised to see that if(this.length == 0) is considered
sloppy opposed to (!this.length); conjointly, I had no idea that
iterating through an array in the way you described was bad practice
either. I'm sure I've done it quite a few times myself, unaware of the
consequences.
The opposite. if (this.length == 0) is not sloppy code because it is
explicitly stating what you are expecting, versus accepting anything
that resolves as false in Flash, which includes 0, false, null and
undefined. You are being strict about what you expect and your code
will be easier to debug because of it, and you will be a stronger
programmer because you are well disciplined and don't take shortcuts
which could potentially come back to haunt you.
Thanks for clearing this up. You didn't really indicate a reason
between both methods when you said "I always try to write as careful
code as possible to avoid the oh so enticing opportunities flash
provides for sloppy coding. Things like if (!this.length) versus if
(this.length == 0)...", so I wasn't sure which you were referring to
as the sloppy or correct way.
To me it has always seemed more logical to use if this.length == 0 for
the very reason of explicitness that you stated; and thus, using the
alternative !this.length was less enticing. I speculated (wrongly)
after reading your post that there might be some sort of speed
optimization inherent to checking if something is false than actually
checking for a specific length defined explicitly in your code. I
don't know why I thought that, and obviously I am wrong for the
various reasons stated earlier.
It would be very beneficial for those of us who are not up to such
(relatively) meticulous levels of coding practice if there was some
sort of resource which enumerated a list of best coding practices when
optimizing for speed--something along the lines of the similarly
titled article in the flash documentation but aimed at the
"middle-class" coder.
I know I don't have time to do this, and I've had to do my own research
over the years to find out this information, and that's fine by me
because it has made me a more resourceful developer. For loop speed has
been covered numerous times throughout the life of this mailing list and
searching the archives will shed light on lots of different things (use
google to search the archives, the built-in Flashcoders archive search
is broken).
I wasn't asking you to create this resource, just simply stating the
fact that such would be considerably valuable to many. It might also
eliminate some of the frequent and routine questions that bother some
of you so frequently ;).
Searching through the archives is a great thing--predicating one
actually knows what to search for. In my humble opinion there is much
more to be said for a unified, centralized, and cohesive source of
information that has been peer reviewed and updated collectively.
While useful, the archives suffer from discontinuity by the very
nature of this platform. A mailing list is intrinsically disconnected;
each post is like a puzzle piece to a much larger concept which
may--or may not--be accurate, dated, and/or relevant at all to your
problem at hand. Yet, in order to derive any utility at all, you are
still faced with the task of assembling the puzzle.
As a sound engineer, graphic artist, photographer, writer, and more
recently a developer, I don't have the enormous amount of time that I
would like to wade through mountains of posts in order to arrive at a
very specific destination. It is not efficient nor realistic to expect
people to drudge through a pile of loose un-scrutinized data that is
growing at an exponential rate.
This is just my opinion though.
And besides, if I say to you that this is the fastest for loop (but not
the fastest loop in Flash):
for (var i = len; --i -(-1); ) {}
You're going to ask why, especially given its funky syntax. Yes, it's a
for loop with only two parameters instead of three and the compiler has
no problem with it. The answer to why is explained by the guys who
wrote Flasm. If you want to learn more about how the Flash player works
and how to really optimize your code, check out Flasm.
Performance enchancers like putting the more likely result first in an
if statement, the fastest possible loop while(--a -(-1)), etc. are
explained by how Flash compiles your Actionscript into bytecode.
Anyway, good luck!
This sounds interesting; and I will surely look into it. I might even
create a document fully explaining the issues I encounter, for which I
would love to get any collaborative input from anyone on this list
when the time comes.
Thank you,
Joseph
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
