سؤال

في كثير من الأحيان، يكتب المبرمجون التعليمات البرمجية التي تولد تعليمات برمجية أخرى.

(المصطلح الفني هو البرمجة الفوقية, ، ولكنه أكثر شيوعًا من مجرد المترجمين المتقاطعين؛فكر في كل صفحة ويب PHP تنشئ HTML أو كل ملف XSLT.)

أحد المجالات التي أجدها صعبة هو التوصل إلى تقنيات لضمان ذلك كلاهما يتم وضع مسافة بادئة واضحة للملف المصدر المكتوب بخط اليد وملف الكائن الذي تم إنشاؤه بواسطة الكمبيوتر للمساعدة في تصحيح الأخطاء.غالبًا ما يبدو أن الهدفين يتنافسان.

أجد هذا تحديًا خاصًا في مجموعة PHP/HTML.أعتقد أن السبب هو:

  • يوجد في بعض الأحيان كود HTML في الملف المصدر أكثر من كود PHP الذي تم إنشاؤه
  • تميل ملفات HTML إلى أن تكون أطول من عبارات SQL، على سبيل المثال، وتحتاج إلى مسافة بادئة أفضل
  • يحتوي HTML على ميزات حساسة للمساحة (على سبيل المثال.بين العلامات)
  • والنتيجة هي HTML مرئية بشكل عام أكثر من عبارات SQL، لذلك هناك ضغط أكبر للقيام بعمل معقول.

ما هي التقنيات التي تستخدمها لمعالجة هذا؟


يحرر:أوافق على أن هناك ثلاث حجج على الأقل لعدم الاهتمام بإنشاء كود HTML جميل:

  • يتم زيادة تعقيد توليد التعليمات البرمجية.
  • لا يحدث فرقًا في العرض بواسطة المتصفح؛يمكن للمطورين استخدام Firebug أو ما شابه لمشاهدته بشكل جيد.
  • نتيجة أداء بسيطة - زيادة وقت التنزيل لأحرف المسافات البيضاء.

لقد قمت بالتأكيد في بعض الأحيان بإنشاء تعليمات برمجية دون التفكير في المسافة البادئة (خاصة SQL).

ومع ذلك، هناك بعض الحجج التي تدفع في الاتجاه الآخر:

  • أجد، في الممارسة العملية، أنني يفعل قراءة التعليمات البرمجية التي تم إنشاؤها بشكل متكرر - إن اتخاذ خطوات إضافية للوصول إليها أمر غير مريح.
  • يحتوي HTML على بعض المشكلات المتعلقة بحساسية المساحة والتي تظهر أحيانًا.

على سبيل المثال، خذ بعين الاعتبار الكود:

<div class="foo">
    <?php
        $fooHeader();
        $fooBody();
        $fooFooter();
    ?>
</div>

وهو أوضح من الكود التالي:

<div class="foo"><?php
        $fooHeader();
        $fooBody();
        $fooFooter();
?></div>

ومع ذلك، فهو يتميز أيضًا بعرض مختلف بسبب المسافة البيضاء المضمنة في HTML.

هل كانت مفيدة؟

المحلول

في الحالة الأكثر عمومية، قمت بكتابة كود XSLT الذي يقوم بإنشاء كود واجهة قاعدة بيانات C++.على الرغم من أنني حاولت في البداية إخراج تعليمات برمجية ذات مسافة بادئة بشكل صحيح من XSLT، إلا أن ذلك سرعان ما أصبح غير مقبول.كان الحل الذي توصلت إليه هو تجاهل التنسيق تمامًا في مخرجات XSLT، ثم تشغيل السطر الطويل جدًا من التعليمات البرمجية الناتج مسافة بادئة لـ GNU.أدى هذا إلى إنتاج ملف مصدر C++ منسق بشكل معقول ومناسب لتصحيح الأخطاء.

أستطيع أن أتخيل أن المشكلة تصبح أكثر شائكة عند التعامل مع مصدر مدمج مثل HTML وPHP.

نصائح أخرى

قم بإنشاء AST ثم اجتيازه بالترتيب وإصدار كود المصدر الذي تم تنسيقه بشكل صحيح.

إحدى الأساليب التي أستخدمها عندما يهيمن كود الإنشاء على الكود الذي تم إنشاؤه هو تمرير معلمة مسافة بادئة.

على سبيل المثال، في بايثون، توليد المزيد من بايثون.

def generateWhileLoop(condition, block, indentPrefix = ""):
    print indentPrefix + "while " + condition + ":"
    generateBlock(block, indentPrefix + "    ")

أو حسب مزاجي:

def generateWhileLoop(condition, block, indentLevel = 0):
    print " " * (indentLevel * spacesPerIndent) + "while " + condition + ":"
    generateBlock(block, indentLevel + 1)

لاحظ الافتراض بأن condition عبارة عن جزء قصير من النص يتناسب مع نفس السطر، بينما block على سطر بمسافة بادئة منفصلة.إذا لم يكن هذا الرمز متأكدًا مما إذا كانت العناصر الفرعية بحاجة إلى مسافة بادئة، فستبدأ هذه الطريقة في التراجع.

كما أن هذه التقنية ليست مفيدة تقريبًا لرش كميات صغيرة نسبيًا من PHP إلى HTML.

[عدل للتوضيح:لقد كتبت السؤال وأيضا هذه الإجابة.أردت أن أجمع الإجابات بتقنية واحدة أستخدمها بالفعل وتكون مفيدة في بعض الأحيان، ولكن هذه التقنية لا تناسبني مع ترميز PHP النموذجي، لذلك أبحث عن أفكار أخرى مثلها.]

لقد وجدت أن تجاهل المسافة البادئة أثناء التوليد هو الأفضل.لقد قمت بكتابة محرك "تنسيق التعليمات البرمجية" العام الذي قام بمعالجة جميع التعليمات البرمجية التي تم إخراجها.بهذه الطريقة، يمكنني تحديد قواعد المسافة البادئة وقواعد بناء جملة التعليمات البرمجية بشكل منفصل عن المولد.هناك فوائد واضحة لهذا الانفصال.

وأنا أتفق مع إجابة التفكير الغريب.

في بعض الأحيان يكون من الأفضل حل المشكلة عن طريق عكسها.إذا وجدت نفسك تقوم بإنشاء قدر كبير من النص، ففكر فيما إذا كان من الأسهل كتابة النص كقالب يحتوي على أجزاء صغيرة من كود الإنشاء الذكي.أو إذا كان بإمكانك تقسيم المشكلة إلى سلسلة من القوالب الصغيرة التي تقوم بتجميعها، ثم وضع مسافة بادئة لكل قالب ككل.

عند إنشاء مواقع الويب بلغة PHP، أجد أن الخلط بين HTML ووظيفة PHP محددة يمثل مشكلة، فهو يحد من النظرة العامة ويجعل تصحيح الأخطاء أكثر صعوبة.الحل لتجنب الخلط في هذه الحالة هو استخدام المحتوى القائم على القالب، انظر سمارتي على سبيل المثال.وباستثناء النية الأفضل، فإن صياغة المحتوى تكون مفيدة لأشياء أخرى، مثل التصحيح الأسرع على سبيل المثال.إذا كان العميل يحتاج إلى تغيير في التخطيط، فيمكن العثور على مشكلة التخطيط هذه وإصلاحها بسرعة، دون الحاجة إلى الاهتمام بكود PHP الوظيفي الذي ينشئ البيانات (والعكس صحيح).

على وجه التحديد فيما يتعلق بإنشاء HTML - ما أهمية ذلك؟

أنت تقضي الكثير من الوقت في التنقل بين المعلمات، ومحاولة معرفة مدى تداخلك وما إلى ذلك.بصرف النظر عن كونه مضيعة عامة للوقت (نظرًا لعدم وجود اختلاف في الإخراج النهائي المعروض)، كيف يمكنك الحفاظ على كل هذه الأشياء أثناء إضافة علامات HTML أخرى والتفاف الصفحات في div وما إلى ذلك؟

على أية حال، تثبيت فايربوغشريط أدوات مطور IE لاختبار IE بعد ذلك) ويعرض لك كلاهما HTML بالتنسيق المتداخل، ويمكنك فقط النقر فوق عنصر الصفحة لعرض العلامات مباشرةً - وهي طريقة أكثر كفاءة من النظر إلى مخرجات HTML المصدر الأولي.

في حالة PHP/HTML، أحاول الاحتفاظ بمسافة بادئة لكل جزء من التعليمات البرمجية باستمرار في كود المصدر الخاص به.وهذا يبقي الكود قابلاً للقراءة حيث يكون مهمًا حقًا عادة له تأثير جانبي يتمثل في إنتاج مخرجات HTML قابلة للقراءة.وكما قال الآخرون، فإن Firebug يعتني بالباقي.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top