أسلوب البرمجة

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

if (hours < 24 && minutes < 60 && seconds < 60) {
    return true;
} else {
    return false;
}

أو

if (hours < 24 && minutes < 60 && seconds < 60)
{
    return true;
}
else
{
    return false;
}

مع شيء مثل:

if ( hours<
24 && minutes<
60 && seconds<
60)
{return true
;} else
{return false
;}

أول نموذجان يكونان غالبا أسهل في القراءة لأنها تحمل مسافات بادئة بأسلوب ثابت (أسلوب «الفقرة المتدلية»). ويعد أسلوب المسافة البادئة أسلوبا مفيدا بشكل خاص عند التعامل مع مقومات متداخلة متعددة.

يجتمع أسلوب المسافة البادئة موديوليك زيرو مع عائدات الحوامل بدلا من المسافات البادئة. قارن كل ما سبق بما يلي:

if (hours < 24 && minutes < 60 && seconds < 60)
return true;

else
return false;

يستخدم بايثون المسافة البادئة للإشارة إلى هياكل التحكم، لذا فالمسافات البادئة الصحيحة مطلوبة. وبفعل ذلك تكون الحاجة لوضع أقواس مع قوس (ترقيم) (مثل {... }) يتم إزالته. على الجانب الآخر، فإن النسخ واللصق اليدوي لشفرة بايثون يمكن أن يؤدي على بعض المشاكل لأن مستوى المسافة البادئة للشفرة الملصوقة يمكن ألا يكون نفس مستوى المسافة البادئة للخط الحالي. مثل هذا التنسيق يمكن أن يكون القيام به يدويا مرهقا ولكن بعض محرر نصوص وبيئة تطوير متكاملة يتمتعون بسمات خاصة للقيام بذلك تلقائيا. كما تتواجد بعض المشاكل أيضا حين يمكن جعل البايثون غير قابلة للاستخدام حين تنشر في أحد المنتديات أو الصفحات الإليكترونية التي تزيل المساحات البيضاء بالرغم من أنه من الممكن تجنب هذه المشكلة حيثما أمكن من أجل إدراج الشفرة في بطاقات تحتفظ بمساحات بيضاء مثل"<pre>... </pre>" (for لغة ترميز النص الفائق), "[code]"... "[/code]" (for bbcode), إلخ.

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

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

$search = array('a', 'b', 'c', 'd', 'e');
$replacement = array('foo', 'bar', 'baz', 'quux');

// Another example:

$value = 0;
$anothervalue = 1;
$yetanothervalue = 2;

مع:

$search = array('a', 'b', 'c', 'd', 'e');
$replacement = array('foo', 'bar', 'baz', 'quux');

// مثال آخر:

          $value = 0;
   $anothervalue = 1;
$yetanothervalue = 2;

المثال السابق يوضح أمرين بشكل بديهي لم تكونا واضحين في المثال الأسبق:

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

ومن بين الأمور الجدلية ضد المحاذاة العمودية:

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

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

على سبيل المثال، قارن الأمثلة التالية المتكافئة في تركيبها والخاصة بشفرة السي.

int i;
for(i=0;i<10;++i){
    printf("%d",i*i+i);
}

مقابل

int i;
for (i=0; i<10; ++i) {
    printf("%d", i*i+i);
}

مقابل

int i;
for (i = 0; i < 10; ++i) {
    printf ("%d", i * i + i);
}

مقابل

int i;
for(i = 0; i < 10; ++i) {
    printf("%d", i * i + i);
}

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

مثال على ذلك، نجد أن أحد المبرمجين يفضلون وقفات الجدولة المكونة من أربع وقفات وقد تم تثبيت مجموعة أدواته على هذه الوضعية ويستعين بها لتنسيق شفرته.

int ix; // Index to scan array
long sum; // Accumulator for sum

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

int ix; // Index to scan array
long sum; // Accumulator for sum

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

class MyClass {
	int foobar(int qux, // first parameter
	 int quux); // second parameter
	int foobar2(int qux, // first parameter
	 int quux, // second parameter
	 int quuux); // third parameter
};