了解在Flash中的编程工作-3
作者：陈冰 时间：2004-7-19 文档类型：原创 来自：蓝色理想
浏览统计 year:3223 | Quarter:3223 | Month:3223 | Week:3223 | today:460
第 1 页 像软件设计师那样思考问题
第 2 页 面向对象的软件开发中的重要概念
第 3 页 好的编程风格
第 4 页 ActionScript术语
18.3 好的编程风格
尽管你将进行先进的面向对象的软件开发了，但一些在面向过程的年代就已经总结出的好的编程风格在任何时候（至少在可预见的未来）都不会过时。本节将教给你这些放之四海皆准的规则，这些规则不是强制性的，但遵守它们毫无疑问会使得你的生活变得容易。
好的风格意味着以一种易维护的方式进行编程。你的代码应该容易到足以使任何人都能够理解它。这倒不是说其他人需要查看你已经编写的这些代码（当然这种情况可能会发生），而是说当你需要进行调试或修改错误时，你能够快速的理解你已经开发出的到底是些什么东西。人们总是很容易失去自制力的试图去建立某些东西而忽视了有益的整理工作。草率的行事将引起无限的烦恼，因此你应该总是尽力遵循好的编程风格。
当然，“好”不能轻易得到，“好”通常就意味着大量的工作。在这里，好就意味着：好的名字、减少重复、总是注释，以及分离代码和数据。
18.3.1 好的名字
什么是好的名字？在编程世界中的好名字的概念和我们日常生活中好名字的概念有很大的不同。在我们的日常生活中，一个好名字往往意味着非常值得推敲：或者是表达父母的良好愿望，或者是字典中绝妙的解释。但一个日常生活中的好名字用在程序中却是很糟糕的，一个这样的名字无法提供除名字之外的其他信息。
在编程世界中，判断一个好名字的标准是是否能够以最少的字符提供更多的信息。在Flash中，我们可以且需要命名的东西是非常多的，每一个按钮或电影剪辑的实例，每一个文本实例，都有可能需要命名；每一个变量，每一个函数，每一个类，都必须命名。
在Flash中，当你命名一个事物的时候，你应该尽量让这个名字反映出这个事物的所有重要的信息。例如：fishCounterMC作为一个统计鱼缸中鱼的数量的电影剪辑的实例名就很不错。很多天后，当你再次见到这个名字时，你能够在瞬间获得许多重要的信息。首先，一打眼，我们就能知道这个名字指代的是一个电影剪辑（MC表示MovieClip），因此，这个名字是一个电影剪辑实例的名字，其次，我们能够看出这是一个用来计数的电影剪辑（根据Counter），最后，我们可以推断这个计数器应该是来统计鱼的（根据fish）。
当为变量命名时，能够在变量名中体现出这个变量的数据类型将是很有益的。childAge_Num作为一个用来保存孩子年龄的变量的名字会是不错的，从Num这个后缀我们可以意识到这个变量应该保存的是数字数据类型。
有的时候，为了给事物赋予一个更有意义的名字，传递更多的信息，你会发现名字正在变得越来越长，这不是好事情，太长的名字同样会造成阅读的困难。因为太多长名字堆积在一起会使得你看不清程序的逻辑，因此，对待任何事情，你都应该保持适可而止的态度，很多时候，你需要在传递更多的信息和防止太长的名字之间进行妥协。
18.3.2 减少重复
要使事情变得简单，每一个编程工作应该在你的电影中只出现一次。如果你的同一段代码出现在两处，那么你的更新和修改Bug的工作也将加倍。你将学到一些方法来实现这点，譬如说将脚本保存在库中、保存在函数中或从外部引入电影。任何时候，每当你打算拷贝和粘贴代码时，一个不大的声音应该在你的头脑中响起—“住手！”。总会有一个更简练的方法在等待着你。
减少重复还意味着精炼代码，尽量用更少的代码来完成同样的工作。细想一下，当你为调试Bug而回头检查你的程序时，你所检查的每一行代码都必须在你的头脑中进行翻译，更少的行你必定读起来会感觉更好。通常，任何时候你都可以以较少的步骤或更少的代码来做某些事情。比较在代码1和代码2中的两个代码段，它们实现的是同样的效果，但代码2中的代码要精炼的多。
代码一：
on (release){
setProperty ("highlight", _x, getProperty ("highlight", _x)+10);
tellTarget ("highlight"){
gotoAndStop(getProperty("",_currentframe)+1);
}
}
代码二：
on (release){
highlight._x+=10;
highlight.nextFrame();
}
那些在代码一中的脚本实现的是与代码二中的脚本同样的效果，只是添了没有必要的复杂性而已。这除了能引起比你水平低很多的选手的崇拜外，没有更多的意义。
诚然，没有什么方法是法定的最好的方法，但减少重复和精炼代码毫无疑问是有益的。当然，你也没有必要把减少重复，精炼代码这点贯彻得太彻头彻底。精简代码的要求不应重于易读性。彻底失去自制力并最终终结于一堆连你自己都无法阅读的代码是很容易的事情。我永远都不会在一个能够工作的已完成的代码段中挑刺儿—因为，说真的，这才是最优先要考虑的。其次，你的代码通常都是由你来维护的，因此，编写出你能够阅读和理解的代码是最重要的。尽一切可能使用你能够理解的代码。如果这有时意味着你的代码罗嗦一点的话，那也只能由它去了。随着时间的推移，慢慢地你将看到你的代码正在逐渐缩短。
有时，当我审视那些仅仅是几个月前才编好的程序时，我也会质疑我当时所采用的方法—但这仅仅是因为我总是在进步。如果你打算等到你的技术变得完美时再做的话，你将等待太长的时间。因此就这样投入进去吧，时间自会证明你能够进步。
18.3.3 总是注释
在Flash中，注释是以//开始的文本。注释在Flash中是被忽略的代码行。注释绝不是Flash的特点，翻开任何一本涉及编程的计算机书，你都会发现里面有有关注释的重要性的论述。的确，注释是非常重要的，怎么强调都不会为过。注释能使你在数月甚至数年后仍能知道每段代码的作用，仍能够继续对程序进行后续开发和维护；能够在必要时候，让别人看懂你的代码，他（她）会一边看一边体味你的仁慈，并心怀感激，发誓也要做像你这样的好男孩（或好女孩）。
我认为我是一个坏男孩，因为我经常做不到对我的代码进行充分的注释，直到我让它运行起来为止。但不管怎么说，没有将这一步继续拖延下去对我来说很重要，因为在我写出它的几天之后，我会将有关这段代码的一切忘的一干二净。没有注释，代码的理解将变得困难的多。因此，花上一些时间去注释你的代码吧，即使你已经完成了你的代码且热情也日渐下降。比较一下代码三中没有注释的代码和代码四中同样的一些但做了注释的代码。尽管你目前可能不明白这些代码的细节，但如果这里存在问题的话，你将能够轻松的识别出包含问题的部分。
代码三：
OnClipEvent (keyUp) {
if (Key.getAscii()==13 | Key.getAscii()==0){
return;
}
if (Key.getAscii()==8){
if (cur.charAt(cur.length-2)==" "){
_root.wordThisTime--;
}
cur=cur.slice(0, cur.length-2)+mbchr(8);
if (_root.wrongPlace[_root.place-1]=="x"){
_root.wrongPlace.pop();
_root.wrongs--;
}
_root.place>0 && _root.place--;
return;
}
}
代码四：
OnClipEvent (keyUp) {
//忽略这些字符
if (Key.getAscii()==13 | Key.getAscii()==0){
return;
}
//假如他们点击退格键
if (Key.getAscii()==8){
//删除一个空格？
if (cur.charAt(cur.length-2)==" "){
_root.wordThisTime--;
}
//删除最后的字符
cur=cur.slice(0, cur.length-2)+mbchr(8);
//他们修改了一个错误吗？
if (_root.wrongPlace[_root.place-1]=="x"){
_root.wrongPlace.pop();
_root.wrongs--;
}
//后退一格
_root.place>0 && _root.place--;
//离开
return;
}
}
代码三在被注释前，其中的代码理解起来很困难。代码四说明了不多的一点注释就使得事情变得明朗，即使你还不明白这些代码的潜在含义。
18.3.4 分离代码和数据
所有的程序设计师都应该力争使代码（简单的说就是编程脚本）和数据（或说特定工程的内容，例如：文本和图形）保持分离。通过保持代码和数据的分离，你能够使你的编程成果轻松的移植到其他的工程。同样的，当你想要对内容作重大的改变时—比如说，以不同的语言重做整个工程—你只需要替换数据而不必去碰（或破坏）那些代码。这是伟大的思想但有时难以实现。
假定你的Flash站点中有一些图形按钮，当用户将他的鼠标指针放置到按钮之上时这些图形按钮将显示出一个浮动的工具提示。如果你保持代码（使工具提示出现的脚本）和数据（实际将出现在工具提示中的文本）分离。你能够轻松的将这个功能移植到另一种语言，而你所做的只是用另一种语言的文本来替换工具提示。理想的情况是，你将所有工具提示的所有文本保存在同一个位置，这将使得移植工作变得更加的轻松。这一思想的主旨是你应该尽量做到对代码或数据中任何一个所做的重大改变都不会对另一个产生影响。
你可以将代码数据分离视为一种模块化形式。还有一些其他的模块化形式—包括Flash的loadMovie()，它使你能够在一个更大的电影的内部播放独立的.swf文件。除了所提及的代码数据分离之外，模块化还有许多其他的优点。首先，通过模块化你的Flash电影，用户们不需要等待整个电影的下载。他们可以有选择的下载那些那他们感兴趣的部分。此外，模块化也使得一个工程可以被干净的剥离成几个独立的部分，从而使得这些部分可以同时进行开发。思考这样一种情况，如果你的整个电影仅由一个基本文件构成，则同时只能有一个人可以工作。因此，可以看出，代码数据分离及其它的一些模块化形式有着许多的优势，你应该尽量保持以模块化的思想来考虑问题。
作者：陈冰 时间：2004-7-19 文档类型：原创 来自：蓝色理想
浏览统计 year:3223 | Quarter:3223 | Month:3223 | Week:3223 | today:460
第 1 页 像软件设计师那样思考问题
第 2 页 面向对象的软件开发中的重要概念
第 3 页 好的编程风格
第 4 页 ActionScript术语
18.3 好的编程风格
尽管你将进行先进的面向对象的软件开发了，但一些在面向过程的年代就已经总结出的好的编程风格在任何时候（至少在可预见的未来）都不会过时。本节将教给你这些放之四海皆准的规则，这些规则不是强制性的，但遵守它们毫无疑问会使得你的生活变得容易。
好的风格意味着以一种易维护的方式进行编程。你的代码应该容易到足以使任何人都能够理解它。这倒不是说其他人需要查看你已经编写的这些代码（当然这种情况可能会发生），而是说当你需要进行调试或修改错误时，你能够快速的理解你已经开发出的到底是些什么东西。人们总是很容易失去自制力的试图去建立某些东西而忽视了有益的整理工作。草率的行事将引起无限的烦恼，因此你应该总是尽力遵循好的编程风格。
当然，“好”不能轻易得到，“好”通常就意味着大量的工作。在这里，好就意味着：好的名字、减少重复、总是注释，以及分离代码和数据。
18.3.1 好的名字
什么是好的名字？在编程世界中的好名字的概念和我们日常生活中好名字的概念有很大的不同。在我们的日常生活中，一个好名字往往意味着非常值得推敲：或者是表达父母的良好愿望，或者是字典中绝妙的解释。但一个日常生活中的好名字用在程序中却是很糟糕的，一个这样的名字无法提供除名字之外的其他信息。
在编程世界中，判断一个好名字的标准是是否能够以最少的字符提供更多的信息。在Flash中，我们可以且需要命名的东西是非常多的，每一个按钮或电影剪辑的实例，每一个文本实例，都有可能需要命名；每一个变量，每一个函数，每一个类，都必须命名。
在Flash中，当你命名一个事物的时候，你应该尽量让这个名字反映出这个事物的所有重要的信息。例如：fishCounterMC作为一个统计鱼缸中鱼的数量的电影剪辑的实例名就很不错。很多天后，当你再次见到这个名字时，你能够在瞬间获得许多重要的信息。首先，一打眼，我们就能知道这个名字指代的是一个电影剪辑（MC表示MovieClip），因此，这个名字是一个电影剪辑实例的名字，其次，我们能够看出这是一个用来计数的电影剪辑（根据Counter），最后，我们可以推断这个计数器应该是来统计鱼的（根据fish）。
当为变量命名时，能够在变量名中体现出这个变量的数据类型将是很有益的。childAge_Num作为一个用来保存孩子年龄的变量的名字会是不错的，从Num这个后缀我们可以意识到这个变量应该保存的是数字数据类型。
有的时候，为了给事物赋予一个更有意义的名字，传递更多的信息，你会发现名字正在变得越来越长，这不是好事情，太长的名字同样会造成阅读的困难。因为太多长名字堆积在一起会使得你看不清程序的逻辑，因此，对待任何事情，你都应该保持适可而止的态度，很多时候，你需要在传递更多的信息和防止太长的名字之间进行妥协。
18.3.2 减少重复
要使事情变得简单，每一个编程工作应该在你的电影中只出现一次。如果你的同一段代码出现在两处，那么你的更新和修改Bug的工作也将加倍。你将学到一些方法来实现这点，譬如说将脚本保存在库中、保存在函数中或从外部引入电影。任何时候，每当你打算拷贝和粘贴代码时，一个不大的声音应该在你的头脑中响起—“住手！”。总会有一个更简练的方法在等待着你。
减少重复还意味着精炼代码，尽量用更少的代码来完成同样的工作。细想一下，当你为调试Bug而回头检查你的程序时，你所检查的每一行代码都必须在你的头脑中进行翻译，更少的行你必定读起来会感觉更好。通常，任何时候你都可以以较少的步骤或更少的代码来做某些事情。比较在代码1和代码2中的两个代码段，它们实现的是同样的效果，但代码2中的代码要精炼的多。
代码一：
on (release){
setProperty ("highlight", _x, getProperty ("highlight", _x)+10);
tellTarget ("highlight"){
gotoAndStop(getProperty("",_currentframe)+1);
}
}
代码二：
on (release){
highlight._x+=10;
highlight.nextFrame();
}
那些在代码一中的脚本实现的是与代码二中的脚本同样的效果，只是添了没有必要的复杂性而已。这除了能引起比你水平低很多的选手的崇拜外，没有更多的意义。
诚然，没有什么方法是法定的最好的方法，但减少重复和精炼代码毫无疑问是有益的。当然，你也没有必要把减少重复，精炼代码这点贯彻得太彻头彻底。精简代码的要求不应重于易读性。彻底失去自制力并最终终结于一堆连你自己都无法阅读的代码是很容易的事情。我永远都不会在一个能够工作的已完成的代码段中挑刺儿—因为，说真的，这才是最优先要考虑的。其次，你的代码通常都是由你来维护的，因此，编写出你能够阅读和理解的代码是最重要的。尽一切可能使用你能够理解的代码。如果这有时意味着你的代码罗嗦一点的话，那也只能由它去了。随着时间的推移，慢慢地你将看到你的代码正在逐渐缩短。
有时，当我审视那些仅仅是几个月前才编好的程序时，我也会质疑我当时所采用的方法—但这仅仅是因为我总是在进步。如果你打算等到你的技术变得完美时再做的话，你将等待太长的时间。因此就这样投入进去吧，时间自会证明你能够进步。
18.3.3 总是注释
在Flash中，注释是以//开始的文本。注释在Flash中是被忽略的代码行。注释绝不是Flash的特点，翻开任何一本涉及编程的计算机书，你都会发现里面有有关注释的重要性的论述。的确，注释是非常重要的，怎么强调都不会为过。注释能使你在数月甚至数年后仍能知道每段代码的作用，仍能够继续对程序进行后续开发和维护；能够在必要时候，让别人看懂你的代码，他（她）会一边看一边体味你的仁慈，并心怀感激，发誓也要做像你这样的好男孩（或好女孩）。
我认为我是一个坏男孩，因为我经常做不到对我的代码进行充分的注释，直到我让它运行起来为止。但不管怎么说，没有将这一步继续拖延下去对我来说很重要，因为在我写出它的几天之后，我会将有关这段代码的一切忘的一干二净。没有注释，代码的理解将变得困难的多。因此，花上一些时间去注释你的代码吧，即使你已经完成了你的代码且热情也日渐下降。比较一下代码三中没有注释的代码和代码四中同样的一些但做了注释的代码。尽管你目前可能不明白这些代码的细节，但如果这里存在问题的话，你将能够轻松的识别出包含问题的部分。
代码三：
OnClipEvent (keyUp) {
if (Key.getAscii()==13 | Key.getAscii()==0){
return;
}
if (Key.getAscii()==8){
if (cur.charAt(cur.length-2)==" "){
_root.wordThisTime--;
}
cur=cur.slice(0, cur.length-2)+mbchr(8);
if (_root.wrongPlace[_root.place-1]=="x"){
_root.wrongPlace.pop();
_root.wrongs--;
}
_root.place>0 && _root.place--;
return;
}
}
代码四：
OnClipEvent (keyUp) {
//忽略这些字符
if (Key.getAscii()==13 | Key.getAscii()==0){
return;
}
//假如他们点击退格键
if (Key.getAscii()==8){
//删除一个空格？
if (cur.charAt(cur.length-2)==" "){
_root.wordThisTime--;
}
//删除最后的字符
cur=cur.slice(0, cur.length-2)+mbchr(8);
//他们修改了一个错误吗？
if (_root.wrongPlace[_root.place-1]=="x"){
_root.wrongPlace.pop();
_root.wrongs--;
}
//后退一格
_root.place>0 && _root.place--;
//离开
return;
}
}
代码三在被注释前，其中的代码理解起来很困难。代码四说明了不多的一点注释就使得事情变得明朗，即使你还不明白这些代码的潜在含义。
18.3.4 分离代码和数据
所有的程序设计师都应该力争使代码（简单的说就是编程脚本）和数据（或说特定工程的内容，例如：文本和图形）保持分离。通过保持代码和数据的分离，你能够使你的编程成果轻松的移植到其他的工程。同样的，当你想要对内容作重大的改变时—比如说，以不同的语言重做整个工程—你只需要替换数据而不必去碰（或破坏）那些代码。这是伟大的思想但有时难以实现。
假定你的Flash站点中有一些图形按钮，当用户将他的鼠标指针放置到按钮之上时这些图形按钮将显示出一个浮动的工具提示。如果你保持代码（使工具提示出现的脚本）和数据（实际将出现在工具提示中的文本）分离。你能够轻松的将这个功能移植到另一种语言，而你所做的只是用另一种语言的文本来替换工具提示。理想的情况是，你将所有工具提示的所有文本保存在同一个位置，这将使得移植工作变得更加的轻松。这一思想的主旨是你应该尽量做到对代码或数据中任何一个所做的重大改变都不会对另一个产生影响。
你可以将代码数据分离视为一种模块化形式。还有一些其他的模块化形式—包括Flash的loadMovie()，它使你能够在一个更大的电影的内部播放独立的.swf文件。除了所提及的代码数据分离之外，模块化还有许多其他的优点。首先，通过模块化你的Flash电影，用户们不需要等待整个电影的下载。他们可以有选择的下载那些那他们感兴趣的部分。此外，模块化也使得一个工程可以被干净的剥离成几个独立的部分，从而使得这些部分可以同时进行开发。思考这样一种情况，如果你的整个电影仅由一个基本文件构成，则同时只能有一个人可以工作。因此，可以看出，代码数据分离及其它的一些模块化形式有着许多的优势，你应该尽量保持以模块化的思想来考虑问题。
回复Comments
作者:
{commentrecontent}