Thinking in programming

Things I like to talk about programming

Archive for the ‘Coding Conventions’ Category

Flex Coding Conventions

with 3 comments

This document is intended to set the coding
conventions for the Flex side.

General Requirements

Only the most recent release of Adobe Flex
should be used. Currently the release is “Flex 3”.

Standard object oriented programming principles
must be used in the Flex code development.

A concept for error handling should be provided
and used by the Flex developers.

A concept for security should be provided and

Necessary Development Concepts

The following is a list of necessary concepts for Flex application development:

  • Error handling and reporting.
  • Application security and authentication.
  • Client side input validation. In certain modules, it may be necessary to create concepts for L10N and I18N.


All package names should be meaningful and
should be prefixed with com.companyname. For example, org.rogerpadilla

When importing packages into classes, it is
preferred to import concrete classes instead of entire packages.


All files must be encoded in the UTF8

  • MXML file names: UpperCamelCase.mxml
  • ActionScript file names: for classes and all interfaces should be prefixed with I (

Classes, functions and code

The following is the set of coding rules
for ActionScript:

  • There should not be magic numbers, strings or values present in the code. Easily accessible constants, property files, xml files should be created where all such values will be kept. For example, a remote service URL should not be hardcoded.
  • Each class, function and class property should be commented. Non-obvious blocks of code should be preceded with a commented explanation of what they do.
  • Multiple variables should not be declared in a single line.
  • Multiple statements should not be placed on a single line.

The following is the set of coding rules
for MXML:

  • Use external style files.
  • There should be only one script block per MXML file, and it should follow the same guidelines as usual ActionScript files, because it should be exportable with asdoc.


All MXML files should contain a brief
desctiption if what they do and where they are used.

All ActionScript classes, functions and
class attributes should be commented with meaningful information in English. It
should be easy to create a documentation export using Flex’s asdoc tool,
where all packages, classes and functions can be reviewed.

For functions, there should be at minimum a
@param tag for each parameter, @return tag for returned
values, and a description of what the function does.


Written by roger.padilla

March 31, 2009 at 10:28

Posted in Coding Conventions

Tagged with ,

Conventions for Creation of SQL Queries, Indexes Tables and Fields

with 4 comments

  1. Whenever added a new table/field to the database, a comment with his purpose must be included.
  2. Use NOT NULL. Always define columns as NOT NULL unless there is a very good reason not to do so:
    • can save up to a byte per column per row of data
    • nullable columns make indexes, index statistics, and value comparisons more complicated.
  3. Use UNIQUE INDEX. If you have verified that each value for that index will/should not be repeated, then use an unique index (UNIQUE INDEX).
  4. Declaring the data type of a field to the more fixed-value, i. e., if you know the value of an int field is always going to become smaller than 10000, the you should use SMALLINT instead of INT.
  5. Use the smallest possible value for the lengths of the text fields. If you know that a zip code field will always hold not more than 10 characters, then you should use VARCHAR (10) and not VARCHAR (25).
    In cases like encrypted values with the MD5 algorithm, use CHAR (32).
  6. While write reserved keys use always capitalized sustained.

Useful info about the most common MySQL Data Types:

/* Unsigned Numeric Data Types */

TINYINT 0 to 255

SMALLINT 0 to 65535

MEDIUMINT 0 to 16777215

INT 0 to 4294967295

BIGINT 0 to 18446744073709551615

/* Text Data Types */

TEXT 65535 OR 64KB characters

MEDIUMTEXT 16777215 OR 16MB characters

LONGTEXT 4294967295 OR 4GB

Written by roger.padilla

March 31, 2009 at 09:25

General Coding Conventions

leave a comment »


1 Self explanatory code. Make sure your method, class, instance, param and all other self written names in your code are self explanatory.
2 Always include explanatory comments in the code. Make sure every class and method has comments explaining what it does and its purpose, this will make the API documentation easier to understand for other without diving into the code.


  • Get a random prime number starting to search it from a minimal number (default 1)
  • @param minNumber Number Optional minimal number where start the search. Default to 1
  • @return Number Random prime number
  • /

public function findRandomPrimeNumber(minNumber:Number = 1):Number {


3 Follow the DRY (Don’t repeat yourself) code philosophy. Make helpers. Make modules. Make plugins. Think in reusable components.

  • If you have a common functionality for two or more classes, please consider to include such functionality in a helper class.
  • If you made a class which have only static functions, like in the case of Utility or Helpers Classes, please consider to use the Singleton Pattern.
4 Avoid too long functions (more than 200 lines). Split to smaller internal functions as needed.


  • /

public function myLongFunction():void {

// Wash clothes

// Now dry them up

// Notify master that laundry is done

5 Avoid empty catch blocks. When the exception occurs, nothing happens, and the program fails for unknown reasons.

In general, when a exception occurs, it can be thrown up to the caller, or it can be caught in a catch block. When catching an exception, some options include: inform the user (strongly recommended), log the problem, send an email escribing the problem to an administrator. Deciding what exactly to do seems to depend on the nature of the problem. If there is an actual bug in the program – a defect that needs to be fixed – then one might do all three of the above. In this case, the end user should likely be shown a generic “Sorry, we goofed” message, not a stack trace. It is usually considered bad form to display a stack trace to a non-technical end user, or if exposing a stack trace may be a security risk. If the exception does not represent a bug, then different behavior may be appropriate.
6 Always include { and } on the statements, even if there is a single block code line.
7 Be sure of read all the coding conventions on: Coding Guidelines


1 Only one return on a same function. Do not use returns to break the flow of the code.

  • If you want to know where something is returned, you have to look for the return statement. With multiple return statements you have to go read the complete method and find all the exit points of a method. (isn‘t your method too big?)
  • If you want to log before you exit a method, so with multiple return statements you need to place that logging code before all return statements.

Written by roger.padilla

February 15, 2009 at 15:10

Posted in Coding Conventions

Tagged with