Rules
| 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.
/**
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.
|
| 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 |
Recommendations
| 1 | Only one return on a same function. Do not use returns to break the flow of the code.
|
