Paul,
You are perfectly right. The case of Beno's piece:
if (e.target.currentFrame == 40) TweenMax.to(mcHandInstance2, 2, {x:200,
startAt:{totalProgress:1}}).reverse();
...is clearly a proof of what you say, because it already produced
confusion.
Greg
Wednesday, December 09, 2009 (1:30:22 PM) Paul Andrews:
> Greg Ligierko wrote:
>> Well... Code without braces may look a bit confusing, but that depends
>> on what somebody is used to and just what you like. An example when I
>> often bypass braces is setting default values for AS2 function
>> arguments:
>>
>> function funName(arg1:Number, arg2:Object):Object
>> {
>> if(isNaN(arg1)) arg1 = 0;
>> if(arg2 == null) arg2 = {};
>>
>> //... rest of code
>> }
>>
>> This has no sense in AS3 because it provides a new syntax for setting
>> default values fun(arg:Number=0):void.
>>
>> Another example:
>> function funName2(flag:Number):Number
>> {
>> if(isNaN(flag)) return someValue;
>> return someOtherValue;
>> }
>>
> The only problem with this (and yes, I have like everyone else coded
> like that), is that it doesn't explicitly indicate the intention of the
> code.
> If the function is written as:
> if(isNaN(flag)){
> return someValue;
> } else {
> return someOtherValue;
> }
> Then the intention to return one or the other depending on the test is
> very explicit. Maybe it doesn't matter for these trivial examples, but
> the intent can be less obvious when the code is more complex.
> I think every body uses the shortcuts (me too) for conditional
> statements, but I think often it's really bad practice and it's often
> proven as bad practice when begginers can't debug their code because it
> looks "right".
> I start off by writing.
> if (i==6) doThis();
> Well already I've messed up any visual clues about the nesting of code
> conditionals when I scan the page because my "doThis()" isn't indented
> equally with other conditional code.
> Lets put that right.
> if (i==6)
> doThis();
> Now the visual appearance of the code makes me instantly see that the
> call to "doThis" is nested in conditional code - it's indented to the right.
> No problem, now right?
> A month later I realise there's a bug and it should really be
> "doThis();doThat()" if i equals 6.
> In my hurry I now make this update:
> if (i==6)
> doThis();
> doThat();
> And it looks right, but now my code is behaving even more badly.
> Scanning through the code doesn't give an instant clue because this wil
> be buried amongst a load of other stuff.. Only later do I realise that
> while my indents look right, the actual interpretation is:
> if (i==6)
> doThis();
> doThat();
> ..something I didn't intend.
> Now, if I was in the habit of writing my conditionals with braces and
> indenting my code, I would be very, very unlikely to make this simple error.
> So I should habitualy write:
> if (i==6) {
> doThis();
> }
> or (depending on your own preferences)
> if (i==6)
> {
> doThis();
> }
> Then I can't go wrong when I come to add extra code:
> if (i==6)
> {
> doThis();
> doThat();
> }
> So, in essence, adding braces even when they aren't needed will make you
> less likely to make accidental mistakes in the future.
> Paul
>> You mention using braces without somewhere to emphasize the code. I
>> think it is just somebodies preference how he highlights separated
>> logic
>>
>> Usually separated logic should be done just by writing a separate
>> method but when there are performance issues (calling a new method
>> leads to redeclaration of variables) or when this part of code sets a
>> group of new variables (separate method returns only one value, unless
>> it returns an array or object - again performance issue), this may
>> have sense. Still, I prefer adding a commented bar or a short limerick
>> instead or braces.
>>
>> Greg
>>
>>
>>
>>
>>
>> Wednesday, December 09, 2009 (6:18:42 AM):
>>
>>
>>> Yes, your correct.
>>> I always use braces.
>>> It looks aesthetically pleasing to me and helps me separate things.
>>>
>>
>>
>>> BTW, what is the point of braces if you dont need them, except the
>>> separation of your code part.
>>> Are they needed in some situations over others?
>>>
>>
>>
>>> Karl
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Flashcoders mailing list
>> [email protected]
>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>>
>>
> _______________________________________________
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
