1. إن حذف التعتيم أمر مريح ولكنه أيضًا خطر خفي!
إن تطبيق المتغير ثم استخدامه هو النهج القياسي:
خافت أ
أ = "1"
في الواقع، يمكنك القيام بذلك دون الكتابة بشكل خافت:
أ = "1"
لا يعتقد النظام أن هناك خطأ، وسيحدد تلقائيًا ما إذا كان a متغيرًا موجودًا، أم لا، فسيستمر في التنفيذ. وإذا لم يكن موجودًا، فسيتم تطبيقه تلقائيًا عليك. يبدو أن النظام ذكي وذكي ومراعي للغاية، ولكن هناك مخاطر خفية! فهل يعرف النظام ما أعنيه؟ من المحتمل جدًا أن يكون النظام ذكيًا جدًا وغير مفيد. السؤال 1: إذا كنت قد تقدمت بطلب للحصول على متغير من قبل، مثل المسؤول، وأريد تعيين قيمة لهذا المتغير لاحقًا، فأنا للأسف أكتب حرفًا خاطئًا أو أفتقد رسالة. حرف، مثل admin = "me"، انتظر النظام أخيرًا فرصة "لمساعدتي"، و"تطوع" للإعلان عن المتغيرات بالنسبة لي، ومن الصعب التعبير عن مدى "مراعاة الأمر"! نعم، قد يكون البرنامج قادرًا على التشغيل، ولكن المنطق معطل نظرًا لأن النظام لا يبلغ عن خطأ (أو يبلغ عن خطأ آخر لتضليلك)، فلن تتمكن من تحديد موقع المشكلة بسرعة إذا كان البرنامج كبيرًا قضاء الكثير من الوقت، ما هو شعورك بعد قضاء الكثير من الوقت في العثور على السبب الجذري؟ أنت بالتأكيد تريد توبيخ النظام لأنه "يحفز نفسه ذاتيًا". إذا أبلغ النظام أن اسم متغير المسؤول غير موجود، فسوف أعرف قريبًا أنني أخطأت في كتابته وأقوم بتصحيح المشكلة بسرعة دون الحاجة إلى "الانغماس" في الأمر. النظام "التلقائي" كن شغوفًا "! وهناك خطر خفي آخر ناجم عن إغفال الخافت سيتم مناقشته لاحقًا!
2. لن تتداخل المتغيرات المعلنة داخل الوظيفة مع المتغيرات الخارجية!
على سبيل المثال:
< %@LANGUAGE="VBSCRIPT " CODEPAGE="936"%>
<%
خافت أ
أ = "1"
الدالة getstr()
خافت أ
أ = "2"
الوظيفة النهائية.اكتب
& "<br>"
getstr()
استجابة.اكتب & "<br>"
%>
تظهر النتيجة أن المتغيرات المعلنة داخل الوظيفة لن تتداخل مع العالم الخارجي، ونطاقها داخل الوظيفة، وفي الواقع يجب على كل من درس لغات أخرى أن يعرف ذلك! لكن يجب أن نذكر أولاً أنه إذا تمت إزالة الـ a الخافت داخل الدالة، فإن a تعتبر a خارجية، وستتغير النتيجة! نطاق المتغيرات المطبقة في الملف هو هذا الملف.
3. تضمين يجعل الناس يحبونه ويكرهونه!
يمكن أن يجعل التضمين بنية برنامج ASP أكثر وضوحًا، ويمكن مشاركة بعض الوظائف شائعة الاستخدام بواسطة ملفات أخرى! في حين أنه يجلب فوائد، يجب عليك الانتباه إلى عيوبه!
نعود الآن إلى حذف dim المذكور في النقطة الأولى. ما ذكرته سابقًا هو أن مهمتي قد تحولت "بلطف" إلى متغير معلن بواسطة النظام. ما أتحدث عنه الآن هو العكس تمامًا، أريد الإعلان عن متغير، لكن النظام يعين له قيمة لأنه من الممكن الإعلان عن متغير حتى لو تم حذفه في كثير من الأحيان لا أستطيع مقاومة هذا الإغراء (أحب أيضًا التقديم بهذه الطريقة في بعض الأحيان. ، هيهي) ولكن هل يمكنك ضمان أن اسم المتغير الذي تقدمت بطلب للحصول عليه ليس موجودًا في البرنامج قبله؟ إذا كان أمامه اسم المتغير هذا، ألا يعني ذلك أنك تقدمت للتعيين؟ نادرًا ما يحدث هذا الخطأ في نفس الملف، لكن لا تنسَ أنه ملف مضمن مشكلة منطقية. إذا لم تكن كسولًا واستخدمت dim للتطبيق، فعندما يتم الإبلاغ عن الخطأ، ستكون محظوظًا بمعرفة أن اسم المتغير هذا موجود بالفعل! سيتم تصحيحه قريبا!
لنناقش الآن موقفًا أكثر تعقيدًا. إذا قمت بتضمين ملفين، فسيكون هناك نفس اسم المتغير في كلا الملفين. إذا استخدمت dim للتطبيق على كليهما، حسنًا، سيتم الإبلاغ عن خطأ يفيد بأن اسم المتغير موجود بالفعل. ، ستعرف المشكلة قريبًا. الآن يمكنك أن تفهم سبب حديثي عن النقطة الثانية من النطاق. نظرًا للنطاق، فإن المتغيرات التي تحمل الاسم نفسه في ملفات مختلفة لن "تتقاتل" بشكل عام. ومع ذلك، إذا تم تضمينه بواسطة ملف آخر في نفس الوقت، فستكون المشكلة مزعجة، لذلك إذا كان ملف asp الذي تكتبه مخصصًا للتضمين، فيرجى منع حدوث الموقف الذي يحمل نفس الاسم. بالعودة إلى المناقشة الأصلية، سيكون من الجيد أن يكون كل من المتغيرات المتضمنة بنفس الاسم خافتًا عند تطبيقه في ملفي التضمين، ولكن تظهر المشكلة إذا تم تطبيق الملف المضمن لاحقًا عن طريق حذف التطبيق الخافت المحذوف التالي تصبح مهمة، والشيء الفظيع هو أن هذا موجود في ملفين متضمنين، وهو مخفي جدًا، مما يزيد من صعوبة العثور على المشكلة!
وخلاصة القول، يمكنك كتابة بعض الأمثلة البسيطة لفهم المشاكل وأخيرًا أقترح:
1. الرجاء استخدام خافت لتطبيق المتغيرات قبل استخدامها! برامج معقدة بشكل خاص تم تطويرها بواسطة عدة أشخاص!
2. عند تعيين قيم للمتغيرات، يرجى الانتباه إلى تهجئة المتغيرات!
3. افهم ملفات التضمين بعناية.
*** الآن دعونا نتحدث عن التحقق من الأخطاء:
في الواقع، العثور على المشاكل أكثر أهمية من كتابة التعليمات البرمجية! ومن تجربتي الشخصية، تنقسم المشاكل إلى ثلاث فئات:
1. نوع الإبلاغ عن الأخطاء، المشكلة التي يواجهها نظام التجميع أثناء عملية التجميع للنظام، ستعطي رسالة خطأ. هذه هي المشكلة المفضلة للمبرمجين هههه، إنها ليست مشكلة غير طبيعية، ولكن هذا النوع من المشاكل أسهل للتحقق!
2. نوع المنطق، مشكلة مزعجة إلى حد ما، تم تجميع البرنامج بنجاح ويمكن تشغيله، لكن النتيجة المعروضة ليست هي النتيجة المتوقعة في المنطق الخاص بك. يا إلهي! ماذا علي أن أفعل؟ لا توجد رسالة سريعة، يمكنني فقط تحليل نتائج الخطأ بناءً على الخبرة والشعور، ثم التحقق من الكود المصدري، إذا سارت الأمور على ما يرام، فسيتم حلها في بضع دقائق النتيجة بعد يوم صعب!
3. فئة الأداء، مشكلة فظيعة. تم تجميع البرنامج بنجاح، ويعمل بشكل طبيعي، ويعرض بشكل طبيعي! ومع ذلك، في بعض الأحيان يأتي إليك خطأ بين الحين والآخر، وليس لديك أي فكرة عن الظروف التي يحدث فيها الخطأ، أو أن أداء البرنامج ليس عاليًا مثل البرامج المماثلة ويعمل ببطء. يمكن حل بعض هذه المشكلات في الداخل أسبوع أو شهر، وبعضها يمكن حله خلال أسبوع أو شهر، وأغلبها أمراض مستعصية لا يمكن علاجها. لقد تم تعذيبي حتى الموت بسبب هذا النوع من المشاكل!
لذلك، إذا كنت تريد تعلم البرمجة جيدًا، فيجب أن تحاول حل المشكلات بنفسك، وخاصةً مثل برامج ASP، حيث لا توجد مشكلات كثيرة في المنطق، بل توجد في الأساس رسائل خطأ ومواقع خطأ لا ينبغي أن يكون من الضروري تحليلها بنفسك. أعتقد أن بعض الأشخاص على استعداد لقضاء ثلاثة أيام في المنتدى في انتظار الآخرين ليخبروهم بمشاكلهم، لماذا لا يحلونها بأنفسهم؟ إذا وجدت مشكلة بنفسك، فسوف تكتسب الخبرة. هذه هي ثروة المبرمجين!
*** تجربة مبرمج صغيرة:
لا تعتقد أنك مبرمج لمجرد أنك تستطيع كتابة بضعة أسطر من التعليمات البرمجية أو تنفيذ بعض البرامج الصغيرة، فبعد العمل في شركة برمجيات لبضع سنوات، ستفهم ما يعنيه أن تكون مبرمجًا. كتابة التعليمات البرمجية ليست سوى التحقق من أخطاء التعليمات البرمجية وتحسينها، وكتابة وثائق البرنامج (ليس دليل مستخدم بسيط، ولكن تطبيق مشروع، تعليمات التصميم الأولية للمشروع، تعليمات التصميم التفصيلية للمشروع، تعليمات تصميم قاعدة البيانات، تعليمات اختبار المشروع، دليل المستخدم، المستخدم. دليل الصيانة، وما إلى ذلك)، حقائق إن مجرد قدرتك على البرمجة لا يعني أنه يمكنك تطوير البرمجيات. في الواقع، أنا لست جيدًا بما يكفي في بعض الجوانب، مثل كتابة وثائق البرامج. هاها، إن التفكير في كتابة وثائق البرامج أمر مخيف أكثر بكثير من كتابة برنامج! لقد عملت كمبرمج دلفي لمدة ثلاث سنوات على الرغم من أنني أكملت مشروعًا برمجيًا جيدًا عندما تركت الشركة. لكنني ما زلت أشعر بأنني غير كاف، لذا أواصل الآن إضافة المهارات في جوانب أخرى. المنافسة في هذا المجتمع شرسة جدًا بالفعل. كلما قللت من العمل الجاد، كلما عملت بجدية أكبر للاقتراب من البطالة!
فيما يتعلق بالسؤال الأول، أوصي بشدة باستخدام Dim لتحديد المتغيرات قبل استخدامها. ليس من الصعب جدًا كتابة سطر آخر من التعليمات البرمجية. ثم استخدم <%Option Explicit%> في رأس ملف ASP. وبهذه الطريقة، إذا كتبت اسم المتغير بشكل غير صحيح عن طريق الخطأ، فسيتم إرجاع خطأ بعدم تعريف المتغير، ويمكن العثور على موقع الخطأ بسهولة. وبخلاف ذلك، يكون المتغير قيمة فارغة.
بالإضافة إلى ذلك، دعونا نتحدث عن السؤال الثاني بالتزامن مع Option Explicit. في بعض الأحيان نحتاج إلى تضمين ملفات متعددة (مثل تعريف الرأس والتنقل العلوي والرموز الأخرى)، ولا يمكن استخدام Option Explicit إلا في تطبيق ASP (لاحظ أنه يشير إلى التطبيق هنا، ويشير على وجه التحديد إلى تطبيق، وليس صفحة، و لا يعني صفحة) مرة واحدة. لذلك، من الأفضل عدم وضع Option Explicit داخل ملف التضمين لتجنب الارتباك الناتج عن استدعائه عدة مرات على صفحات متعددة.
دعونا نتحدث عن سؤال صغير حول التضمين. بشكل عام، إذا كان الملف المراد تضمينه موجودًا في الدليل الحالي، فيمكننا استخدامه مباشرة
<!--#include file="abc.asp"-->
لتضمينه. ومع ذلك، في كثير من الأحيان يكون لدينا ملفات N تحتاج إلى تضمينها. لذلك، لتسهيل الإدارة، قمنا بوضعها في INC أو تضمين الدليل. بهذه الطريقة، يتم أحيانًا كتابة رمز التضمين على النحو التالي:
<!--#include file="..incabc.asp" -->
هذا ما أريد مناقشته. يرجى ملاحظة أن استخدام .. يمكنه الوصول إلى الدليل العلوي، مما يعرضك لخطر أمني: قد يقوم المستخدمون بالإشارة بشكل غير قانوني إلى الملفات الموجودة خارج الموقع. لهذا السبب، تقوم أداة IIS Lockdown التي أصدرتها Microsoft بحظر هذه الطريقة المرجعية، وتقوم Microsoft بحظر هذه الطريقة افتراضيًا على IIS6.0 لنظام التشغيل Windows Server 2003. بالنسبة للملفات المضمنة غير الموجودة في هذا الدليل، يوصى باستخدام طريقة المرجع الآمن هذه:
<!--#include virtual="/inc/abc.asp"-->
مرحبًا بالمزيد من الاستكشاف والمناقشة المفيدة