Your // bad block looks ok to me. The only reasons I can think of to store the value first before using it is if you need it more than once or if the method/function name isn't clear, you can make it more so by the the name of the valiable you use for the returned value.
Ade -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Judah Frangipane Sent: 21 December 2005 23:10 To: Flashcoders mailing list Subject: Re: [Flashcoders] Faster code? This happens all too often. As common as this is, it is something you *must* do. Especially if you are the person that has to go back and change stuff at a later date. I dont know how many times I have gone back and looked at my code and I was like, "what the (explicitive deleted) was I doing". Now I write code for readability. // bad (IMHO) if (getIsTrue(myTest)) { return (10/2 + 5)/mc._x; } // good var isSomethingTrue = getIsTrue(myTest) if (isSomethingTrue) { var retVal = (10/2 + 5)/mc._x; return retVal; } Trust me dude, I am having to rewrite an asp app in flash remoting asp.net and none of the code is commented. So I have spent 3/4ths of my time trying to interprit another persons code and the other half writing a flash remoting version of it. Readability is more important than speed (IMHO). Either way comment. :) Judah JesterXL wrote: >What I want to know is who is paying for #2? Very rarely do I ever get time >to comment anything, and even if I did, the code I commented changes the >next day, rendering the whole endeavor fruitless. > >...not to mention most service work is always a custom job/rewrite anyway. > >----- Original Message ----- >From: "Paul BH" <[EMAIL PROTECTED]> >To: "Flashcoders mailing list" <[email protected]> >Sent: Wednesday, December 21, 2005 4:49 PM >Subject: Re: [Flashcoders] Faster code? > > >I think these are all great, but if I can be the voice of caution for >a moment... > >remember that when you write code, it is for 2 interpreters: > >1) the Actionscript VM >2) the person who has to go back and change stuff at a later date, >which may or may not be you... > >Its often very easy to forget number 2 - so, while writing doing >things like avoiding function calls may be faster for 1) it can end up >making things a lot slower for 2) > >Also, when you go through your code & optimise it, make sure you are >efficient with your efforts - you will probably find you can nail down >key performance spikes to just a few functions / algorithms... be >careful not to optimise to death, and try and measure your gains at >each step > >I'm not saying code shouldnt be optimised at the expense of (human) >readability, just that sometimes it gets a little overdone... > >ta > >PBH _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
