Overall description:
After everyone plays FLASH for a period of time, they will definitely form their own development habits. Good habits can avoid low-level mistakes and unnecessary troubles as much as possible, thereby accelerating the development process and improving the development quality. Although volcano is just an amateur now, the two years of accumulation and the development of the "Volcano House" have naturally formed a volcanic development habit. These habits reflect my current development level to some extent, so they are basically formed around small, fast, process-oriented development models, and are still very naive in many places. However, as my abilities continue to improve and my learning of object-oriented programming ideas in the future, it will definitely continue to be updated and improved.
Library folder classification habits：
- Put the sound and pictures in separate folders.
- MC classifies it to different folders according to the column.
- Generally, no graphics components are used.
Timeline management habits：
- The top layer is the AS layer. If the AS layer exceeds three layers, a special AS layer folder will be created. Multi-layer AS layers need to pay attention to the code execution order.
- The second layer is the label layer.
- Other layers in the main scene are classified by folders by column, but there is generally only one column in a MC and there is no need to classify them.
- Components with the same properties and little influence on each other are placed in one layer, and the others are layered independently, and layered up and down according to the visual effect.
- Loading, transition animation, and function pages are divided into different scenes.
Component naming habits：
- Naming of components in the library: Use Chinese naming, with the suffix of specific components added afterwards. For example, I have a component with "Navigation", and the button is named "Navigation BTN", and the video clip is named "Navigation MC". Sounds and pictures are named directly using "navigation".
- The three-step unity of naming: that is, the name of the component in the library, the instance name in the scene, and the name of the layer where it is located are kept as unified as possible. For example, if a component in the library is named "Navigation MC", then its instance name in the scene will be "daohang_mc", and the layer name it is located in will be "Navigation". This way, when there are many components and the code writing volume is very large, it can effectively save naming and search time, and avoid reference errors.
- Text domain naming: If there is only one dynamic text domain in a MC, it is uniformly named: "wenben_txt" and its variable is named "wenben_var". If there are more than two dynamic text fields, they are named according to their function.
Architectural habits：
- Three-layer separation: the main scene data layer, animation layer, and code function layer are separated. Because the data is loaded, the short animation will be unsmooth, so I usually load the data together in the loading scene and then enter the animation scene. A large number of timeline animations will cause the project structure to be confused, so I usually process the animation into an independent scene, copy the last one of the animation, and then create a new functional scene and paste it. All the core code is concentrated in the functional scene.
- MC structure: Since each MC is basically quite an independent small SWF, its structure also tries to follow the idea of "three-layer separation".
- MC Double Chase Style: Each MC maintains two chastity. Although in most cases, I can complete the task with Yizhen, I will still leave room for possible Yizhen data refresh.
- The component nesting structure generally does not exceed three layers. If you have no choice, you must also ensure that the code is not written on components below three layers.
- External calls SWF are all defined: _lockroot = true.
- _level0 is never used in externally called SWF unless otherwise required.
Volcano Chinese Pinyin oriented process structured code writing habits：
1. Code distribution: All codes are written on the timeline, generally on the first zodiac, and no code is written on the component. The code on the main scene is responsible for the initial setting of the entire system, and the code on each MC timeline is integrated.
2. Code structure: (In order from top to bottom in the code editor)
1 System initialization:
① Interface initialization: including encoding settings, stage settings, component visibility, usability and other initial settings.
②Variable initialization: timeline or global variable initialization.
③Array initialization: the initial array required and the value is assigned using a loop.
④ Object initialization: All objects required initially and register the listener.
2. Code logical structure: This is the logical structure of the entire code, which generally organically combines various functions through a series of function calls.
3. Function blocks: Generally, each function block is defined in the order in the logical structure and encapsulated into the function.
3. Naming habits: All are spelled in Chinese pinyin.
1. Variable naming: Use "var" to declare timeline variables, and use full Chinese naming. Example: var liuyan="";
2. Array and object naming: Use full spelling to add the corresponding suffix. Example: var shuzu_array=new Array(); var liuyan_lv=new LoadVars();
3. Function local variable naming: use the full spelling of "fc" suffix, example: function fanye(anniu_fc);
4. Naming of external communication variables: variables passed to FLASH externally, add the corresponding suffix:
Example: The variables passed to FLASH by txt are: liuyan_txt, and the ASP is: liuyan_asp.
FLASH is passed to external variables with "flash" suffix, example: yeshu_flash.
4. Comment habits:
1. The location of comments: I am usually used to writing comments in front of the code. That is, comment first and then code.
2. Comment frequency: Basically, it is annotated line by line, and at least it is annotated by function.
3. Comment structure:
Module-level code is separated by "==============================================.
Functional-level codes are separated by "—————”.
Generally, use "//" directly for comments.