Dave Watts wrote:
snip
It really depends on the language. Since I'm moving (more or less)
from Java to AS3, more or less, I'm usually using explicit expressions
because that's what people do in Java. On the other hand, in the
ColdFusion code I've written, I usually use implicit Boolean
evaluation.
I don't think writing "good" code is related to languages, despite the
different constructs available between them. I think good coding style
is based on simple principles, and brevity or speed of coding is not
included.
Short coding constructs may be perceived as elegant and aid coding
speed, but that wholly misses the point - coding isn't a race nor is
optimising the number of bytes in the source code. Showing a deep
knowledge of a software language through use of the language in ways
that are not so clear to mere mortals less familiar with the language,
isn't good. It is rarely a good idea to optimise code by using a faster
programming construct that makes the intention of the code less clear.
Good coding should be clear - even for those less familiar with the
language. Truncated coding constructs may be efficient and even elegant,
but will they be easily understandable by someone else (or even the same
person much later)? Code minimalism can hide the true intention of the
code and introduce unintended behaviour when mistakes are made. When
code is expansive (verbose even) the intention of the code is clear.
When someone relies on some language behaviour for handling null values,
the reader may be left wondering whether the original developer really
intended that the code should handle nulls in this way, or is it some
accidental happenstance of using that construct? Are nulls really
relevant here in this code snippet or not. Testing specifically for
nulls is explicit and unambiguous.
Maintainability - truncated constructs can sometimes mean that changes
for updates mean undoing the "efficient" constructs that performed well
for specific case they were coded for, but will have to be ditched
completely for the more complicated case, leaving the updater to unwind
the intention of the shorter construct and translate that to the wider case.
As far as "fast" coding goes, everybody likes a helpful ide or editor,
but really fast coders really aren't team coders and the "need for
speed" is less important than the need for clarity. I'm not a fast
coder. Sometimes I wish I was an even slower coder, because then I'd
realise I could code things rather better than going rushing in to get
things done.
I once worked with a guy who had a clear desk and often sat reading the
newspaper. It did attract some critical comment, but that guy had the
right idea. Before he started coding he spent a lot of time on the
design, getting that right. A faster code editor or fancy programming
wouldn't have made him a better developer. He spent most of his time
getting it right before his hands hit the keyboard. He was the best
developer I ever met.
So, in my insignificant opinion - brevity == BAD, fast coding ==BAD.
Paul
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
Fig Leaf Software provides the highest caliber vendor-authorized
instruction at our training centers in Washington DC, Atlanta,
Chicago, Baltimore, Northern Virginia, or on-site at your location.
Visit http://training.figleaf.com/ for more information!
_______________________________________________
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
