Flash basic Development Habits 1th/2 page _flash Tutorial

General Description:
Everyone playing flash for some time, will certainly form their own set of development habits. Good habits can avoid low-level mistakes and unnecessary problems as much as possible, thus speeding up the development process and improving the quality of development. Although the volcano is now amateur, but two years of accumulation, coupled with the "Volcano House" development, but also naturally formed a volcanic characteristics of the development habits. These habits in some way reflect my current level of development, so it is basically around the small, fast, process-oriented development model, many places are very naïve. However, with the continuous improvement of my ability, as well as the learning of object-oriented programming ideas, it must be constantly updated and perfected.

Library Folder Classification habits :

• Sound and pictures are placed in separate folders.
• The MC is categorized into different folders according to the columns.
• No graphical components are generally used.

Timeline Management habits :

• The top-level is the as layer, and if the as layer is over three layers, a specialized as layer folder is established. Multilayer as layers need to be aware of the sequence of code execution.
• The second layer is the label layer.
• The main scene of other layers by column folder classification, but a MC in general only a column, do not classify.
• Elements of the same nature with little impact on each other are placed one layer, the other independent layering, and the visual effects of the upper and lower layers.
• Loading, transition animation, feature pages are divided into different scenes.

component naming habits :

• Name of the components in the library: in Chinese name, add the suffix of a specific component, such as I have a "navigation" components, the button is named: "Navigation Btn", the movie clip is named: "Navigation MC." Sounds and pictures are named directly using the navigator.
• Named three-step uniformity: The name of the component in the library, the instance name in the scene, and the name of the layer to be as consistent as possible. For example, a component in the library name is: "Navigation MC", it is in the scene of the instance name is "DAOHANG_MC", it is located in the layer name "navigation." In this way, when the number of components is very large, the amount of code written is very high, you can effectively save the naming and lookup time, while avoiding reference errors.
• Text field naming: If there is only one dynamic text field in an MC, it is named "Wenben_txt" and its variable name is "Wenben_var". If there are more than two dynamic text fields, they are named according to their capabilities.

Architectural habits :

• Three layer separation: Main scene data layer, animation layer, code function layer to separate. Because the data load completes, will cause the short animation to be not fluent, therefore I generally in the loading scene loads the data to complete together, then enters the animation scene. A large number of time axis animation will cause confusion in the project structure, so I usually will be the animation also processed as a stand-alone scene, the animation of the last one to copy, and then create a new feature scene and paste, all the core code is concentrated in the functional scene.
• MC structure: Because each MC basic and quite an independent small SWF, so its structure also as far as possible comply with "three layer separation" thought.
• MC Double-Jeong: Each MC is kept two-jeong. Although most of the cases can be used to complete the task of a Zhen, but I will be dedicated to a chastity, for the possibility of chastity data refresh room.
• Component nesting structure generally does not exceed three layers, in the case of compelling, but also to ensure that the code is not written in the three-layer components.
• External invocation swf all defined: _lockroot = True.
• _level0 is never used in an externally invoked SWF unless specifically required.

Chinese pinyin for volcanoes process-oriented structured code writing habits :

One, code distribution: All the code is written on the timeline, generally in the first chastity, components never write code. The code on the main scene is responsible for the initial setup of the entire system, and the code on each MC timeline is integrated into one.

Second, code structure: (in the Code Editor from top to bottom in order)
1 System initialization:
① interface initialization: Includes encoding settings, stage settings, component visibility, usability, and so on.
② variable initialization: The timeline or global variable initialization.
③ Array initialization: An array that is initially required and is assigned using loops.
④ Object initialization: All initially needed objects, and registers the listener.
2, the Code logic structure: Here is the entire code logic structure, generally through a series of function calls to make a variety of functions organically combined.
3, function block: Generally in the logical structure in order to define each function block, and encapsulated into the function.

Third, the naming habit: all use Chinese pinyin whole spelling.
1, variable naming: Use "var" for the timeline variable declaration, and use Chinese all desperately name, example: Var liuyan= "";
2, array and object naming: Using the full spelling of the corresponding suffix, example: var shuzu_array=new array (); var liuyan_lv=new loadvars ();
3, function of the local variable naming: Using the full spell "FC" suffix, example: function Fanye (ANNIU_FC);
4, external communication variable name: external to the flash variable, add the corresponding suffix:
Example: TXT passed to flash variable use: liuyan_txt,asp is: liuyan_asp.
Flash is passed to external variables plus "flash" suffix, example: Yeshu_flash.

Four, the annotation custom:
1, the location of the note: I am generally used to write notes in front of the code. Which is to annotate and then code first.
2, the annotation frequency: basically is the line-by-row annotation, at least is the functional annotation.
3. Annotation structure:
Module-level code is delimited by "===============".
The functional level code is delimited with "——————".
General comments are made directly with "//".

Current 1/2 page 12 Next read the full text