1. How not to code Flex
Applications
Tips and Tricks to keep you from
being fired, or fed to the lions.
Jeff Tapper
jtapper@digitalprimates.net
Digital Primates IT Consulting
2. Who Am I
Jeff Tapper (jtapper@digitalprimates.net)
Senior Consultant – Digital Primates IT Consulting
Group
Building Internet Applications since 1995
Authored 10 books on internet technologies
Adobe Certified Instructor for all Flex, AIR, Flash, and
ColdFusion courses
http://blogs.digitalprimates.net/jefftapper
Twitter: jefftapper
3. Who Are You?
• Developers who…
– are open to learning
– Have some experience with Flex
– Have a sense of humor
• If this isn’t you, you should probably leave
4. Agenda
• What is bad code
• Why do developers code badly
• Bad Code Samples
• Rules to Live By
• Questions
5. What is Bad Code
• Bad code is…
– Code which doesn’t meet the needs of a project
• Efficiency
• maintainability
• Time to develop
– Code which doesn’t make sense
6. Why do developers code badly?
• Lack of Time
• Lack of Knowledge
• Lack of Caring
7. Some of my bad code…
public class XMLListener extends
EventDispatcher
{
// FIXME! - JT - yes, i know this is
// not the right solution
// but im making the socket public so I
// can attach a listener to it
// this can clearly be done better, but im
// tired, and this is what i have at the
// moment
public var socket:XMLSocket;
8. What are the consequences
• Bad code can lead to
– Delays
– Project failure
– Job loss
– Death
10. What is wrong with #1
• Summary: Inappropriate use of container.
• Description: <mx:Image> should be used to
display an image, not a container with an
backgroundImage style
• Type: Maintainability, Performance
• Rule: Its never appropriate to use a container
which will never have children.
12. What is wrong with #2
• Summary: List used when VBox more
appropriate
• Description: A List control has lots of code
dealing with selecting items, clearly, this is not
about item selection
• Type: Performance, Maintainability
• Rule: Never use a List based component when
list functionality is not needed.
14. What is wrong with #3
• Summary: Properties are set on
controls, when data binding would be better
• Description: Setting properties on controls
• Type: Maintenance, Development Time
• Rule: Modify the Model, Let the View Follow
16. What is wrong with #4
• Summary: Views events handled in top level
component
• Description: View is dispatching an event
which is handled by a controller by passing
event data back to view
• Type: Maintenance, Separation of Concerns
• Rule: Always handle events as locally as
possible
18. What is wrong with #5
• Summary: Inappropriate container nesting
• Description: Additional containers added for
styling, not for child layout
• Type: Performance
• Rule: If you have a container with only one
child, you are usually doing something wrong.
20. What is wrong with #6
• Summary: reaching into a child of a child
• Description: Components should interact with
their children, not their children’s children
• Type: Separation of Concerns, Encapsulation
• Rule: Two dots and your out
22. What is wrong with #7
• Summary: unreadable code
• Description: Use functions, not complex
binding expressions
• Type: Maintainability
• Rule: Being too clever makes you a dumb-ass
23. Everyone Writes Bad Code -
sometimes
• If you spend some time in the SDK source
code, you can find gems like this:
var changeCount:int;
changeCount=Math.max(1,getStyle(quot;horizontalChangeCountquot;));
if (changeCount * 0 != 0){
changeCount = 1;
}
24. Rules To Live By
• Its never appropriate to use a container when
they will never have children.
• Never use a List based component when list
functionality is not needed.
• Modify the Model, Let the View Follow
• Always handle events as locally as possible
• If you find you have a container with only one
child, you are probably doing something wrong.
• Don’t be a dumb-ass
• Flex isnt broken, you are.