360Flex - Jeff Tapper on How Not to Code Flex Applications

Jeff Tapper discusses bad code, worst practices and why developers code badly. Bad code is code that doesn't fit the needs of the project taking into consideration efficiency, maintainability and time to develop. Usually this is due to a lack of time, lack of knowledge or a lack of caring. At some point, we all right bad code...sometimes knowingly.

Jeff went to show some examples of "worst practices." The first example used a VBox for displaying a graphic by assigning the image as a style for the VBox (i.e. the image was not a child of the VBox but was the background of the VBox which had no children). Jeff says that misuse of containers is a common mistake.

The next example was someone using a List with an ItemRenderer which was purely for displaying data. The issue here, Jeff says, was that Lists should be used when you are selecting data not displaying data. In this case, he says he would use a repeater to simply display multiple VBox's. There were some exceptions to this rule that he covered, such as when you might be displaying a large number of items because a List is good at recycling display objects.

The third example showed a function manually setting the text property of some TextInput. The idea here was that you should bind the TextInput's to a data model rather than manually set items in this manner. This way when you modify the model, the view will automatically update.

The following example was a simple login form built with the Cairngorm framework. In this example the login button submitted an event that went to the controller and called a Command that then changed the ModelLocator which had the effect of changing the state of the form. Basically, this went in a big circle to update the state of the very form that fired the event. The suggestion here is to keep events as locally as possible - in this case, just have the login button's click handler change the state. As with other rules, some exceptions were discussed.

The fifth example showed a VBox container with only a Text input. The container was used entirely for styling and not for "containing" and thus the VBox was completely unnecessary. The exception here was that ViewStacks require that children are containers and might require this rule be broken.

Example 6 showed a display element reaching into a child element and binding to a property of that element. This creates a very tight coupling as the parent container needs a specific implementation within the child component due to the binding. The rule Jeff states is "two dots and you're out" - i.e. deal with your children not your children's children. This example brings up the most debate from the audience.

The seventh example showed a button that bound its enabled property to an extremely long statement that was long enough to be difficult to discern its intent. Instead, this example should have bound to a function rather than placing all the logic within the bind statement. The rule for this one is "being too clever makes you a dumb-ass" which brings up some references to programming in Perl and some laughter from the audience.

The final example comes out of the Flex SDK which test if a variable multiplied by zero is not equal to zero. In this case Matt Chotin comes to the "defense" of the issue stating that it was something in the port from AS2 that wasn't caught. However, the point Jeff was trying to make was that everyone writes bad code sometimes.