★总体说明：每个人玩FLASH一段时间后，肯定都会形成自己的一套开发习惯。好的习惯可以尽可能避免低级失误和不必要的麻烦，从而加速开发进程，提高开发质量。火山现在虽然只是业余爱好者，但两年的积累，再加上“火山之家”的开发，也自然而然的形成了火山特色的开发习惯。这些习惯从某种程度反映了我现在的开发水平，所以它基本上都是围绕着小型、快捷、面向过程的开发模式形成的，很多地方还很幼稚。不过以后随着我能力的不断提高，以及对面向对象编程思想的学习，它肯定还要不断的更新和完善。

→库文件夹分类习惯：
1，声音、图片各自放到独立的文件夹。
2，MC则根据栏目进行分类到不同的文件夹。
3，一般不用图形元件。

→时间轴管理习惯：
1，最上层为AS层，如果AS层超过三层，则建立专门的AS图层文件夹。多层AS层需要注意代码执行顺序。
2，第二层为标签层。
3，主场景其它图层按栏目进行文件夹分类，但一个MC内一般仅为一个栏目，不用分类。
4，相同性质而且相互影响不大的元件放一层，其它的独立分层，并按视觉效果进行上下分层。
5，loading、过渡动画、功能页面分在不同的场景。

→元件命名习惯：
1，库中元件的命名：采用中文命名，后边添加特定元件的后缀，比如我有一个“导航”的元件，按钮则命名为：“导航BTN”，影片剪辑则命名为：“导航MC”。声音和图片则直接使用“导航”命名。
2，命名的三步统一性：即元件在库中的名字，在场景中的实例名，以及所在层的名字尽量保持统一。比如一个元件在库中的名字为：“导航MC“，则它在场景中的实例名将为“daohang_mc”，它所在的层名将为“导航”。这样在元件非常多，代码编写量非常大的时候，可以有效的节省命名和查找时间，同时避免引用错误。
3，文本域命名：如果一个MC中仅有一个动态文本域，则统一命名为：“wenben_txt”，其变量名为“wenben_var”。如果有两个以上动态文本域，则根据其功能进行命名。

→架构习惯：
1，三层分离：主场景数据层，动画层，代码功能层进行分离。由于数据加载完成时，会导致短暂的动画不流畅，所以我一般在loading场景中把数据一起加载完成，然后进入动画场景。大量的时间轴动画又会导致项目结构混乱，所以我一般又会把动画也处理成独立场景，将动画最后一贞复制，然后建立新的功能场景并粘贴，所有的核心代码都集中在功能场景中。
2，MC结构：由于每个MC基本又相当一个独立的小SWF，所以它的结构也尽量遵从“三层分离”的思想。
3，MC双贞式：每个MC都保持两贞。尽管大部分情况下，都可以用一贞完成任务，但我还是会专门留一贞，为可能的贞数据刷新留有余地。
4，元件嵌套结构一般不超过三层，迫不得已的情况下，也要保证代码不写在三层以下的元件上。
5，外部调用SWF全部定义：_lockroot = true。
6，外部调用的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，注释结构：
     模块级代码用"==============="分隔。
     功能级代码用"——————"分隔。
     一般注释直接用"//"。

★唠叨两句：
    今天暂时就能想到这么多了，既然是第一时间想到的，肯定都是我根深蒂固的习惯，以后想到了，再补上来。其实我发这个帖子主要有三个用意：第一，自我巩固和提高；第二，以后没事的时候，我可能会来写写教程，这个东西会方便新手们看懂我的源文件；第三，希望富有开发经验的前辈高手们也谈谈自己的习惯，好给我们这些后辈指条名路！
    另外，这篇文章写的其实都是些最基本的操作习惯概述，还有很多高级的或者是特别的习惯以及很多细节，这里先不写了，不然会把文章的整体性搞乱，而且一时半会儿、一句两句肯定也写不完。具体到哪个项目再具体问题具体分析吧：）

[ 本帖最后由 jimohuoshan 于 2006-12-10 20:36 编辑 ]

Very Good!
论坛就是需要这样的经验总结贴。
继续，加油。 ^_^
我要转载到我的博客上，先打个招呼。呵呵。

另外抛砖引玉，我有几点不同看法：

AS1.0开发：
因为火山谈的是在时间轴中的开发，因此我下面的意见只是AS1.0开发经验。
1.对于火山这样的老手，我建议应当把图形元件看成MovieClip的私有元件，在单帧矢量图片和循环播放这两种情况下尽可能多用它，有利于执行效率提高。对于新手，则干脆全用MC好了。
2.文件夹只是用来理顺图层关系的，多用不太好。应当尽可能的把动画分解成一个个MC，增加重用率。改动时也方便统一改动。
如果你发现自己文件夹过多时，往往是你的动画没有分解好。
3.赞同火山，库中元件分类是很好的习惯。怎么强调也不过分。
4.动态文本框再也不要用变量名了，统一用xxx.text来赋文本。动态文本变量名这种用法是应该废弃的，弊端多多。
5.AS代码不论是在主时间轴，还是在单独MC中都不应超过一层。集中管理。
把主要的代码集中在关键的几个关键帧，所有代码都用#include 外部文件。使用外部文本编辑器编辑，提高效率，如FD，SEPY。
6.把全局变量减少到最低限度。所有MC都应该看成独立的组件，与上层父组件保持最少的联系。

再小谈一下2.0中的时间轴的特征：
好的2.0开发，是没有时间轴概念的，整个Fla只有一帧，而Loading功能抽象出单独的swf比如我的KLoader组件在RIA项目就是扮演这样的角色。很好的东东，可以带来很多的益处：
1，轻松解决了频繁改动代码Export到第xx帧，完全不用管。
2.所有的外部设置初始化统一在loader.swf中完成，例如：可以统一控制帧频，初始化右键菜单，增加logo，等等所有初始化工作。便于维护管理。
3.轻松统一更换站点所有loader皮肤，更新一个loader.swf即可。
4.统一管理父级向子级swf传参数。
等等等，好处多多啊。
.......
2.0的开发，经验和注意之点太多了，日后有机会整理出来和大家分享。

而时间轴中，我的习惯，一般分两三层，背景等美工单独放置一层。一般，只有三层，第一层as代码，第二层功能组件，第三层放一些美工背景等等之类的视觉元件。只有一帧。

经典的经验，先学习了！

坐稳了看``

呵呵，难得有人开个头，不然平时也没想到哈
我也来交流一下自己的经验吧

1 自定义元件库的管理
推荐用文件夹分类。最大的类别应该是功能模块，比如说就是导航，建立导航文件夹，文件夹里再有第二级的分类，我按照的是图片，按钮（包括MC按钮），MC，有关联类的MC，主场景MC（就是可以被其他模块使用的，像Interface中的接口）。另外还有有个common功能模块，放组件，声音，视频什么的共用元件。

2 方法的命名
变量的命名楼主都说了，我想谈谈函数的命名。推荐“骆驼”试命名法，从语法上来说是动宾结构，比如getMovieClipName()，四个词，第一个是动词，除第一个词外首字母大写，这样的命名比较好说明函数的用途。

3 提高类的颗粒度，类功能单一化
多写几个类没有坏处，类的功能尽量单一，不要让一个类做各种各样不相干的事，这样后期的修改会非常麻烦。

4 基于接口的OOP编程
java要求为每个类都配个interface，其实不用那么夸张。但是这个思路值得借鉴，让接口来代替具体的实现类跟别的类交互，如果以后有扩展，只需要再写个实现类，不用修改交互部分的代码了。

5 设计比编码重要
一上来写代码绝对是不行的。先好好规划自己的系统，从大的流程到细小的逻辑实现，尽量的做到心中有数。这样才不会在做的过程中感觉混乱。

不错,受益!

别骂我菜,呵呵

再小谈一下2.0中的时间轴的特征：
好的2.0开发，是没有时间轴概念的，整个Fla只有一帧，


2.0中时间轴动画怎么处理,,kingda版主讲一下好吗?

看火山的代码一直都很头疼的，拼音也就算了，竟然每个变量名都超长。。。。

看来我的习惯还是不好啊.

大家的激情很高啊，现在突然发现我这个帖子题目有点自我了，干脆改成“FLASH基础开发习惯讨论”算了，这样方便大家一起参与讨论

TO：KingdaSun，谢谢鼓励，等待你更详细的总结。
不过你帖子中有两个知识点我太理解：
1，你说使用图形元件可以提高执行效率，这点我有怀疑，以前还专门测试过，跟MC相比，没见有太大差异啊？
2，动态文本域不推荐使用变量名，这个我也好多地方说了，但一直没搞懂它的弊端到底是什么？还望指明。
3，你那个loader.swf的做法很值得借鉴！
另外，我现在对面向对象编程还没深入研究，就不乱发言了：）

TO：noahgenius，你提到了库的管理，KingdaSun斑竹也强调了这点，本来我想等到《火山之家开发总结》中再详细谈这个的，但现在忍不住先说两句把，在我看来，库的管理应该跟网站文件夹分类一样有两大模式。一个模式主要面向小型开发，这时可以采用按功能模块儿分，比如我的网站有一个导航栏目，就专门建立一个“导航栏目”文件夹，把导航栏目所用到的所有元件，图片，声音都放进来，然后又有一个“新闻更新”栏目了，再建一个“新闻更新”文件夹，也把所有元件都放进去。但如果我们的“导航栏目”和“新闻更新”文件夹下又有好多文件怎么办呢？当然我们还可以在每个栏目文件夹下再建立类似“MC”，“图形”，“声音”，“图片”这样的文件夹。这样做的好处是方便查询，但弊端也出来了，就是文件夹累赘，在每个模块文件夹下都建立一遍元件类型文件夹。所以第二中面向中型开发的分类模式就出来了，就是按元件类别进行最顶级分类，然后大型功能模块，然后是小型功能模块。其实这是一个很丰富的课题，这个帖子中就先说这么多吧：）

TO：heimuxiao，在FLASH开发，尤其是追求效果的FLASH WEB开发中，一点不用时间轴有点不切实际，我想斑竹的意思是把动画动放到独立的MC中，然后把MC放到第一贞吧。

TO：kvgnt，没办法啊，我英语不好，又想进行大规模开发，暂时只有用这个办法。可能是你对拼音命名不习惯不吧，其实我的命名不算长的，你看看MM组件里的命名，那才叫长

TO：HBrO，你也写写自己的开发习惯啊，我们一起来研究研究：）

[ 本帖最后由 jimohuoshan 于 2006-12-8 14:09 编辑 ]

图形元件跟脚本没有关系,因此,运行的时候不需要像MovieClip类那样,储存太多的信息.而且,图形不是独立于时间轴的,那么,运行的时候,也就不会太消耗资源.
至于库的管理,我好像真的不太喜欢用文件夹,虽然自己知道这个习惯不好.主要是不同文件夹里头的元件,名称也不能重复的原因吧,我通常都是用folder1_folder2_symbol1这样的格式来给库的东西命名的.
至于单帧,在Flash Web里头,我觉得也没必要太刻意地去追求.毕竟动画也是Flash的优势嘛.当然,如果是对动画要求不高的程序开发就另当别论.这里,我说下2AD的吧,它的V5版就是用AS2.0类开发的,不同的类在不同的时间轴里调用,但是我个人感觉也不是一个失败的AS2.0开发啊,毕竟我看它的结构跟表现还是分离得不错的.

yongpinyin  和 YongPinYin 比起来还是后面的容易读些.

TO：HBrO，按你说的好象挺有道理，不过你对图形和MC进行过数据上的测验吗？我觉得还是数据更有说服力，所以还是有点怀疑：）另外，不同文件夹下的元件是可以使用同一个名字的。

TO：kvgnt，我也一直在考虑改进一下，不知道yongPinYin和yong_pin_yin那个更容易被人接受啊？

用首字母大写应该会好点, _ 在有些时候起连接作用的,到处都是 _ 的话就没意义了. 英文书写一般也都是单词首字母大写.

我之想和楼主说.... 你的变量命名赶快改成英文把, 拼音太可怕了

http://livedocs.macromedia.com/flash/8_cn/main/00001640.html

or

http://livedocs.macromedia.com/f ... ;file=00001640.html

[ 本帖最后由 abc12hjc 于 2006-12-8 18:12 编辑 ]

引用:

原帖由 kvgnt 于 2006-12-8 05:46 PM 发表
用首字母大写应该会好点, _ 在有些时候起连接作用的,到处都是 _ 的话就没意义了. 英文书写一般也都是单词首字母大写.

按照 java 的习惯, 变量, 属性, 方法首字母小写, 类名首字母大写, 单词之间使用大小写分割, 但遇到特殊单词并不强制大小写分割, 如, HTMLEncode, Object.toString,
按照 c 习惯, 变量, 属性名, 方法名以及类名首字母都大写, 单词之间使用大小写风格, 并且遇到特殊单词强制大小写风格, 如 HtmlEncode, Object.ToString

MM 是亲 J 的

区分大小写的语言中一般用  骆驼命名法 (Java)
不区分大小写的语言中一般用  下划线命名法 (PHP)

首字母全部大写的是  帕斯卡命名法

类名  帕斯卡命名法
函数/方法名  骆驼命名法
变量/属性  匈牙利命名法

[ 本帖最后由 abc12hjc 于 2006-12-8 18:09 编辑 ]

abc12hjc给我的那个网页我怎么打不开，郁闷！

我E文不好啊！
以前都是自己玩的，把主要精力放在了“能不能做出来”上
再有半年就毕业了，而且我还想从事这方面的工作，是该把主要精力放在“能不能让别人看懂”上的时候了！
其实我高中E文挺好的，上大学老是不用就废了，恢复一下应该还能应付一般小项目：）

[ 本帖最后由 jimohuoshan 于 2006-12-8 18:14 编辑 ]

MM在AS2语法中规定:首字母大写的名称默认为类或接口的名称

引用:

原帖由 xbstu2006 于 2006-12-8 18:14 发表
MM在AS2语法中规定:首字母大写的名称默认为类或接口的名称

这是“约定”，而不是“规定”。

P.S: 接口命名约定为，帕斯卡命名法且首字母前加大写"I"

[ 本帖最后由 abc12hjc 于 2006-12-8 18:22 编辑 ]

好贴！建议大家截图；

要不贴到blog上吧，把链接留下

引用:

原帖由 HBrO 于 2006-12-8 14:20 发表
图形元件跟脚本没有关系,因此,运行的时候不需要像MovieClip类那样,储存太多的信息.而且,图形不是独立于时间轴的,那么,运行的时候,也就不会太消耗资源.
至于库的管理,我好像真的不太喜欢用文件夹,虽然自己知道这 ...

2AD的V5，相比之前的版本，少了很多细腻的动画效果哦。这一版的体验我觉得还不如V3，V4。其实2AD并没有创新太多的交互方式，更像是在原来的html平面排版加入过渡。当然他们的作品不全是这样，以前的一个人力资源系统给我印象很深

没有测试过.
另外,我发现不能用同样的名字啊,就算是不同文件夹.

也同意使用英文名作为元件名称,如果用拼音,还不如把元件名都改成中文好了.

太长了，先Mark一下，回来在看

各位老师级的还是多讲点AS3吧
我都后悔学了AS2

TO：HBrO
库中不同文件夹下的元件是可以同名的，比如我们直接在库中右键新建一个MC，命名为：导航，这时候如果想再建一个名字为“导航”的MC，则需要建立一个文件夹，然后把已经建立的“导航”MC拖到这个文件夹下，然后就可以再在建立主库中新建一个名字同样为“导航”的MC了。我用FLASH8简体中文个人版，测试是可以的：）

另外如果直接采用中文命名，需要频繁的在中英文之间切换输入法，太麻烦了

谈谈时间轴的习惯，我见过只有一帧、全export的fla，所有修改都要在库中找元件，对于不熟悉的人，往往要对着每个linkage ID看过去，猜哪个才是要修改的，很不方便。

这个是我做游戏的时间轴例子：

文件夹管理：
时间轴第一层As，第二层Label。以下采用功能文件夹管理，比如，bg，Links。独立层不进文件夹。
库顶层是类型文件夹，比如Bitmap,Graphic,Sound等。以下是功能文件夹。

代码位置：
主场景第一帧负责初始化，构造主类(一般是Preseter)，如果使用FlashVars参数则放在构造里传递，如果主类绑定了MC不需构造则调用 init方法。需要代码的元件全部绑定类，时间轴上只有 stop() 和类方法调用，如 motionComplete()。

代码编写：
类代码从上而下：常量定义Constants、变量声明Variables、构造函数Constructor、属性设置getter/setter、公共方法Methods、私有函数Functions、事件句柄Handlers。
常量全大写，下划线分隔。如 CHECK_DELAY 。
有 getter/setter 的变量下划线开头，构造函数、共有方法参数设置的变量双下划线开头。
构造函数里只调用初始化函数，如 initSystem();initUi();
公共方法一般单个动词，或动词加名词。如 init(), show(), hidePanel()
私有函数命名同上，有时以 Func 结尾。
事件句柄以 on 开头或者以 Handle 结尾。

注释风格：
//##########################################################################
//
// 区块注释(Constants,Variables…)
//
//##########################################################################
// ====== 常量、变量分类 ======
//================================================================
// 方法分类
//================================================================
//——————————————————
// 方法名 方法注释
//——————————————————
构造函数和公有方法使用文档注释

　　我的信念是“方向天马行空，细节循规蹈距”，而且我对代码有“洁癖”的，一定要看起来清爽。先说这么多，以后想到什么再加。

[ 本帖最后由 eidiot 于 2006-12-9 20:23 编辑 ]