總體說明：
每個人玩FLASH一段時間后，肯定都會形成自己的一套開發習慣。好的習慣可以盡可能避免低級失誤和不必要的麻煩，從而加速開發進程，提高開發質量。火山現在雖然只是業余愛好者，但兩年的積累，再加上“火山之家”的開發，也自然而然的形成了火山特色的開發習慣。這些習慣從某種程度反映了我現在的開發水平，所以它基本上都是圍繞著小型、快捷、面向過程的開發模式形成的，很多地方還很幼稚。不過以后隨著我能力的不斷提高，以及對面向對象編程思想的學習，它肯定還要不斷的更新和完善。
庫文件夾分類習慣：
- 聲音、圖片各自放到獨立的文件夾。
- MC則根據欄目進行分類到不同的文件夾。
- 一般不用圖形元件。
時間軸管理習慣：
- 最上層為AS層，如果AS層超過三層，則建立專門的AS圖層文件夾。多層AS層需要注意代碼執行順序。
- 第二層為標簽層。
- 主場景其它圖層按欄目進行文件夾分類，但一個MC內一般僅為一個欄目，不用分類。
- 相同性質而且相互影響不大的元件放一層，其它的獨立分層，并按視覺效果進行上下分層。
- loading、過渡動畫、功能頁面分在不同的場景。
元件命名習慣：
- 庫中元件的命名：采用中文命名，后邊添加特定元件的后綴，比如我有一個“導航”的元件，按鈕則命名為：“導航BTN”，影片剪輯則命名為：“導航MC”。聲音和圖片則直接使用“導航”命名。
- 命名的三步統一性：即元件在庫中的名字，在場景中的實例名，以及所在層的名字盡量保持統一。比如一個元件在庫中的名字為：“導航MC“，則它在場景中的實例名將為“daohang_mc”，它所在的層名將為“導航”。這樣在元件非常多，代碼編寫量非常大的時候，可以有效的節省命名和查找時間，同時避免引用錯誤。
- 文本域命名：如果一個MC中僅有一個動態文本域，則統一命名為：“wenben_txt”，其變量名為“wenben_var”。如果有兩個以上動態文本域，則根據其功能進行命名。
架構習慣：
- 三層分離：主場景數據層，動畫層，代碼功能層進行分離。由于數據加載完成時，會導致短暫的動畫不流暢，所以我一般在loading場景中把數據一起加載完成，然后進入動畫場景。大量的時間軸動畫又會導致項目結構混亂，所以我一般又會把動畫也處理成獨立場景，將動畫最后一貞復制，然后建立新的功能場景并粘貼，所有的核心代碼都集中在功能場景中。
- MC結構：由于每個MC基本又相當一個獨立的小SWF，所以它的結構也盡量遵從“三層分離”的思想。
- MC雙貞式：每個MC都保持兩貞。盡管大部分情況下，都可以用一貞完成任務，但我還是會專門留一貞，為可能的貞數據刷新留有余地。
- 元件嵌套結構一般不超過三層，迫不得已的情況下，也要保證代碼不寫在三層以下的元件上。
- 外部調用SWF全部定義：_lockroot = true。
- 外部調用的SWF中絕不使用_level0，除非特別需要。
火山中文拼音面向過程結構化代碼編寫習慣：
一、代碼分布：所有代碼均寫在時間軸上，一般都在第一貞，元件上絕不寫代碼。主場景上的代碼負責對整個系統的初始設置，各MC時間軸上的代碼各成一體。
二、代碼結構：（按代碼編輯器中從上到下的順序）
1系統初始化：
①界面初始化：包括編碼設置，舞臺設置，元件可見性，可用性等等初始設置。
②變量初始化：時間軸或者全局變量初始化。
③數組初始化：初始需要的數組，并利用循環進行賦值。
④對象初始化：初始需要的所有對象，并注冊偵聽器。
2、代碼邏輯結構：這里是整個代碼的邏輯結構，一般通過一系列的函數調用使各種功能有機結合。
3、功能塊兒：一般按邏輯結構中的順序定義各個功能塊兒，并封裝到函數中。
三、命名習慣：全部采用中文拼音全拼。
1、變量命名：使用“var”進行時間軸變量聲明，并且采用中文全拼命名，示例：var liuyan="";
2、數組和對象命名：采用全拼加對應的后綴，示例：var shuzu_array=new Array(); var liuyan_lv=new LoadVars();
3、函數局域變量命名：使用全拼加“fc”后綴，示例：function fanye(anniu_fc);
4、外部通信變量命名：外部傳遞給FLASH的變量，添加對應的后綴:
示例：txt傳遞給FLASH的變量用：liuyan_txt，ASP則為：liuyan_asp。
FLASH傳遞給外部的變量加“flash”后綴，示例：yeshu_flash。
四、注釋習慣：
1、注釋的位置：我一般習慣把注釋寫在代碼前面。也就是先注釋再代碼。
2、注釋頻率：基本上是逐行注釋，最少也是逐功能注釋。
3、注釋結構：
模塊級代碼用"==============="分隔。
功能級代碼用"——————"分隔。
一般注釋直接用"//"。