日期:2013-09-14  浏览次数:20975 次

转贴自:http://www.5d.cn/bbs/NewsDetail.asp?id=917831

1.省略dim,方便但也是隐患!
申请变量后再使用是标准方法:
dim a
a = "1"
事实上,你不写dim也可以:
a = "1"
系统并不认为出错,它会自动判断a是不是一个已经存在的变量,存在就继续执行,如果不存在就自动帮你申请!看似系统好聪明好智能好体贴,但是隐患出来了!系统知道我的意思吗?系统很可能自作聪明,好心帮倒忙!问题一:如果我前面已经申请了一个变量,比如administrator,后面我要给这个变量赋值,我不幸写错了个字母或少写了个字母,比如administratar = “me",系统终于等来了个“帮”我的机会,并“自告奋勇”的为我申明变量,“体贴周到”难以言表!是的,程序也许能运行,但逻辑上已经乱成一片了,因为系统没有报错(或者报了个其他错来误导你),你根本不能很快定位到问题处,如果程序很大,你花了很多时间找到根源后,你感想如何?你肯定很想骂系统“自做多情”,如果当初系统报一个administratar变量名不存在,我很快就能知道自己拼写错了,而把问题迅速纠正,而不必“沉醉”在系统的“自做多情”当中!省略dim后带来的另一个隐患后面会讲!

2.函数内申明的变量不会干扰外部的变量!
比如:
<%@LANGUAGE="VBSCRIPT" CODEPAGE="936"%>
<%
dim a
a = "1"
function getstr()
dim a
a = "2"
end function

response.Write a & "<br>"
getstr()
response.Write a & "<br>"
%>

结果显示函数内部申明的变量是不会干扰外面的,它的作用域就是函数内部,其实学过其他语言的都应该知道!但要先声明,如果把函数内的dim a去掉的话,那就把那个a认为是外部的a,结果就变了!文件里面申请的变量,他的作用域就是这个文件。

3.让人又爱又恨的include!
include可以使ASP程序更加结构清晰,而且一些常用的函数可以被其他文件所共享!他带来的好处同时你必须注意缺点!
现在回到第一点谈到的省略dim,前面讲的是我赋值却被系统“好心”的变成了申明变量。现在讲的正好相反,我想声明变量,系统却赋值,因为省略dim也能申明变量,对于能省则省喜欢精简的程序员来说,常常挡不住这个诱惑(我有时候也喜欢这么申请,嘿嘿)但是,你能保证你申请的变量名前面的程序里没有?如果前面有这个变量名,那你不是申请成了赋值了?同一个文件中也许很少会犯这个错误,但是别忘了include,他是包含进来文件,如果包含进来的文件中有你申请的变量,那你就完了,就算能运行,逻辑上已经成问题了。如果你不偷懒,用dim申请,报错的时候,你幸运的得知这个变量名已经存在了!很快就能改正!

现在来讨论更复杂的情况,如果你include两个文件进来,在这两个文件中都有同一个变量名,如果两个都用dim申请的话,还好,就只是报错,说变量名已经存在了,很快就能知道问题了。现在你可以理解我为什么讲第二点的作用域了,由于作用域,不同文件同名变量一般情况下不会“打架”。但是,如果被另一个文件同时include进来,问题就麻烦了,所以如果你写的asp文件是准备被包含的,请防止同名的情况发生。再回到原来的讨论,如果两个include文件中申请同名变量都dim还好,但是后包含文件是用省略dim申请,问题就来了,后面的省略dim申请成赋值了,要命的是,这是在两个include文件中,很隐蔽,查找问题更困难!

综上所述,大家可以写一些简单的例子来体会体会其中的问题,最后建议:
1.变量请先用dim申请再使用!尤其多人开发的复杂程序!
2.给变量赋值请注意变量拼写!
3.仔细了解include的文件。

***现在讲讲查错:

事实上,寻找问题比代码编写更重要!我个人经验,问题分三类:
1.报错类,编译系统在编译系统过程中遇到的问题,它会给出错误信息,这是程序员最喜欢的问题,呵呵,不是变态,而是这种问题查起来最简单!

2.逻辑类,比较讨厌的问题,程序编译成功,也能运行,不过显示的结果不是你逻辑中期望的结果。oh, my god!怎么办,没有提示信息,只能凭经验和感觉去分析错误的结果,然后查源代码,顺利的话,几分钟解决,难缠的一天下来也没结果!

3.性能类,很可怕的问题,程序编译成功,也能正常运行,显示也正常!但是,偶尔隔段时间给你来个错误,你根本不知道错误是在什么情况下触发的,或者程序性能不如同类程序的高,运行慢,这些问题,有些一个星期一个月能解决了,有的几乎就是顽疾,治不好。我就曾经被这种问题折腾的死去活来!

所以,要想学好编程,就要尝试自己解决问题,尤其象ASP程序,逻辑方面出问题的情况不大,出的问题基本都是报错类的,有出错信息,出错位置,自己分析分析应该不难解决。我看有些人愿意在论坛上花个三天等别人告诉自己问题,为什么自己不去解决呢?自己查到一个问题,就长了一分经验,这才是程序员的财富!

***一点程序员的心得:
不要以为能写几行代码,做过几个小程序就以为是程序员了,等你去软件公司干上几年你就明白什么叫程序员了,编写代码不算什么,代码查错,优化代码,编写软件文挡(不是一个简单的用户手册,而是项目申请书,项目初步设计说明书,项目详细设计书,数据库设计说明书,项目测试说明书,用户使用手册,用户维护手册等等),事实上你会程序设计,并不代表你能软件开发。事实上我在某些方面还做的不够好,比如编写软件文档,呵呵,想想是件很恐怖的事情,编写软件文档比写程序痛苦多了!自己做了三年delphi程序员,虽然离开公司的时候完成一个不错的软件项目。但还是感觉到自己不足,所以现在我还是不停的补充其他各个方面的技术,这个社会竞争已经很激烈了,你越不努力向上,你越努力向失业靠近!

对于第一个问题,我强烈建议大家使用变量前用Dim定义一下,多写一行代码并不是很困难的事。然后在ASP文件头部用<%Option Explicit%>,这样,如果不小心把变量名写错,就会返回变量没有定义的错误,就可以很容易地查出错误位置,否则,该变量就是一个Null值。

另外,结合Option Explicit说一下第二个问题。有时候我们需要包含多个文件(比如head定义、顶部导航等代码),而Option Explicit在一个ASP Application(注意这里是说application,特指一次应用,而不是page,不表示一个页面)只能用一次。所以,Option Explicit最好不要放在include文件内部,以免被多个页面多次调用引起混乱。

再说一个关于 include 的小问题。一般,如果需要包含的文件就在当前目录内,我们可以直接用
<!--#include file="abc.asp"-->

来包含它。但是,很多时候我们有N个需要包含的文件。于是,为了方便管理,我们将它们统一放在一个INC或include目录内。这样,有时候包含代码就写成了:
<!--#include file="..\inc\abc.asp" -->

这就是我要讨论的问题。请注意,使用..可以访问上层目录,由于而带来一个安全隐患:用户有可能非法引用站点外部文件。基于这个理由,Microsoft 发布的 IIS Lockdown 工具屏蔽了这个引用方法,并且 Microsoft 在 Windows Server 2003 的 IIS6.0 上默认是屏蔽这种方式的。对于这种不在本目录内的包含文件,推荐使用这种安全的引用方法:
<!--#include virtual="/inc/abc.asp"-->

欢迎更多有益的探索和讨论