18.3 Good programming style
Although you will be doing advanced object-oriented software development, some good programming styles that have been summarized in process-oriented ages will not be outdated at any time (at least for the foreseeable future). This section will teach you these universal rules that are not mandatory, but observing them will undoubtedly make your life easier.
A good style means programming in a way that is easy to maintain. Your code should be easy enough for anyone to understand it. This is not to say that others need to look at the code you have written (of course this may happen), but to say that when you need to debug or modify errors, you can quickly understand what exactly you have developed. People are always prone to losing control and trying to build something and neglecting the useful finishing work. Sloppy behavior will cause endless troubles, so you should always try to follow a good programming style.
Of course, "good" cannot be easily obtained, and "good" usually means a lot of work. Here, good means: good names, reduce duplication, always comments, and separate code and data.
18.3.1 Good name
What is a good name? The concept of a good name in the programming world is very different from the concept of a good name in our daily lives. In our daily lives, a good name often means it is worth pondering: either expressing the good wishes of parents, or a wonderful explanation in the dictionary. But it is very bad to use a good name in daily life in programs, and such a name cannot provide other information than the name.
In the programming world, the criterion for judging a good name is whether it can provide more information with minimal characters. In Flash, there are many things we can and need to name. Every instance of a button or movie clip, every text instance may need to be named; every variable, every function, and every class must be named.
In Flash, when you name a thing, you should try to let the name reflect all the important information of the thing. For example: fishCounterMC is a good example of a movie clip that counts the number of fish in a fish tank. Many days later, when you see this name again, you can get a lot of important information in an instant. First, with a look, we can know that this name refers to a movie clip (MC means MovieClip), so this name is the name of a movie clip instance, and secondly, we can see that this is a movie clip used to count (according to Counter), and finally, we can infer that this counter should be used to count the fish (according to fish).
When naming a variable, it will be beneficial to be able to reflect the data type of the variable in the variable name. childAge_Num is a name for a variable used to save the age of a child. From the suffix of Num, we can realize that this variable should save the numeric data type.
Sometimes, in order to give things a more meaningful name and convey more information, you will find that the name is getting longer and longer. This is not a good thing. Too long names will also cause difficulties in reading. Because too many long names are piled up together, you cannot see the logic of the program clearly, so you should maintain a proper attitude towards anything. Many times, you need to compromise between passing more information and preventing too long names.
18.3.2 Reduce duplication
To make things simple, every programming job should only happen once in your movie. If your same piece of code appears in two places, your update and modify bugs will also double. You will learn some ways to do this, such as saving scripts in libraries, saving them in functions, or introducing movies from outside. Any time, whenever you plan to copy and paste the code, a small voice should sound in your mind—"Stop!". There will always be a more concise way waiting for you.
Reducing duplication also means refining the code and trying to do the same with less code. Think about it, when you go back and check your program for debugging bugs, every line of code you check must be translated in your mind, and fewer lines you will definitely feel better when you read. Usually, at any time you can do something with fewer steps or less code. Comparing the two code segments in code 1 and code 2, they achieve the same effect, but the code in code 2 is much more refined.
Code 1:
on (release){
setProperty ("highlight", _x, getProperty ("highlight", _x)+10);
tellTarget ("highlight"){
gotoAndStop(getProperty("",_currentframe)+1);
}
}
Code 2:
on (release){
highlight._x+=10;
();
}
Those scripts in Code One achieve the same effect as those in Code Two, but add unnecessary complexity. This has no more meaning than arousing the admiration of players who are much lower than your level.
Admittedly, there is no method that is legally best, but reducing duplication and refining code is undoubtedly beneficial. Of course, you don’t need to implement the refinement code too thoroughly. The requirement of streamlining code should not be more important than legibility. It's easy to completely lose your self-control and end up in a bunch of code that you can't even read on your own. I will never pick on a finished snippet that works—because, seriously, that's the priority. Secondly, your code is usually maintained by you, so it is most important to write code that you can read and understand. Do everything possible to use code that you can understand. If this sometimes means that your code is a little bit verbose, it can only be done with it. As time goes by, slowly you will see your code gradually shortening.
Sometimes, when I look at programs that were only written a few months ago, I also question the approach I was taking at the time—but it was simply because I was always improving. If you plan to wait until your technology becomes perfect, you will wait too long. So just invest in it like this, time will prove that you can make progress.
18.3.3 Always comment
In Flash, comments are text that start with //. Comments are ignored lines of code in Flash. Comments are by no means a feature of Flash. If you open any computer book involving programming, you will find that there are discussions that focus on the importance of explanation. Indeed, comments are very important and no matter how you emphasize them, you will not be too much. Comments can allow you to know the role of each piece of code for months or even years, and continue to carry out subsequent development and maintenance of the program; they can let others understand your code when necessary, and he (she) will experience your kindness while watching, and be grateful, and swear to be a good boy (or good girl) like you.
I think I'm a bad boy because I often can't make adequate comments on my code until I get it running. But no matter what, it was important for me not to delay this step because after a few days of writing it, I would forget everything about this code. Without comments, understanding the code will become much more difficult. So, take some time to comment your code, even if you have finished your code and your enthusiasm is declining. Compare the code without comments in Code Three and the code with the same but commented code in Code Four. Although you may not understand the details of these codes at the moment, if there is a problem here, you will be able to easily identify the part that contains the problem.
Code Three:
OnClipEvent (keyUp) {
if (()==13 | ()==0){
return;
}
if (()==8){
if ((-2)==" "){
_root.wordThisTime--;
}
cur=(0, -2)+mbchr(8);
if (_root.wrongPlace[_root.place-1]=="x"){
_root.();
_root.wrongs--;
}
_root.place>0 && _root.place--;
return;
}
}
Code 4:
OnClipEvent (keyUp) {
//Ignore these characters
if (()==13 | ()==0){
return;
}
//If they click the backspace
if (()==8){
//Delete a space?
if ((-2)==" "){
_root.wordThisTime--;
}
//Delete the last character
cur=(0, -2)+mbchr(8);
//Did they modify an error?
if (_root.wrongPlace[_root.place-1]=="x"){
_root.();
_root.wrongs--;
}
//Retreat one square
_root.place>0 && _root.place--;
//leave
return;
}
}
Code Three is difficult to understand before being commented. Code Four explains a little comment that makes things clear, even if you don't understand the potential meaning of these codes.
18.3.4 Separating code and data
All programmers should strive to keep the code (simply programming scripts) and data (or the content of a specific project, such as text and graphics) separate. By keeping the code and data apart, you can easily port your programming results to other projects. Similarly, when you want to make a significant change to your content—for example, rework the entire project in a different language—you just need to replace the data without touching (or destroying) that code. This is a great idea but sometimes difficult to achieve.
Assume that your Flash site has some graphic buttons, these graphic buttons will show a floating tooltip when the user places his mouse pointer over it. If you keep the code (the script that makes the tooltip appear) and the data (the text that will actually appear in the tooltip) separate. You can easily port this feature to another language, and all you do is replace the tooltip with text from another language. Ideally, you save all the text of all tooltips in the same place, which will make porting easier. The main idea is that you should try to make major changes to any one of the code or data that will not affect the other.
You can think of code data separation as a modular form. There are some other modular forms—including Flash's loadMovie(), which allows you to play standalone .swf files inside a larger movie. In addition to the mentioned code data separation, modularity has many other advantages. First, by modularizing your Flash movie, users don't need to wait for the entire movie to be downloaded. They can choose to download those parts that they are interested in. In addition, modularity also allows a project to be cleanly stripped into several separate parts, so that these parts can be developed simultaneously. Think about a situation where if your entire movie consists of only one basic file, there can only be one person working at the same time. Therefore, it can be seen that code data separation and other modular forms have many advantages, and you should try to maintain a modular idea to consider the problem.