Professional Documents
Culture Documents
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Martin Fowler
Planning
UML
Consider using UML to model application Start simple, dont go overboard Dont try to model the entire application Package ,Class, Interface diagrams Sequence diagrams *Component diagrams
Code Generation
Consider using code generation tools
(Round trip diagram to source code) (Generate diagrams from existing code)
Application/Business logic
More Design Patterns
Facade
Strategy
Use frameworks for team-based development efforts Know when NOT to use a framework
Design Patterns
Consider using design patterns: Strategy Command Singleton MVC Decorator Faade Composite
Workspaces
Cluttered / Slow
Clean/Fast
Workspace/Project hierarchy
Workspace
C:\kannopy\flex\client\
Project
TwitterFlexClient
UpperCamelCase
TwitterFlexClient.mxml
Setting up
Source code
Source Control
If not already: Use source control (SCM)
Track changes to codebase ALWAYS have a backup Critical in team environments Merge, difference, tag, branch, etc.
Source Control
Subversion, CVS, Perforce, GIT Subclipse for Flex Builder/Eclipse Dont include .project file or /settings directory (specific to each developers machine)
Use libs directory Reference shared SWC libraries using Flex Library path (under project properties)
Handling assets
File naming
TwitterFlexClient
Uppercamel casing
ILoggingTarget
Uppercamel casing , Begin file name with capital letter I
Coding standards
Packages
Dont use verbs, adjectives, adverbs for package names Name packages according to their classes: vo contains AccountVO, PhotoVO
package com.seantheflexguy.bestPracticesExample.vo {}
Classes
Append class types to the class name:
validators, formatters, events, and errors
com.seantheflexguy.burrow.validators.DateValidator
Constructor Getters/setter variables and methods Methods (grouped by functionality vs. scope)
Classes
Favor composition (HAS-A) over inheritance (IS-A )
Interfaces
Defines contract for implementing classes Enables runtime polymorphism
Advantages: Classes can implement multiple interfaces Classes cannot extend multiple classes Leaves class open to extend another class
Interfaces
public interface ISearchService { function search( criteria:String ):void; }
public class SearchService implements ISearchService { public function search( criteria:String ):void { } }
Variables
Use meaningful and descriptive variable names:
private var tmpHoldr;
Separate each variable declaration with a blank line Avoid the word object in identifiers: private var userObject;
Variables
Prefix Boolean variable names with can, is, or has
private var isAuthenticated:Boolean;
Capitalize constants:
DOMAIN, PORT, IP_ADDRESS
Prefix getter/setters with underscores and place the getter method above the setter method
Methods
Use meaningful and descriptive method names: private function doIt():void private function updateAfterEvent():void Use blank lines in between method definitions
Methods
Specify types for method arguments
parseResults( rawXMLData:XML ):ArrayCollection
Always provide return type even if it is void (returns nothing) or * (any type) Use blank spaces to separate keywords from parentheses
if (isAuthenticated) {}
MXML
XML Header <?xml version="1.0" encoding="UTF8"?> Root component (w/ namespaces) Metadata
Event Style Effect
Style definitions (external css file) Scripts (only one Script block) Non visual components Visual components
MXML
Place the ID attribute as the first attribute for MXML elements
MXML
Indent nested MXML elements <mx:VBox> <mx:HBox> <mx:Label text=Search:/> <mx:TextInput id=searchText /> <mx:HBox> <mx:TextArea id=resultsText /> <mx:VBox>
CSS
- Comment styles - Group similar definitions - One declaration per line
/** * * Defines style information for the Exit * button control for the main UI. * */
.exitButton {
fillAlphas: 0.76, 0.52, 0.75, 0.65; fillColors: #009933, #009966, #00cc66, #009999; color: #ffffff; textRollOverColor: #ffffff; themeColor: #009966;
CSS
Avoid in-line CSS
.redButton { }
ASDoc
/**
* * Use white space and leading asterisks increase comment readability * Do not use special characters in ASDoc comments (Hoses up ASDoc tool!) * */
- Use supported HTML to format the ASDoc output - Comment text should always precede any @ tags - Use @private for hiding classes from ASDoc - Use @return for methods with return types - Use @see for items that have relationships
Unit testing
Unit Testing
Use standard OOP best practices in test cases Encapsulation, inheritance, polymorphism, abstraction Document the test code
Apply the too simple to break rule for your unit tests Test complex methods and calculated properties not simple VO type classes
Books
Books
Programming Flex 3 Head First Design Patterns Pragmatic Programmer Beautiful Code Code Complete Programming Pearls Gang of Four (GOF) Design Patterns: Elements of Reusable ObjectOriented Software The Productive Programmer The Art of Interactive Design The Design of Everyday Things Dont Make Me Think