Overall explanation: After playing FLASH for a period of time, everyone will definitely form their own set of 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:
1. Put the sound and pictures in separate folders and at the bottom of the library.
2. MC will classify it into different folders according to the column.
3. Generally, no graphics components are used.
→Timeline management habits:
1. 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.
2. The second layer is the label layer.
3. Other layers in the main scene are classified by folders according to columns, but there is generally only one column in a MC and there is no need to classify them.
4. A component with the same properties and little influence on each other is placed in one layer, and the others are layered independently, and layered up and down according to the visual effect.
5. Loading, transition animation, and function pages are divided into different scenes.
→Component naming habits:
1. Naming of components in the library:It is named in Chinese, and the suffix of a specific component is 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".
2. 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.
3. Text domain naming: If there is only one dynamic text field 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:
1. 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.
2. MC structure: Since each MC is basically quite an independent small SWF, its structure also tries to follow the idea of "three-layer separation".
3. MC double chastity 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.
4. 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.
5. All external calls to SWF are defined: _lockroot = true.
6. _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: Here 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 the timeline variables, and use full Chinese name, with capital letters, 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 variable passed to FLASH by txt is: 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 comments line by line, at least function by function.
3. Comment structure:
Module-level code is separated by "========================================.
Functional-level codes are separated by "—————”.
Generally, use "//" directly for comments.
★Blacking words:
I can think of so many things today. Since I think of it first, it must be my deep-rooted habit. If I think of it in the future, I will make up for it. In fact, I mainly use three intentions to post this post: first, self-consolidation and improvement; second, when I have nothing to do in the future, I may write tutorials, which will facilitate newbies to understand my source files; third, I hope that senior experts with development experience will also talk about their habits so that they can show us the best way for the younger generations!
In addition, this article is actually an overview of the most basic operating habits, and there are many advanced or special habits and many details. I won’t write them here for now, otherwise the overall nature of the article will be messed up, and I will definitely not finish writing one or two sentences in a while. Let’s analyze the specific project and the specific problem:)
→ Library folder classification habits:
1. Put the sound and pictures in separate folders and at the bottom of the library.
2. MC will classify it into different folders according to the column.
3. Generally, no graphics components are used.
→Timeline management habits:
1. 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.
2. The second layer is the label layer.
3. Other layers in the main scene are classified by folders according to columns, but there is generally only one column in a MC and there is no need to classify them.
4. A component with the same properties and little influence on each other is placed in one layer, and the others are layered independently, and layered up and down according to the visual effect.
5. Loading, transition animation, and function pages are divided into different scenes.
→Component naming habits:
1. Naming of components in the library:It is named in Chinese, and the suffix of a specific component is 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".
2. 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.
3. Text domain naming: If there is only one dynamic text field 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:
1. 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.
2. MC structure: Since each MC is basically quite an independent small SWF, its structure also tries to follow the idea of "three-layer separation".
3. MC double chastity 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.
4. 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.
5. All external calls to SWF are defined: _lockroot = true.
6. _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: Here 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 the timeline variables, and use full Chinese name, with capital letters, 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 variable passed to FLASH by txt is: 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 comments line by line, at least function by function.
3. Comment structure:
Module-level code is separated by "========================================.
Functional-level codes are separated by "—————”.
Generally, use "//" directly for comments.
★Blacking words:
I can think of so many things today. Since I think of it first, it must be my deep-rooted habit. If I think of it in the future, I will make up for it. In fact, I mainly use three intentions to post this post: first, self-consolidation and improvement; second, when I have nothing to do in the future, I may write tutorials, which will facilitate newbies to understand my source files; third, I hope that senior experts with development experience will also talk about their habits so that they can show us the best way for the younger generations!
In addition, this article is actually an overview of the most basic operating habits, and there are many advanced or special habits and many details. I won’t write them here for now, otherwise the overall nature of the article will be messed up, and I will definitely not finish writing one or two sentences in a while. Let’s analyze the specific project and the specific problem:)