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
