Some ASP problems, errors, and personal experiences

Some ASP problems, errors, and personal experiences

From: http://www.5d.cn/bbs/NewsDetail.asp stickers? Id = 917831

1. Omit dim, which is convenient but hidden!
It is a standard method to apply for a variable:
Dim
A = "1"
In fact, you can:
A = "1"
The system does not think that an error occurs. It automatically determines whether a is an existing variable and continues execution if it exists. If it does not exist, it automatically applies for it for you! It seems that the system is smart, intelligent, and considerate, but the hidden danger has come out! Does the system know what I mean? The system is likely to be smart and helpful! Question 1: If I have applied for a variable, such as administrator, and I want to assign a value to the variable, I am unfortunately wrong about a letter or less, for example, when administratar = "me", the system finally waited for a chance to "help" me and "volunteered" to declare variables for me. "considerate" is hard to express! Yes, the program may run, but it is already a piece of logic, because the system does not report an error (or another error is reported to mislead you ), you cannot quickly locate the problem. If the program is large, how do you feel after you spend a lot of time finding the root cause? You must be tempted to scold the system for "self-Empathy". If the system reported that the name of the administratar variable did not exist, I would soon be able to know that I had misspelled and corrected the problem quickly, instead, you don't have to "indulge" in the system's "self-made passion! If Dim is omitted, another hidden danger will be discussed later!

2. variables declared in the function do not interfere with external variables!
For example:
<% @ Language = "VBScript" codePage = "936" %>
<%
Dim
A = "1"
Function getstr ()
Dim
A = "2"
End Function

Response. Write a & "<br>"
Getstr ()
Response. Write a & "<br>"
%>

The result shows that the variables stated in the function do not interfere with the outside. The scope of the variable is the internal function. In fact, all the variables that have learned other languages should be known! However, we must first declare that if dim A in the function is removed, the result will change if it considers that a is an external! The applied variable in the file. Its scope is the file.

3. Include the product that people love and hate!
Include Can Make ASP programs more structured and clear, and some common functions can be shared by other files! But you must pay attention to its shortcomings!
Now let's go back to the first point to omit dim. The previous point is that my assignment has been changed to a declarative variable by the system "kindly. I want to declare a variable, but the system assigns a value. If Dim is omitted, the variable can also be declared. For programmers who can save time and enjoy streamlining, I often cannot resist this temptation (I sometimes like this application, ). However, can you ensure that there is no program in front of the variable name you applied? If this variable name exists, didn't you apply for a value assignment? This error may be rarely made in the same file, but don't forget to include it. It contains the file. If the file contains the variable you applied for, you will be done, even if it can run, it is already a logical problem. If you are not lazy, use dim to apply. When an error is reported, you are lucky to know that the variable name already exists! It will be corrected soon!

Now let's discuss more complex cases. If you include two files, both of them have the same variable name. If both of them are applied for Using Dim, it is okay, but an error is reported, the variable name already exists, and the problem will soon be known. Now you can understand why I am talking about the second scope. Because of the scope, variables with the same name in different files will not "fight" in general ". However, if another file is included at the same time, the problem will be troublesome. Therefore, if the ASP file you are writing is intended to be included, please prevent the same name from happening. Back to the original discussion, if the dim variable applied for in the two include files is okay, but the dim application is omitted in the later include files, the problem arises, the omitted dim application is assigned a value. What's worse is that it is hidden in two include files and it is more difficult to find the problem!

To sum up, you can write some simple examples to understand the problems. The final suggestions are as follows:
1. Use dim to apply for a variable! Complex programs especially developed by many people!
2. assign values to variables. Note the spelling of variables!
3. Carefully understand the include files.

* ** Now let's talk about troubleshooting:

In fact, searching for problems is more important than coding! In my personal experience, there are three types of problems:
1. error class: The problem encountered by the compilation system during the compilation process. It will give an error message, which is the programmer's favorite problem. It is not abnormal, but the easiest way to look up this problem!

2. Logic class, annoying problem. The program can run successfully after compilation, but the displayed result is not the expected result in your logic. Oh, my God! What should I do? I have no prompt information. I have to analyze the error results based on experience and feeling, and then check the source code. If the code goes well, it will take a few minutes to solve the problem!

3. Performance class, a terrible problem. The program can run properly after compilation, and the display is normal! However, you may encounter an error in the interval. You do not know under what circumstances the error is triggered, or the program performance is not as high as or slow as that of similar programs, some of them can be solved every Monday, and some are almost stubborn. I was once killed by this problem!

Therefore, if you want to learn programming well, you must try to solve the problem by yourself, especially in ASP. The logical problems are not very serious. The problems are basically error-type, with error information and error location, self-analysis should not be difficult to solve. I think some people are willing to spend three days on the Forum to wait for others to tell themselves about the problem. Why don't they solve it? Finding a problem on your own leads to a long experience. This is the fortune of programmers!

*** A programmer's experience:
Do not think that you can write a few lines of code. If you have done a few small programs, you will think that you are a programmer. When you have been in a software company for a few years, you will understand what a programmer is. Writing code is nothing, and the code is found wrong, optimize the code and write the software document (not a simple user manual, but a project application, Preliminary Design Manual, detailed design book, database design manual, Project Test Manual, user User Manual, user maintenance manual, etc.), in fact, you will program design, does not mean that you can develop software. In fact, I have not done well in some aspects, such as writing software documents. It is a terrible thing to think about. It is much more painful to write software documents than to write programs! I worked as a Delphi programmer for three years, although I completed a good software project when I left the company. However, I still feel that I am not enough. Now I am constantly adding other technologies. The competition in this society is already fierce. The harder you are, the closer you are to unemployment!

For the first question, I strongly recommend that you use dim to define variables. It is not very difficult to write more code lines. Then, use <% option explicit %> in the ASP file header. In this way, if you accidentally write an error in the variable name, an error not defined in the variable will be returned, the error location can be easily identified. Otherwise, the variable is a null value.

In addition, let's talk about the second problem with option explicit. Sometimes we need to contain multiple files (such as head definition, top navigation, and other code), while option explicit is in an ASP application (note that this is an application, especially an application, rather than a page, does not represent a page) can only be used once. Therefore, option explicit should not be placed inside the include file to avoid confusion caused by multiple calls to multiple pages.

Let's talk about the small issue of include. Generally, if you want to include files in the current directory, you can directly use

<! -- # Include file = "ABC. asp" -->

To include it. However, we often have n files to be included. Therefore, to facilitate management, we put them in a unified INC or include directory. In this way, sometimes the code is written as follows:

<! -- # Include file = "../INC/ABC. asp" -->

This is the question I want to discuss. Please note that you can access the upper-level directory by using .., which brings about a security risk: users may illegally reference the site's external files. For this reason, Microsoft released the IIS Lockdown tool to block this reference method, and Microsoft blocked this method by default on Windows Server 2003 iis6.0. We recommend that you use this safe reference method for files that are not included in this directory:

<! -- # Include virtual = "/INC/ABC. asp" -->

More useful explorations and discussions are welcomed.