سطور من التعليمات البرمجية المصدرية
عدد أسطر الكود المصدري ( SLOC )، المعروف أيضًا باسم عدد أسطر الكود ( LOC )، هو مقياس برمجي يُستخدم لقياس حجم برنامج حاسوبي عن طريق عدّ عدد الأسطر في نص الكود المصدري للبرنامج . يُستخدم SLOC عادةً للتنبؤ بالجهد المطلوب لتطوير برنامج، بالإضافة إلى تقدير إنتاجية البرمجة أو سهولة صيانة البرنامج بعد إنتاجه.
طرق القياس
تعتمد العديد من المقارنات المفيدة على حجم سطور التعليمات البرمجية في المشروع. فمقارنة مشروع مكون من 10,000 سطر بمشروع آخر مكون من 100,000 سطر أكثر فائدة بكثير من مقارنة مشروع مكون من 20,000 سطر بمشروع آخر مكون من 21,000 سطر. ورغم أن كيفية قياس حجم سطور التعليمات البرمجية بدقة أمر قابل للنقاش، إلا أن الفروقات الكبيرة في هذا الحجم قد تكون مؤشرات واضحة على مدى تعقيد البرمجيات أو ساعات العمل المطلوبة .
يوجد نوعان رئيسيان من مقاييس SLOC: SLOC المادي (LOC) وSLOC المنطقي (LLOC). تختلف التعريفات المحددة لهذين المقياسين، ولكن التعريف الأكثر شيوعًا لـ SLOC المادي هو عدد الأسطر في نص شفرة المصدر للبرنامج باستثناء أسطر التعليقات. [ 1 ]
يحاول مقياس SLOC المنطقي قياس عدد "العبارات" القابلة للتنفيذ، لكن تعريفاته المحددة مرتبطة بلغات برمجة معينة (أحد مقاييس SLOC المنطقية البسيطة للغات البرمجة الشبيهة بلغة C هو عدد الفواصل المنقوطة التي تنهي العبارات). من الأسهل بكثير إنشاء أدوات لقياس SLOC المادي، كما أن تعريفات SLOC المادي أسهل شرحًا. مع ذلك، فإن مقاييس SLOC المادي أكثر حساسية لتنسيقات وأساليب الكتابة غير ذات الصلة منطقيًا من مقاييس SLOC المنطقية. لكن غالبًا ما تُذكر مقاييس SLOC دون تعريفها، وقد يختلف SLOC المنطقي اختلافًا كبيرًا عن SLOC المادي.
لنأخذ هذا المقتطف من كود C كمثال على الغموض الذي يواجهنا عند تحديد SLOC:
for ( int i = 0 ; i < 100 ; i ++ ) printf ( "hello" ); /* عرض مئة تحية */في هذا المثال لدينا:
- سطر واحد فعلي من التعليمات البرمجية (LOC)،
- سطران منطقيان من التعليمات البرمجية (LLOC) ( عبارة for وعبارة printf )،
- سطر تعليق واحد.
اعتمادًا على المبرمج ومعايير البرمجة، يمكن كتابة "سطر" التعليمات البرمجية المذكور أعلاه على عدة أسطر منفصلة:
/* عرض مئة تحية */ for ( int i = 0 ; i < 100 ; i ++ ) { printf ( "hello" ); }في هذا المثال لدينا:
- 4 أسطر فعلية من التعليمات البرمجية (LOC): هل وضع الأقواس عمل يجب تقديره؟
- سطران منطقيان من التعليمات البرمجية (LLOC): ماذا عن كل العمل الذي يتم القيام به في كتابة الأسطر غير العباراتية؟
- سطر تعليق واحد: يجب أن تأخذ الأدوات في الاعتبار جميع التعليمات البرمجية والتعليقات بغض النظر عن موضع التعليق.
حتى قيم SLOC "المنطقية" و"المادية" قد يكون لها تعريفات متعددة ومختلفة. قام روبرت إي. بارك (أثناء عمله في معهد هندسة البرمجيات ) وآخرون بتطوير إطار عمل لتحديد قيم SLOC، لتمكين المستخدمين من شرح وتحديد مقياس SLOC المستخدم في المشروع بدقة. على سبيل المثال، تعيد معظم أنظمة البرمجيات استخدام التعليمات البرمجية، ويُعدّ تحديد أيّ من التعليمات البرمجية المعاد استخدامها (إن وُجدت) التي يجب تضمينها أمرًا بالغ الأهمية عند إعداد تقرير عن هذا المقياس.
الأصول
عندما طُرح مقياس SLOC، كانت اللغات الأكثر شيوعًا، مثل فورتران ولغة التجميع ، لغاتٍ تعتمد على الأسطر. طُوّرت هذه اللغات في زمن كانت فيه البطاقات المثقبة الوسيلة الرئيسية لإدخال البيانات في البرمجة. كانت البطاقة المثقبة الواحدة تُمثل عادةً سطرًا واحدًا من التعليمات البرمجية، أي أنها كانت عنصرًا منفصلًا يسهل عدّه. ولأنها كانت الناتج المرئي للمبرمج، فقد كان من المنطقي للمديرين حساب أسطر التعليمات البرمجية كمقياس لإنتاجية المبرمج، حتى أنهم كانوا يُشيرون إلى ذلك بـ" صور البطاقات ". أما اليوم، فتُتيح لغات البرمجة الأكثر استخدامًا مرونةً أكبر في التنسيق. لم تعد أسطر النصوص مُقيدةً بـ 80 أو 96 عمودًا، ولم يعد سطر النص يُقابل بالضرورة سطرًا واحدًا من التعليمات البرمجية.
استخدام مقاييس SLOC
تُعدّ مقاييس عدد أسطر التعليمات البرمجية (SLOC) مثيرةً للجدل إلى حدٍّ ما، لا سيما في طريقة إساءة استخدامها أحيانًا. وقد أكّدت التجارب مرارًا وتكرارًا وجود ارتباط وثيق بين الجهد المبذول وعدد أسطر التعليمات البرمجية ، أي أن البرامج ذات القيم الأعلى لعدد أسطر التعليمات البرمجية تستغرق وقتًا أطول في التطوير. وبالتالي، يُمكن أن يكون عدد أسطر التعليمات البرمجية فعّالًا في تقدير الجهد المبذول. مع ذلك، فإنّ الارتباط بين الوظائف وعدد أسطر التعليمات البرمجية أقلّ وضوحًا: فقد يتمكّن المطوّرون الماهرون من تطوير الوظائف نفسها باستخدام كمية أقلّ بكثير من التعليمات البرمجية، لذا قد يُظهر برنامجٌ ذو عدد أسطر أقلّ وظائفَ أكثر من برنامجٍ آخر مماثل. إنّ اعتماد عدد أسطر التعليمات البرمجية كمقياس للإنتاجية له محاذيره، إذ يُمكن للمطوّر أن يكتب بضعة أسطر فقط، ومع ذلك يكون أكثر إنتاجيةً بكثير من حيث الوظائف من مطوّرٍ يكتب عددًا أكبر من الأسطر (ويبذل جهدًا أكبر عمومًا). قد يدمج المطوّرون الماهرون عدّة وحدات برمجية في وحدة واحدة، ممّا يُحسّن النظام، لكنّه قد يبدو ذا إنتاجية سلبية لأنّه يُزيل جزءًا من التعليمات البرمجية. علاوةً على ذلك، غالبًا ما يلجأ المطوّرون عديمو الخبرة إلى تكرار التعليمات البرمجية ، وهو أمرٌ غير مُستحبّ على الإطلاق لأنّه أكثر عرضةً للأخطاء وأكثر تكلفةً في الصيانة، لكنّه يؤدّي إلى زيادة عدد أسطر التعليمات البرمجية.
يُظهر حساب عدد أسطر التعليمات البرمجية (SLOC) مشاكل دقة إضافية عند مقارنة البرامج المكتوبة بلغات مختلفة، ما لم تُطبَّق عوامل تعديل لتوحيد اللغات. تُوازن لغات البرمجة المختلفة بين الإيجاز والوضوح بطرق متباينة؛ فعلى سبيل المثال، تتطلب معظم لغات التجميع مئات الأسطر من التعليمات البرمجية لأداء نفس المهمة التي تُنجز ببضعة أحرف في لغة APL . يُظهر المثال التالي مقارنة بين برنامج "مرحباً بالعالم" المكتوب بلغات BASIC و C و COBOL (وهي لغة معروفة بإسهابها الشديد).
| أساسي | ج | كوبول |
|---|---|---|
اطبع "مرحباً بالعالم" | #include <stdio.h>int main () { printf ( "hello, world \n " ); } | قسم التعريف . معرف البرنامج . مرحباً . قسم الإجراءات . عرض "مرحباً بالعالم" . الرجوع . إنهاء البرنامج مرحباً . |
| عدد أسطر الكود: 1 (بدون مسافات بيضاء) | عدد أسطر الكود: 4 (باستثناء المسافات البيضاء) | عدد أسطر الكود: 6 (باستثناء المسافات البيضاء) |
من المشاكل الشائعة والمتزايدة في مقارنة مقاييس عدد أسطر التعليمات البرمجية (SLOC) الفرق بين التعليمات البرمجية المُولَّدة تلقائيًا والمكتوبة يدويًا. غالبًا ما تتمتع أدوات البرمجيات الحديثة بالقدرة على توليد كميات هائلة من التعليمات البرمجية تلقائيًا ببضع نقرات. على سبيل المثال، تُولِّد أدوات تصميم واجهات المستخدم الرسومية جميع التعليمات البرمجية المصدرية لعناصر التحكم الرسومية تلقائيًا بمجرد سحب أيقونة إلى مساحة العمل. لا يمكن مقارنة الجهد المبذول في إنشاء هذه التعليمات البرمجية بالجهد اللازم لكتابة برنامج تشغيل جهاز ، على سبيل المثال. وبالمثل، قد يكون إنشاء فئة واجهة مستخدم رسومية مخصصة يدويًا أكثر تطلبًا من كتابة برنامج تشغيل جهاز بسيط؛ ومن هنا تكمن قصور هذا المقياس.
توجد العديد من نماذج تقدير التكلفة والجدول الزمني والجهد التي تستخدم عدد أسطر التعليمات البرمجية في كل سطر (SLOC) كمعامل إدخال، بما في ذلك سلسلة نماذج التكلفة البنائية ( COCOMO ) واسعة الانتشار التي وضعها باري بوهم وآخرون، ونموذج PRICE Systems True S ، ونموذج SEER-SEM الخاص بغالوراث . ورغم أن هذه النماذج أظهرت قدرة تنبؤية جيدة، إلا أن دقتها تعتمد على دقة التقديرات المُدخلة إليها (وخاصةً تقديرات عدد أسطر التعليمات البرمجية في كل سطر). وقد دعا العديد من الباحثين [ 2 ] إلى استخدام نقاط الوظائف بدلاً من عدد أسطر التعليمات البرمجية في كل سطر كمقياس للوظائف، ولكن نظرًا لارتباط نقاط الوظائف ارتباطًا وثيقًا بعدد أسطر التعليمات البرمجية في كل سطر (ولا يمكن قياسها تلقائيًا)، فإن هذا الرأي ليس مُتفقًا عليه عالميًا.
مثال
وفقًا لفينسنت مارايا، [ 3 ] فإن قيم SLOC لأنظمة التشغيل المختلفة في خط إنتاج Windows NT من مايكروسوفت هي كما يلي:
| سنة | نظام التشغيل | SLOC (مليون) |
|---|---|---|
| 1993 | ويندوز إن تي 3.1 | 4-5 [ 3 ] |
| 1994 | ويندوز إن تي 3.5 | 7-8 [ 3 ] |
| 1996 | ويندوز إن تي 4.0 | 11-12 [ 3 ] |
| 2000 | ويندوز 2000 | أكثر من 29 [ 3 ] |
| 2001 | ويندوز إكس بي | 45 [ 4 ] [ 5 ] |
| 2003 | ويندوز سيرفر 2003 | 50 [ 3 ] |
درس ديفيد أ. ويلر توزيعة ريد هات لنظام التشغيل لينكس ، وأفاد بأن إصدار ريد هات لينكس 7.1 [ 6 ] (الذي صدر في أبريل 2001) احتوى على أكثر من 30 مليون سطر برمجي فعلي. كما استنتج أنه لو تم تطويره بالطرق الاحتكارية التقليدية، لكان تطلب حوالي 8000 سنة عمل من الجهد التطويري، ولبلغت تكلفته أكثر من مليار دولار (بقيمة الدولار الأمريكي في عام 2000).
أُجريت دراسة مماثلة لاحقًا على نظام التشغيل دبيان جنو/لينكس الإصدار 2.2 (المعروف أيضًا باسم "بوتيتو")؛ وقد صدر هذا النظام في الأصل في أغسطس 2000. وخلصت هذه الدراسة إلى أن دبيان جنو/لينكس 2.2 احتوى على أكثر من 55 مليون سطر برمجي، ولو طُوّر بطريقة احتكارية تقليدية، لكان قد تطلّب 14005 سنوات عمل وتكلفة 1.9 مليار دولار أمريكي. وتشير نتائج لاحقة للأدوات المستخدمة إلى أن الإصدار التالي من دبيان احتوى على 104 ملايين سطر برمجي، وذلك اعتبارًا من عام 2005.، سيشمل الإصدار الأحدث أكثر من 213 مليون سطر من التعليمات البرمجية.
| سنة | نظام التشغيل | SLOC (مليون) |
|---|---|---|
| 2000 | ديبيان 2.2 | 55–59 [ 7 ] [ 8 ] |
| 2002 | ديبيان 3.0 | 104 [ 8 ] |
| 2005 | ديبيان 3.1 | 215 [ 8 ] |
| 2007 | ديبيان 4.0 | 283 [ 8 ] |
| 2009 | ديبيان 5.0 | 324 [ 8 ] |
| 2012 | ديبيان 7.0 | 419 [ 9 ] |
| 2009 | أوبن سولاريس | 9.7 |
| فري بي إس دي | 8.8 | |
| 2005 | نظام التشغيل ماك أو إس إكس 10.4 | 86 [ 10 ] [ n 1 ] |
| 1991 | نواة لينكس 0.01 | 0.010239 |
| 2001 | نواة لينكس 2.4.2 | 2.4 [ 6 ] |
| 2003 | نواة لينكس 2.6.0 | 5.2 |
| 2009 | نواة لينكس 2.6.29 | 11.0 |
| 2009 | نواة لينكس 2.6.32 | 12.6 [ 11 ] |
| 2010 | نواة لينكس 2.6.35 | 13.5 [ 12 ] |
| 2012 | نواة لينكس 3.6 | 15.9 [ 13 ] |
| 30-06-2015 | نواة لينكس قبل الإصدار 4.2 | 20.2 [ 14 ] |
جدوى
المزايا
- نطاق أتمتة العد: بما أن سطر الكود كيان مادي، يمكن الاستغناء بسهولة عن جهد العد اليدوي من خلال أتمتة عملية العد. يمكن تطوير أدوات صغيرة لعد أسطر الكود في البرنامج. مع ذلك، لا يمكن استخدام أداة عد الكود المنطقي المصممة للغة برمجة معينة مع لغات أخرى نظرًا للاختلافات النحوية والبنيوية بينها. في المقابل، تم إنتاج عدادات أسطر كود مادية تدعم عشرات اللغات.
- مقياس بديهي: يُعدّ عدد أسطر التعليمات البرمجية مقياسًا بديهيًا لقياس حجم البرمجيات، إذ يمكن رؤيته وتصوّر تأثيره. أما نقاط الوظائف ، فتُعتبر مقياسًا موضوعيًا لا يُمكن تصوره ككيان مادي، بل هو موجود فقط في الفضاء المنطقي. وبهذا، يُصبح عدد أسطر التعليمات البرمجية مفيدًا للتعبير عن حجم البرمجيات لدى المبرمجين ذوي الخبرة المحدودة.
- مقياس شائع: تُستخدم مقاييس عدد أسطر التعليمات البرمجية منذ بدايات البرمجيات. [ 15 ] ولذلك، يمكن القول إن بيانات عدد أسطر التعليمات البرمجية المتاحة أكثر من أي مقياس حجم آخر.
العيوب
- غياب المساءلة: يعاني مقياس عدد أسطر البرمجة من بعض المشاكل الجوهرية. يرى البعض أنه من غير المجدي قياس إنتاجية المشروع بالاعتماد فقط على نتائج مرحلة البرمجة، والتي لا تمثل عادةً سوى 30% إلى 35% من الجهد الإجمالي.
- عدم التوافق بين الجهد المبذول والوظائف: على الرغم من أن التجارب أكدت مرارًا وتكرارًا أن الجهد المبذول يرتبط ارتباطًا وثيقًا بعدد أسطر الكود، إلا أن الوظائف ترتبط به ارتباطًا أقل. بمعنى آخر، قد يتمكن المطورون المهرة من تطوير نفس الوظائف باستخدام كود أقل بكثير، لذا قد يُظهر برنامج ذو عدد أسطر أقل وظائف أكثر من برنامج آخر مشابه. على وجه الخصوص، يُعد عدد أسطر الكود مقياسًا ضعيفًا لإنتاجية الأفراد، لأن المطور الذي يكتب بضعة أسطر فقط قد يكون أكثر إنتاجية من مطور يكتب عددًا أكبر من الأسطر - بل وأكثر من ذلك: فبعض عمليات إعادة هيكلة الكود الجيدة، مثل "استخراج الدالة"، للتخلص من الكود الزائد والحفاظ على نظافته، ستؤدي في الغالب إلى تقليل عدد أسطر الكود.
- التأثير السلبي على التقدير: بسبب الحقيقة المذكورة في النقطة رقم 1، فإن التقديرات المستندة إلى أسطر التعليمات البرمجية يمكن أن تسوء بشكل سلبي، في كل الاحتمالات.
- خبرة المطور: يختلف تنفيذ منطق معين باختلاف مستوى خبرة المطور. وبالتالي، يختلف عدد أسطر التعليمات البرمجية من شخص لآخر. قد يُنفذ مطور ذو خبرة وظيفة معينة بعدد أسطر أقل من التعليمات البرمجية مقارنةً بمطور آخر أقل خبرة، على الرغم من استخدامهما نفس لغة البرمجة.
- اختلاف لغات البرمجة: لنفترض وجود تطبيقين يؤديان نفس الوظائف (شاشات، تقارير، قواعد بيانات). أحدهما مكتوب بلغة C++ والآخر بلغة مثل COBOL. سيكون عدد نقاط الوظائف متطابقًا تمامًا، لكن جوانب التطبيق ستختلف. بالتأكيد، لن يكون عدد أسطر البرمجة اللازمة لتطوير التطبيق متطابقًا. ونتيجة لذلك، سيختلف مقدار الجهد المطلوب لتطوير التطبيق (ساعات لكل نقطة وظيفة). على عكس عدد أسطر البرمجة، سيظل عدد نقاط الوظائف ثابتًا.
- ظهور أدوات واجهة المستخدم الرسومية : مع ظهور لغات وأدوات البرمجة القائمة على واجهة المستخدم الرسومية، مثل فيجوال بيسك ، أصبح بإمكان المبرمجين كتابة عدد قليل نسبيًا من التعليمات البرمجية وتحقيق مستويات عالية من الوظائف. على سبيل المثال، بدلًا من كتابة برنامج لإنشاء نافذة ورسم زر، يمكن للمستخدم الذي يستخدم أداة واجهة المستخدم الرسومية استخدام السحب والإفلات وعمليات الماوس الأخرى لوضع المكونات على مساحة العمل. عادةً لا تُؤخذ التعليمات البرمجية التي تُنشئها أداة واجهة المستخدم الرسومية تلقائيًا في الاعتبار عند استخدام طرق قياس عدد أسطر التعليمات البرمجية. ينتج عن ذلك تباين بين اللغات؛ فالمهمة نفسها التي يمكن إنجازها بسطر واحد من التعليمات البرمجية (أو بدون أي تعليمات برمجية على الإطلاق) في لغة ما، قد تتطلب عدة أسطر من التعليمات البرمجية في لغة أخرى.
- مشاكل تعدد اللغات: في بيئة تطوير البرمجيات الحالية، غالبًا ما تُطوَّر البرامج بأكثر من لغة. وكثيرًا ما تُستخدم عدة لغات حسب تعقيد المتطلبات. ويُشكِّل تتبُّع معدلات الإنتاجية والأخطاء والإبلاغ عنها تحديًا كبيرًا في هذه الحالة، إذ لا يُمكن ربط الأخطاء بلغة برمجة مُحدَّدة بعد دمج النظام. وتُعدّ نقطة الوظيفة أفضل مقياس لحجم البرنامج في هذه الحالة.
- غياب معايير موحدة لحساب الأسطر البرمجية: لا يوجد تعريف موحد لما يُعتبر سطرًا برمجيًا. هل تُحتسب التعليقات؟ هل تُضمّن تعريفات البيانات؟ ماذا يحدث إذا امتدّت عبارة برمجية على عدّة أسطر؟ – هذه بعض الأسئلة التي تُطرح غالبًا. مع أن منظمات مثل SEI وIEEE قد نشرت بعض الإرشادات في محاولة لتوحيد عملية الحساب، إلا أنه من الصعب تطبيقها عمليًا، خاصةً مع ظهور لغات برمجة جديدة باستمرار كل عام.
- علم النفس: المبرمج الذي تُقاس إنتاجيته بعدد أسطر الكود لديه حافز لكتابة كود مطوّل بلا داعٍ. وكلما زاد تركيز الإدارة على عدد أسطر الكود، زاد حافز المبرمج لتوسيع الكود بإضافة تعقيدات غير ضرورية. وهذا أمر غير مرغوب فيه، لأن زيادة التعقيد قد تؤدي إلى زيادة تكلفة الصيانة وزيادة الجهد المطلوب لإصلاح الأخطاء.
في الفيلم الوثائقي الذي بثته قناة PBS بعنوان "انتصار المهووسين" ، انتقد ستيف بالمر، المدير التنفيذي المستقبلي لشركة مايكروسوفت، استخدام عدّ أسطر التعليمات البرمجية:
في شركة IBM، هناك عقيدة راسخة في عالم البرمجيات تُلزمك بحساب عدد أسطر الكود (K-LOC)، حيث يُمثل كل سطر ألف سطر من الكود. ما حجم المشروع؟ حسنًا، إنه مشروع من عشرة آلاف سطر تقريبًا. وهذا مشروع من عشرين ألف سطر. وهذا مشروع من خمسين ألف سطر. أرادت IBM أن تجعل هذا هو المعيار الأساسي لكيفية حصولنا على أجورنا. كم ربحنا من نظام التشغيل OS/2 ، وكم ربحوا هم. كم ألف سطر كتبت؟ وكنا نحاول إقناعهم - مهلًا، إذا كان لدى مطور فكرة جيدة ويمكنه إنجاز شيء ما بأربعة آلاف سطر بدلًا من عشرين ألف سطر، فهل يجب أن نتقاضى أجرًا أقل؟ لأنه أنجز شيئًا أصغر وأسرع، بعدد أسطر أقل. ألف سطر، ألف سطر، هذه هي المنهجية. يا إلهي! على أي حال، دائمًا ما يُصيبني هذا الأمر بالضيق.
بحسب متحف تاريخ الحاسوب، وجد مطور شركة أبل بيل أتكينسون في عام 1982 مشاكل في هذه الممارسة:
عندما كان فريق ليزا يسعى جاهدًا لإنهاء برنامجهم عام ١٩٨٢، بدأ مديرو المشاريع يطلبون من المبرمجين تقديم استمارات أسبوعية تُفصّل عدد أسطر التعليمات البرمجية التي كتبوها. رأى بيل أتكينسون أن هذا الأمر سخيف. ففي الأسبوع الذي أعاد فيه كتابة إجراءات حساب المناطق في برنامج كويك درو لتصبح أسرع بست مرات وأقصر بألفي سطر، كتب "-٢٠٠٠" في الاستمارة. وبعد بضعة أسابيع أخرى، توقف المديرون عن مطالبته بملء الاستمارة، فامتثل بكل سرور. [ ١٦ ] [ ١٧ ]
انظر أيضاً
ملحوظات
- ↑ ربما يشمل ذلك مجموعة iLife بأكملها، وليس فقط نظام التشغيل والتطبيقات المرفقة عادةً.
مراجع
- ↑ فو نغوين؛ صوفيا ديدز-روبين؛ توماس تان؛ باري بوهم (2007)، معيار عد أسطر التعليمات البرمجية (ملف PDF) ، مركز هندسة النظم والبرمجيات، جامعة جنوب كاليفورنيا
- ↑ IFPUG "قياس فوائد استخدام نقاط الوظائف"
- 1 2 3 4 5 6 "كم عدد أسطر التعليمات البرمجية في نظام ويندوز؟" . موقع Knowing.NET. 6 ديسمبر 2005. تاريخ الاسترجاع: 30 أغسطس 2010 .وهذا بدوره يستشهد بكتاب "The Build Master" لفينسنت مارايا كمصدر للمعلومات.
- ↑ "كم عدد أسطر التعليمات البرمجية في نظام التشغيل ويندوز إكس بي؟" . مايكروسوفت. 11 يناير 2011. مؤرشف من الأصل في 26 فبراير 2022.
- ↑ "تاريخ ويندوز - مايكروسوفت ويندوز" . 21-09-2012. مؤرشف من الأصل في 21-09-2012 . تم الاطلاع عليه في 26-03-2021 .
- 1 2 ديفيد أ. ويلر (2001-06-30). "أكثر من جيجابوك: تقدير حجم جنو/لينكس" .
- ^ غونزاليس باراهونا، خيسوس م. ميغيل أ. أورتونيو بيريز؛ بيدرو دي لاس هيراس كيروس؛ خوسيه سينتينو غونزاليس؛ فيسنتي ماتيلان أوليفيرا. "عد البطاطس: حجم دبيان 2.2" . debian.org . مؤرشفة من الأصلي بتاريخ 2008-05-03 . تم الاسترجاع 2003-08-12 .
- 1 2 3 4 5 روبليس، غريغوريو. "عدّ دبيان" . مؤرشف من الأصل بتاريخ 14 مارس 2013. تم الاطلاع عليه بتاريخ 16 فبراير 2007 .
- ↑ تم إصدار دبيان 7.0 في مايو 2013. هذا الرقم هو تقدير نُشر في 13 فبراير 2012، باستخدام قاعدة الشفرة التي أصبحت فيما بعد دبيان 7.0، وباستخدام نفس أسلوب البرمجيات المستخدم في البيانات التي نشرها ديفيد أ. ويلر. جيمس برومبرجر. "ديبيان ويزي: 19 مليار دولار أمريكي. سعرك... مجانًا!" . مؤرشف من الأصل في 23 فبراير 2014. تم الاطلاع عليه في 7 فبراير 2014 .
- ↑ جوبز، ستيف (أغسطس 2006). "بث مباشر من مؤتمر WWDC 2006: كلمة ستيف جوبز الرئيسية" . تم الاطلاع عليه بتاريخ 16 فبراير 2007.
86 مليون سطر من التعليمات البرمجية المصدرية التي تم نقلها للعمل على بنية جديدة تمامًا دون أي مشاكل.
- ↑ ثورستن ليمهاوس (2009-12-03). "ما الجديد في لينكس 2.6.32" . مؤرشف من الأصل بتاريخ 2013-12-19 . تم الاطلاع عليه بتاريخ 2009-12-24 .
- ↑ غريغ كروه-هارتمان؛ جوناثان كوربيت؛ أماندا ماكفرسون (أبريل 2012). "تطوير نواة لينكس: مدى سرعة التقدم، ومن يقوم به، وماذا يفعلون، ومن يموله" . مؤسسة لينكس . تاريخ الاسترجاع: 10 أبريل 2012 .
- ↑ ثورستن ليمهاوس (1 أكتوبر 2012). "ملخص، توقعات، إحصائيات - بطولة H المفتوحة: أخبار ومقالات" . مؤرشف من الأصل بتاريخ 19 ديسمبر 2013.
- ^ "Linux-Kernel durchbricht die 20-Millionen-Zeilen-Marke" . 30 يونيو 2015.
- ↑ IFPUG "تاريخ موجز لمقاييس أسطر التعليمات البرمجية (loc)"
- ↑ "شفرة مصدر MacPaint و QuickDraw" . CHM . 2010-07-18 . تم الاسترجاع في 2021-04-15 .
- ↑ "Folklore.org: -2000 سطر من التعليمات البرمجية" . www.folklore.org . تم الاطلاع عليه بتاريخ 15 أبريل 2021 .
للمزيد من القراءة
- لي، لو؛ هيربسليب، جيم؛ شو، ماري (مايو 2005). التنبؤ بمعدلات العيوب الميدانية باستخدام نهج مشترك قائم على الوقت والمقاييس: دراسة حالة لنظام OpenBSD (CMU-ISRI-05-125) . جامعة كارنيجي ميلون.
- ماكجرو، غاري (مارس-أبريل 2003). "من الصفر: ورشة عمل DIMACS لأمن البرمجيات" . مجلة IEEE للأمن والخصوصية . 1 (2): 59-66 . doi : 10.1109/MSECP.2003.1193213 .
- بارك، روبرت إي.؛ وآخرون . (31 أغسطس 1992). "قياس حجم البرمجيات: إطار عمل لحساب عبارات المصدر" . تقرير فني CMU/SEI-92-TR-20 .
روابط خارجية
- تعريفات مقاييس معيار الموارد (RSM) لأسطر التعليمات البرمجية العملية تحدد "أسطر التعليمات البرمجية الفعالة" كمقياس واقعي للتعليمات البرمجية مستقل عن أسلوب البرمجة.
- مقاييس eLOC الفعالة لأسطر التعليمات البرمجية لبرامج المصادر المفتوحة الشائعة مثل Linux Kernel 2.6.17 و Firefox و Apache HTTPD و MySQL و PHP باستخدام RSM.
- ويلر، ديفيد أ. "SLOCCount" . تم الاسترجاع في 12 أغسطس 2003 .
- ويلر، ديفيد أ. (يونيو 2001). "حساب أسطر التعليمات البرمجية المصدرية (SLOC)" . تم الاسترجاع في 12 أغسطس 2003 .
- تانينباوم، أندرو س. أنظمة التشغيل الحديثة (الطبعة الثانية). برنتيس هول. ISBN 0-13-092641-8.
- هوارد دحداح (24 يناير 2007). "تانينباوم يوضح رؤيته لنظام تشغيل سهل الاستخدام حتى لكبار السن" . مؤرشف من الأصل بتاريخ 27 يناير 2007. تم الاطلاع عليه بتاريخ 29 يناير 2007 .
- سي إم لوت. "أدوات جمع المقاييس لشفرة المصدر C و C++" . مؤرشف من الأصل في 19 يونيو 2020.
- Folklore.org: قصص ماكنتوش: -2000 سطر من التعليمات البرمجية
- مقاييس البرمجيات