1. Omettre la luminosité est pratique mais constitue également un danger caché !
Appliquer une variable puis l'utiliser est l'approche standard :
atténuer un
une = "1"
En fait, vous pouvez le faire sans écrire dim :
une = "1"
Le système ne pense pas qu'il y a une erreur. Il déterminera automatiquement si a est une variable existante. Si elle existe, elle continuera à s'exécuter. Si elle n'existe pas, elle s'appliquera automatiquement pour vous ! Il semble que le système soit si intelligent, intelligent et attentionné, mais il y a des dangers cachés ! Le système sait-il ce que je veux dire ? Le système est très probablement trop intelligent et inutile ! Question 1 : Si j'ai déjà demandé une variable, comme administrateur, et que je souhaite attribuer une valeur à cette variable plus tard, j'écris malheureusement la mauvaise lettre ou je manque une lettre, telle que administrateur = "moi", le système a finalement attendu une opportunité de "m'aider", et s'est "volontaire" pour déclarer les variables pour moi. Il est difficile d'exprimer à quel point c'était "prévenant" ! Oui, le programme peut s'exécuter, mais la logique est perturbée. Étant donné que le système ne signale pas d'erreur (ou signale une autre erreur pour vous induire en erreur), vous ne pouvez pas localiser rapidement le problème. Si le programme est volumineux, vous le ferez. passer beaucoup de temps. Comment vous sentez-vous après avoir passé beaucoup de temps à trouver la cause profonde ? Vous voulez certainement reprocher au système d'être "auto-motivé". Si le système signalait que le nom de la variable administrateur n'existait pas, je saurais bientôt que je l'ai mal orthographié et corrigerais le problème rapidement sans avoir à me "livrer". le système « Soyez passionné » automatique ! Un autre danger caché causé par l’omission de dim sera abordé plus tard !
2. Les variables déclarées dans la fonction n'interféreront pas avec les variables externes !
Par exemple:
< %@LANGUAGE="VBSCRIPT " CODEPAGE="936"%>
<%
atténuer un
une = "1"
fonction getstr()
atténuer un
une = "2"
de fonction de fin.Écrivez
un & "<br>"
getstr()
réponse.Écrivez un & "<br>"
%>
Le résultat montre que les variables déclarées à l'intérieur de la fonction n'interféreront pas avec le monde extérieur. Sa portée est à l'intérieur de la fonction. En fait, tous ceux qui ont étudié d'autres langages devraient le savoir ! Mais il faut d’abord préciser que si le dim a au sein de la fonction est supprimé, alors que a est considéré comme un a externe, et le résultat changera ! La portée des variables appliquées dans le fichier est ce fichier.
3. Une inclusion qui fait que les gens l'aiment et la détestent !
include peut rendre la structure du programme ASP plus claire, et certaines fonctions couramment utilisées peuvent être partagées par d'autres fichiers ! Même si cela apporte des avantages, il faut faire attention aux inconvénients !
Revenons maintenant à l'omission de dim mentionnée dans le premier point. Ce que j'ai mentionné plus tôt, c'est que mon affectation a été "gentiment" transformée en variable déclarée par le système. Ce dont je parle maintenant, c'est exactement le contraire. Je veux déclarer une variable, mais le système lui attribue une valeur car il est possible de déclarer une variable même si dim est omis. Pour les programmeurs qui aiment sauvegarder et simplifier, ils le font. souvent, je ne peux pas résister à cette tentation (j'aime aussi postuler comme ça parfois. , hehe) Mais pouvez-vous garantir que le nom de variable que vous avez demandé n'est pas dans le programme qui le précède ? S'il y a ce nom de variable devant, cela ne signifie-t-il pas que vous avez postulé pour une affectation ? Cette erreur peut rarement être commise dans le même fichier, mais n'oubliez pas d'inclure. Si le fichier inclus contient les variables que vous avez demandées, alors vous êtes foutu. Même s'il peut s'exécuter, c'est déjà un. problème logique. Si vous n'êtes pas paresseux et utilisez dim pour postuler, lorsque l'erreur sera signalée, vous aurez la chance de savoir que ce nom de variable existe déjà ! Ce sera bientôt corrigé !
Parlons maintenant d'une situation plus compliquée. Si vous incluez deux fichiers, il y aura le même nom de variable dans les deux fichiers. Si vous utilisez dim pour appliquer les deux, d'accord, cela signalera simplement une erreur indiquant que le nom de la variable existe déjà. , vous connaîtrez bientôt le problème. Vous pouvez maintenant comprendre pourquoi j'ai parlé du deuxième point de portée. En raison de la portée, les variables portant le même nom dans différents fichiers ne se "battront" généralement pas. Cependant, s'il est inclus par un autre fichier en même temps, le problème sera gênant, donc si le fichier asp que vous écrivez est destiné à être inclus, veuillez éviter que la situation du même nom ne se produise. Pour en revenir à la discussion originale, ce serait bien si les deux variables d'inclusion portant le même nom étaient dim lorsqu'elles étaient appliquées dans les deux fichiers d'inclusion, mais le problème survient si le fichier inclus ultérieurement est appliqué en omettant dim L'application dim omise suivante. devient une mission. Le pire, c'est que c'est dans deux fichiers d'inclusion, ce qui est très caché, ce qui rend plus difficile la recherche du problème !
Pour résumer, vous pouvez écrire quelques exemples simples pour comprendre les problèmes. Enfin, je suggère :
1. Veuillez utiliser dim pour appliquer des variables avant de les utiliser ! Des programmes particulièrement complexes développés par plusieurs personnes !
2. Lorsque vous attribuez des valeurs aux variables, faites attention à l'orthographe des variables !
3. Comprenez attentivement les fichiers inclus.
***Parlons maintenant de la vérification des erreurs :
en fait, trouver des problèmes est plus important que d'écrire du code ! D'après mon expérience personnelle, les problèmes se répartissent en trois catégories :
1. Type de rapport d'erreur, le problème rencontré par le système de compilation lors du processus de compilation du système, il donnera un message d'erreur. C'est le problème préféré des programmeurs Haha, ce n'est pas anormal, mais ce genre de problème est le cas. le plus simple à vérifier !
2. Type logique, un problème plutôt gênant. Le programme est compilé avec succès et peut être exécuté, mais le résultat affiché n'est pas celui attendu dans votre logique. Oh mon Dieu! Que dois-je faire ? Il n'y a pas de message d'invite. Je peux uniquement analyser les résultats de l'erreur en fonction de mon expérience et de mon ressenti, puis vérifier le code source. Si tout se passe bien, le problème sera résolu dans quelques minutes. résultat après une journée difficile !
3. Catégorie Performance, un problème terrible. Le programme a été compilé avec succès, s'exécute normalement et s'affiche normalement ! Cependant, il arrive parfois qu'une erreur survienne de temps en temps et vous n'avez aucune idée des circonstances dans lesquelles l'erreur est déclenchée, ou les performances du programme ne sont pas aussi élevées que celles de programmes similaires et s'exécutent lentement. Certains de ces problèmes peuvent être résolus en interne. une semaine ou un mois, et certaines peuvent être résolues en une semaine ou un mois. La plupart d'entre elles sont des maladies tenaces qui ne peuvent être guéries. J'ai été torturé à mort par ce genre de problème !
Par conséquent, si vous voulez bien apprendre la programmation, vous devez essayer de résoudre les problèmes par vous-même. En particulier, comme les programmes ASP, il n'y a pas beaucoup de problèmes de logique. Il y a essentiellement des rapports d'erreur et des emplacements d'erreur. ne devrait pas être nécessaire de les analyser par vous-même. Difficile à résoudre. Je pense que certaines personnes sont prêtes à passer trois jours sur le forum à attendre que d'autres leur fassent part de leurs problèmes. Pourquoi ne les résolvent-ils pas eux-mêmes ? Si vous trouvez vous-même un problème, vous gagnerez en expérience. C'est la richesse des programmeurs !
***Une petite expérience de programmeur :
Ne pensez pas que vous êtes un programmeur simplement parce que vous pouvez écrire quelques lignes de code ou avoir réalisé quelques petits programmes. Après avoir travaillé dans une entreprise de logiciels pendant quelques années, vous comprendrez ce que signifie être programmeur. L'écriture de code n'est rien d'autre que la vérification et l'optimisation des erreurs de code, la rédaction de la documentation du logiciel (pas un simple manuel d'utilisation, mais une application de projet, des instructions de conception préliminaires de projet, des instructions de conception détaillées de projet, des instructions de conception de base de données, des instructions de test de projet, un manuel d'utilisation, un manuel d'utilisation). manuel de maintenance, etc.), faits Ce n'est pas parce que vous savez programmer que vous pouvez développer des logiciels. En fait, je ne suis pas assez bon dans certains aspects, comme écrire de la documentation sur un logiciel Haha, c'est une chose effrayante à laquelle penser. Écrire une documentation sur un logiciel est bien plus pénible que d'écrire un programme ! Je suis programmeur Delphi depuis trois ans, même si j'ai réalisé un bon projet logiciel lorsque j'ai quitté l'entreprise. Mais je me sens toujours insuffisant, alors maintenant je continue à ajouter des compétences dans d'autres domaines. La concurrence dans cette société est déjà très féroce. Moins on travaille dur, plus on travaille dur pour se rapprocher du chômage !
Concernant la première question, je vous recommande fortement d'utiliser Dim pour définir des variables avant de les utiliser. Il n'est pas très difficile d'écrire une ligne de code supplémentaire. Utilisez ensuite <%Option Explicit%> dans l'en-tête du fichier ASP. De cette façon, si vous écrivez accidentellement le nom de la variable de manière incorrecte, une erreur indiquant que la variable n'est pas définie sera renvoyée et l'emplacement de l'erreur pourra être facilement trouvé. Sinon, la variable est une valeur Null.
De plus, parlons de la deuxième question en conjonction avec Option Explicit. Parfois, nous devons inclure plusieurs fichiers (tels que la définition de la tête, la navigation supérieure et d'autres codes), et Option Explicit ne peut être utilisé que dans une application ASP (notez qu'il fait ici référence à une application, spécifiquement à une application, pas à une page, et ne veut pas dire une page) une fois. Par conséquent, il est préférable de ne pas placer Option Explicit dans le fichier d'inclusion pour éviter toute confusion causée par un appel répété sur plusieurs pages.
Parlons d'une petite question sur l'inclusion. Généralement, si le fichier à inclure est dans le répertoire courant, on peut directement utiliser
<!--#include file="abc.asp"-->
pour l'inclure. Cependant, nous avons souvent N fichiers qui doivent être inclus. Ainsi, afin de faciliter la gestion, nous les mettons dans un répertoire INC ou include. De cette façon, le code d'inclusion s'écrit parfois comme :
<!--#include file="..incabc.asp" -->
C'est ce dont je veux discuter. Veuillez noter que l'utilisation de .. peut accéder au répertoire supérieur, ce qui entraîne un risque de sécurité : les utilisateurs peuvent référencer illégalement des fichiers en dehors du site. Pour cette raison, l'outil IIS Lockdown publié par Microsoft bloque cette méthode de référence, et Microsoft bloque cette méthode par défaut sur IIS6.0 de Windows Server 2003. Pour les fichiers inclus qui ne se trouvent pas dans ce répertoire, il est recommandé d'utiliser cette méthode de référence sécurisée :
<!--#include virtual="/inc/abc.asp"-->
Bienvenue dans une exploration et une discussion plus utiles