طي الشفرة

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

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

على سبيل المثال، في لغة جافا، يتطلب حقل خاص واحد مع دالة جلب ودالة تعيين ما لا يقل عن 3 أسطر، إذا كانت كل دالة على سطر منفصل:

private String name = null ; public String getName ( ) { return name ; } public void setName ( String name ) { this.name = name ; }​

يتوسع هذا إلى 10 أسطر مع فواصل الأسطر الوظيفية التقليدية والمسافات بين الوظائف (بما في ذلك سطر جديد لاحق):

private String name = null ;public String getName () { return name ; }public void setName ( String name ) { this . name = name ; }

يؤدي استخدام Javadoc في التوثيق إلى توسيع هذا إلى 20 سطرًا:

/** * خاصية <code>name</code> قابلة للقراءة/الكتابة. */ private String name = null ;/** * دالة جلب للخاصية <code>name</code> */ public String getName () { return name ; }/** * دالة تعيين للخاصية <code>name</code>. * @param name */ public void setName ( String name ) { this . name = name ; }

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

قد تكون البيانات الوصفية طويلة، وعادةً ما تكون أقل أهمية من البيانات التي تصفها. يسمح اختصار البيانات الوصفية بالتركيز بشكل أساسي على البيانات، وليس على البيانات الوصفية نفسها. على سبيل المثال، يمكن اختصار قائمة طويلة من السمات في لغة C# يدويًا كما يلي: ^{[ 6 ]}

#region Attributes [Browsable(false)] [MergableProperty(false)] [DefaultValue(null)] [PersistenceMode(PersistenceMode.InnerProperty)] [TemplateContainer(typeof(MyType))] [TemplateInstance(TemplateInstance.Single)] #endregion public ITemplate ContentTemplate { get ; set ; }

يظهر الكود الناتج على النحو التالي:

السمات العامة ITemplate ContentTemplate { get ; set ; }

التعليقات هي نوع من البيانات الوصفية سهلة القراءة، وقد تُعيق التعليقات المطولة انسيابية الكود. ينطبق هذا على التعليقات الطويلة التي تُغطي جزءًا قصيرًا من الكود، كفقرة لشرح سطر واحد، أو على التعليقات الخاصة بمولدات التوثيق ، مثل Javadoc أو توثيق XML . تتيح خاصية طي الكود إمكانية إضافة تعليقات طويلة، مع عرضها فقط عند الحاجة. في حال احتواء التعليق الطويل على سطر ملخص واحد، كما هو الحال في توثيق Python، يظل الملخص ظاهرًا حتى عند طي الجزء، مما يُتيح عرضًا موجزًا/تفصيليًا.

تتألف البرمجة الهيكلية من كتل برمجية متداخلة، وقد تُخفي الكتل البرمجية الطويلة - مثل عبارات التبديل الطويلة - البنية العامة. يسمح طي الكود برؤية البنية العامة والتوسع إلى مستوى محدد. علاوة على ذلك، في بعض الاستخدامات، وخاصة البرمجة الهيكلية الصارمة (الخروج من دالة واحدة)، توجد أنماط برمجية يصعب رؤيتها عند النظر إلى الكود الموسع. على سبيل المثال، في إدارة الموارد في البرمجة الهيكلية، يتم عادةً الحصول على مورد، يليه كتلة برمجية تستخدم هذا المورد، ثم تحريره. يصعب رؤية عملية الحصول على المورد وتحريره إذا كانت هناك كتلة برمجية طويلة بينهما، ولكن يسهل رؤيتها إذا تم طي الكتلة الوسيطة. وبالمثل، في الكود الشرطي if...then...else، قد تكون الكتل الثانوية بعيدة عن عبارة الشرط.

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

يمكن طي التعليمات البرمجية القديمة - أو أي تعليمات برمجية لا يرغب المطور في عرضها أو تغييرها في وقت معين - بحيث يتمكن المبرمجون من التركيز على التعليمات البرمجية قيد الدراسة.

تعتمد نقاط الطي المعتمدة على بناء الجملة على محتوى الملف الذي يتم تحريره لتحديد بداية ونهاية مناطق الطي المحددة. تُعرَّف نقاط الطي المعتمدة على بناء الجملة عادةً بناءً على أيٍّ من الميزات الفرعية القياسية للغة الترميز أو لغة البرمجة المستخدمة، أو جميعها. وتُعدّ هذه النقاط مرغوبة لكونها تلقائية ومتوافقة مع بنية الكود، ولكنها قد تتطلب جهدًا كبيرًا لتنفيذها، ووقتًا طويلًا لحسابها أثناء تحرير الملف.

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

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

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

ومن الرموز البارزة الأخرى #region( توجيهات C# )، و #Region( توجيهات Visual Basic )، المستخدمة في محرر أكواد Microsoft Visual Studio . تُعامل هذه التوجيهات نحويًا كتوجيهات للمترجم ، على الرغم من أنها لا تؤثر على عملية الترجمة.

باعتبارها طريقة يدوية، فإن الطي القائم على الرموز يسمح بالتقدير في تجميع التعليمات البرمجية بناءً على معايير تعسفية، مثل "الوظائف المتعلقة بمهمة معينة"، والتي لا يمكن استنتاجها من التحليل النحوي.

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

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