1. dim を省略すると便利ですが、隠れた危険性もあります。
変数を適用して使用するのが標準的なアプローチです。
薄暗い
a = "1"
実際、 dim を書かなくてもそれを行うことができます。
a = "1"
システムは、 a が既存の変数であるかどうかを自動的に判断し、存在しない場合は自動的に適用されます。このシステムはとても賢く、賢く、思いやりがあるように見えますが、隠れた危険があります。システムは私の言いたいことを理解していますか？システムが賢すぎて役に立たない可能性が非常に高いです。 質問 1: 管理者など、以前に変数を申請したことがあり、後でこの変数に値を割り当てたい場合、残念ながら間違った文字を書いたり、文字を書き忘れたりしてしまいます。管理者 = "me" などの文字を使用すると、システムは最終的に私を「支援」する機会を待って、私に代わって変数を宣言することを「自発的に」行ってくれました。それがどれほど「配慮」されていたかを表現するのは難しいです。はい、プログラムは実行できるかもしれませんが、システムがエラーを報告しない (または誤解を招く別のエラーを報告する) ため、プログラムが大きい場合は問題をすぐに特定できません。多くの時間を費やして根本原因を見つけた後はどう思いますか?管理者変数名が存在しないとシステムが報告した場合、私はスペルが間違っていることにすぐに気づき、「甘やかす」ことなく問題をすぐに修正できます。システムの「自動で『熱くなれ』！」 dim の省略によって引き起こされるもう 1 つの隠れた危険については、後ほど説明します。
2. 関数内で宣言された変数は外部変数に干渉しません。
例えば：
< %@LANGUAGE="VBSCRIPT " CODEPAGE="936"%>
<%
薄暗い
a = "1"
関数 getstr()
薄暗い
a = "2"
関数の
応答を終了します。& "<br>" を
書き込みます。
getstr()
応答。&「<br>」を書いてください。
%>
結果は、関数内で宣言された変数が外部の世界に干渉しないことを示しています。実際、他の言語を学習したことのある人なら誰でもこれを知っているはずです。ただし、関数内の dim a が削除されると、a は外部の a とみなされ、結果が変わるということを最初に述べなければなりません。ファイルに適用される変数のスコープはこのファイルです。
3. 好き嫌いが分かれる内容！
include を使用すると、ASP プログラムの構造がより明確になり、よく使用される関数の一部を他のファイルで共有できます。メリットがある一方で、デメリットにも注意する必要があります。
ここで、最初の点で述べた dim の省略に戻ります。先ほど述べたのは、私の代入が「親切に」システムによって宣言された変数に変換されたということです。私が今話していることはまったく逆で、変数を宣言したいのですが、dim を省略しても変数を宣言できるため、システムは変数に値を代入します。多くの場合、この誘惑に抵抗することはできません (私も時々このように適用するのが好きです。笑) しかし、適用した変数名がその前のプログラムに存在しないことを保証できますか?この変数名が先頭にあれば代入を申請したということではないでしょうか？この間違いが同じファイル内で行われることはほとんどありませんが、インクルードされたファイルに適用した変数が含まれている場合は、実行できたとしても、それはすでに問題になっています。論理的な問題。怠け者ではなく、dim を使用して適用する場合、エラーが報告されたときに、この変数名がすでに存在していることがわかるのは幸運です。すぐに修正されます！
次に、より複雑な状況について説明します。2 つのファイルをインクルードする場合、両方のファイルに同じ変数名が存在します。dim を使用して両方に適用すると、変数名がすでに存在するというエラーが報告されるだけです。 、問題はすぐにわかります。これで、スコープの 2 番目の点について説明した理由が理解できると思います。スコープにより、異なるファイル内の同じ名前の変数は通常「競合」しません。ただし、同時に別のファイルにインクルードされると厄介なので、自分が書いたaspファイルがインクルードするつもりの場合は、同名事態が起こらないようにしてください。元の話に戻りますが、2 つのインクルード ファイルに適用されたときに、同じ名前のインクルード変数が両方とも dim であれば問題ありませんが、後からインクルードされたファイルが dim を省略して適用された場合に問題が発生します。恐ろしいことに、これは 2 つのインクルード ファイルに分かれており、非常に隠されているため、問題を見つけるのがさらに難しくなります。
要約すると、問題を理解するためにいくつかの簡単な例を書くことができます。最後に、次のように提案します。
1. 変数を使用する前に dim を使用して変数を適用してください。特に複雑なプログラムは複数人で開発されます。
2. 変数に値を割り当てるときは、変数のスペルに注意してください。
3. インクルード ファイルをよく理解します。
***次に、エラー チェックについて話しましょう。
実際、問題を見つけることはコードを書くことよりも重要です。私の個人的な経験から言えば、問題は次の 3 つのカテゴリに分類されます。
1. エラー報告タイプ。システムのコンパイル処理中にコンパイル システムで発生した問題で、エラー メッセージが表示されます。ははは、これは異常ではありませんが、この種の問題です。簡単にチェックできます！
2. ロジック タイプ。プログラムは正常にコンパイルされ、実行できますが、表示される結果はロジックで期待される結果ではありません。何てことだ！どうすればよいですか? プロンプトメッセージはありません。経験と感覚に基づいてエラー結果を分析し、問題がなければ数分で解決します。困難な一日の後の結果！
3. パフォーマンス カテゴリ。プログラムは正常にコンパイルされ、正常に実行され、正常に表示されました。ただし、時々エラーが発生し、どのような状況でエラーが発生するかわからない場合や、プログラムのパフォーマンスが同様のプログラムほど高くなく、実行が遅い場合があります。これらの問題の一部は、内部で解決できます。 1週間や1ヶ月で治るものもありますが、そのほとんどは治らない頑固な病気です。私はこの種の問題で死ぬほど苦しめられました！
したがって、プログラミングをしっかり学びたい場合は、特に ASP プログラムのように、発生する問題はエラー メッセージとエラーの場所にあることがほとんどではありません。自分で分析する必要はありません。他の人が自分の問題を解決するのを待つために、フォーラムで 3 日も費やす人もいると思います。自分で問題を見つければ経験が得られます。これがプログラマーの財産です。
***プログラマーのちょっとした経験:
数行のコードを書けたり、いくつかの小さなプログラムを実行したりしたからといって、自分がプログラマーであるとは考えないでください。ソフトウェア会社で数年間働いたら、プログラマーであることが何を意味するのか理解できるでしょう。コードを書くということは、コードのエラー チェックと最適化にほかなりません。コードを書き、ソフトウェア ドキュメント (単なるユーザー マニュアルではなく、プロジェクト アプリケーション、プロジェクトの予備設計手順、プロジェクトの詳細設計手順、データベース設計手順、プロジェクト テスト手順、ユーザー マニュアル、ユーザー マニュアル) を作成します。メンテナンスマニュアルなど）、事実 プログラミングができるからといって、ソフトウェアを開発できるわけではありません。実際、私はソフトウェアのドキュメントを書くなど、いくつかの点で十分ではありません。笑、ソフトウェアのドキュメントを書くことは、プログラムを書くことよりもはるかに苦痛です。私は Delphi プログラマとして 3 年間働いていましたが、会社を辞めたときに良いソフトウェア プロジェクトを完了しました。しかし、私はまだ足りないと感じているので、今は他の面でスキルを追加し続けています。この社会の競争は、頑張れば頑張るほど失業に近づきます。
最初の質問に関しては、変数を使用する前に Dim を使用して変数を定義することを強くお勧めします。あと 1 行のコードを記述することはそれほど難しくありません。このように、ASP ファイルのヘッダーで <%Option Explicit%> を使用すると、変数名を誤って記述した場合に、変数が定義されていないというエラーが返され、エラーの場所を簡単に見つけることができます。それ以外の場合、変数は Null 値になります。
さらに、2 番目の質問について、Option Explicit と合わせて説明しましょう。場合によっては、複数のファイル (ヘッド定義、トップ ナビゲーション、その他のコードなど) を含める必要があり、Option Explicit は ASP アプリケーションでのみ使用できます (ここではアプリケーションを指しており、特にページではなくアプリケーションを指します。ページを意味するものではありません) 1 回。したがって、複数のページで複数回呼び出されることによる混乱を避けるために、Option Explicit をインクルード ファイル内に配置しないことをお勧めします。
include に関する小さな質問について話しましょう。通常、インクルードするファイルが現在のディレクトリにある場合は、直接使用できます。
<!--#include file="abc.asp"-->
を含めます。ただし、多くの場合、含める必要のあるファイルが N 個あります。したがって、管理を容易にするために、それらを INC または include ディレクトリに置きます。このように、インクルード コードは次のように記述される場合があります。
<!--#include file="..incabc.asp" -->
これが私が議論したいことです。 .. を使用すると上位ディレクトリにアクセスできるため、セキュリティ上のリスクが生じることに注意してください。ユーザーはサイト外のファイルを不正に参照する可能性があります。このため、Microsoft がリリースした IIS Lockdown ツールはこの参照メソッドをブロックしており、Windows Server 2003 の IIS6.0 では Microsoft がデフォルトでこのメソッドをブロックしています。このディレクトリにないインクルード ファイルについては、次の安全な参照方法を使用することをお勧めします。
<!--#include virtual="/inc/abc.asp"-->
より有益な探索とディスカッションを歓迎します