Flex Formatter plugin (FlexPrettyPrint)

If you want to automate a code review process regarding coding convention then you can install Flex Formatter plugin in FlexBuilder or eclipse and then configure formatting for ActionScript and MXML with help of coding convention checklist document (example of ActionScript coding convention checklist).

Update Site URL – http://flexformatter.googlecode.com/svn/trunk/FlexFormatter/FlexPrettyPrintCommandUpdateSite

After installing you will be able to configure formatting in Preferences window and to export properties files to share them with your team or to import in an other projects.

Flex Formatting Preferences

Then when you save a file or perform a predefined key combination for formatting all code will be formatted automatically. This will save a lot of time for you and your team members.

ActionScript coding convention checklist

Here is a checklist which I think is useful when you need to review your ActionScript code.

Also I’m adding an example.zip with ‘CheckList Template.docx’ file, ‘CodeConventionClass.as’ file and ‘CodeConventionClass Attachment.xlsx’. (Please do not forget to change extension from .doc to .zip after downloading).

1. English grammar and spelling.
2. Copyright comment is added and used /**   */ format.  Copyright comment includes such information as: a year of company foundation – current year, company name and “All rights reserved” string.


* Copyright 1991-2010 Company Name. All rights reserved


3. Package names must use “reverse domain” naming convention.

4. Braces “{“ and “}” are placed on separate line.

5. Organize imports by sections. Separate sections with empty line.

6. Imports don’t contain unnecessary classes or packages.

7. Class comment is added and used /**   */ format. Class comments should include class purpose and author.

8. Each author in Class comment should be placed on a new line. If you are the person who is modifying somebody’s class then you can do this way:

@author Name Surname (modified).

9. Class name is in UpperCamel format.

10. Constants are placed using priority order – public, private.

11. Base variables section has priority order – public, private.

12. Private variables must start with an underscore “_”.

13. Boolean variables should start with “is”.

14. Public variables must not contain underscore “_”.

15. Used one empty line between separate variables sections.

16. Used two empty lines before Constructor.

17. Method comments are added and used /**   */ format. Description for parameters and returned value is added.

18. Meaningful constants are used in compound, while and dowhile, switch statements instead of using just a value.

19. Added a space after “(“ and before “)”. And a space is added only after “:” character.

20. Types declaration used for variables and parameters declaration conforms.

21. Copy-Paste style of coding avoided.

22. Code organized according to system design.

23. Event listeners names should start with event dispatcher name, then event type and then key word “Handler” (getItemActionResultHandler, btnSaveClickHandler) .

24. Comment of handlers’ methods is started from a word “Handles” and a description for transferred parameter is added.


* Handles socket connection

* @param e – Event.CONNECT


25. Parameters in methods must not start from underscore “_” or “$”.

26. All added event listeners should be removed when not used anymore.

27. Resources are removed if they are not used anymore to free memory. Example, when window is closed.

28. Keyword ‘this’ is used to address methods and variables. Using thiskeyword allows us to distinguish global variables from local and to see calling of methods through a lot of strings in a class.

29. Complex constructions and long methods avoided.

30. Code is consistent to system design and approaches.

31. Avoid using public variables in general, as it does not properly encapsulate the software design; instead use getter/setter conventions.

32. Public fields and methods used only when necessary.

33. Usage of design patterns only when needed.

34.trace statements are removed or commented.