Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Строки исходного кода ( 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:

для  ( я  =  0 ;  я  <  100 ;  я ++ )  printf ( "привет" );  / * Сколько это строк кода? * /

В этом примере мы имеем:

  • 1 физическая строка кода (LOC),
  • 2 логические строки кода (LLOC) ( для оператора и оператора printf ),
  • 1 строка комментария.

В зависимости от программиста и стандартов кодирования указанная выше «строка кода» может быть записана на многих отдельных строках:

/ * Сколько это строк кода? * / for  ( я  =  0 ;  я  <  100 ;  я ++ ) {  printf ( "привет" ); }

В этом примере мы имеем:

  • 4 физических строки кода (LOC): нужно ли оценивать работу расстановки скобок?
  • Две логические строки кода (LLOC): как насчет всей работы по написанию строк без инструкций?
  • 1 строка комментария: инструменты должны учитывать весь код и комментарии независимо от размещения комментариев.

Даже «логические» и «физические» значения SLOC могут иметь большое количество различных определений. Роберт Э. Парк (в то время как в Институте программной инженерии ) и другие разработали структуру для определения значений SLOC, чтобы люди могли тщательно объяснять и определять меру SLOC, используемую в проекте. Например, большинство программных систем повторно используют код, и определение того, какой (если есть) повторно используемый код включить, важно при составлении отчета о показателе.

Истоки [ править ]

В то время, когда люди начали использовать SLOC в качестве метрики, наиболее часто используемые языки, такие как FORTRAN и язык ассемблера , были строчно-ориентированными языками. Эти языки были разработаны в то время, когда перфокарты были основной формой ввода данных для программирования. Одна перфокарта обычно представляет собой одну строку кода. Это был один дискретный объект, который легко пересчитать. Это был видимый результат работы программиста, поэтому менеджерам было разумно считать строки кода мерой продуктивности программиста, даже имея в виду такие, как « изображения карточек».". Сегодня наиболее часто используемые компьютерные языки предоставляют гораздо больше возможностей для форматирования. Текстовые строки больше не ограничиваются 80 или 96 столбцами, и одна строка текста больше не обязательно соответствует одной строке кода.

Использование мер SLOC [ править ]

Меры SLOC несколько противоречивы, особенно в том смысле, что они иногда используются не по назначению. Эксперименты неоднократно подтверждали, что усилия сильно коррелируют с SLOC [ необходима цитата ], то есть программы с более высокими значениями SLOC требуют больше времени для разработки. Таким образом, SLOC может быть эффективным при оценке усилий. Однако функциональность хуже коррелирует с SLOC: опытные разработчики могут разработать ту же функциональность с гораздо меньшим количеством кода, поэтому одна программа с меньшим количеством SLOC может демонстрировать больше функциональности, чем другая аналогичная программа. Подсчет SLOC как показателя производительности имеет свои недостатки, поскольку разработчик может разработать только несколько строк и при этом быть гораздо более продуктивным с точки зрения функциональности, чем разработчик, который в итоге создает больше строк (и обычно затрачивает больше усилий). Хорошие разработчики могут объединить несколько модулей кода в один модуль, улучшая систему, но при этом снижая производительность, поскольку они удаляют код. Кроме того, неопытные разработчики часто прибегают к дублированию кода., который крайне не рекомендуется, поскольку он более подвержен ошибкам и требует больших затрат в обслуживании, но приводит к более высокому SLOC.

Подсчет SLOC вызывает дополнительные проблемы с точностью при сравнении программ, написанных на разных языках, если для нормализации языков не применяются поправочные коэффициенты. Различные компьютерные языки по-разному уравновешивают краткость и ясность; В качестве крайнего примера, большинству языков ассемблера потребуются сотни строк кода для выполнения той же задачи, что и несколько символов в APL . В следующем примере показано сравнение программы «hello world», написанной на C , и той же программы, написанной на COBOL - языке, который известен своей особенно многословностью.

CКОБОЛ
#include  <stdio.h>int  main ()  {  printf ( " \ n Привет, мир \ n " ); }
 отдел идентификации. идентификатор программы. Привет . процедурное деление. показать "привет, мир" вернитесь назад . конец программы привет.
Строки кода: 4
(без пробелов)		Строк кода: 6
(без пробелов)

Другой все более распространенной проблемой при сравнении показателей SLOC является разница между автоматически сгенерированным и написанным вручную кодом. Современные программные инструменты часто имеют возможность автоматически генерировать огромные объемы кода с помощью нескольких щелчков мыши. Например, построители графического пользовательского интерфейса автоматически генерируют весь исходный код для графических элементов управления, просто перетаскивая значок в рабочее пространство. Работу по созданию этого кода нельзя разумно сравнивать с работой, необходимой, например, для написания драйвера устройства. Точно так же, созданный вручную пользовательский класс графического интерфейса может быть более требовательным, чем простой драйвер устройства; отсюда и недостаток этой метрики.

Существует несколько моделей оценки затрат, графика и усилий, которые используют SLOC в качестве входного параметра, включая широко используемую серию моделей конструктивной модели затрат ( COCOMO ) Барри Боэма и др., PRICE Systems True S и SEER-SEM от Galorath . Несмотря на то, что эти модели продемонстрировали хорошую предсказательную силу, они настолько хороши, насколько хороши оценки (в частности, оценки SLOC), предоставленные им. Многие [2] выступали за использование функциональных точек вместо SLOC в качестве меры функциональности, но, поскольку функциональные точки сильно коррелированы с SLOC (и не могут быть измерены автоматически), это не универсальная точка зрения.

Пример [ править ]

По словам Винсента Maraia, [3] значения SLOC для различных операционных систем в Microsoft «s Windows NT линейки продуктов заключаются в следующем:

ГодОперационная системаSLOC (млн.)
1993 г.Windows NT 3.14–5 [3]
1994 г.Windows NT 3.57–8 [3]
1996 г.Windows NT 4.011–12 [3]
2000 г.Windows 2000более 29 [3]
2001 г.Windows XP45 [4] [5]
2003 г.Windows Server 200350 [3]

Дэвид А. Уилер изучил дистрибутив Red Hat операционной системы Linux и сообщил, что Red Hat Linux версии 7.1 [6] (выпущенной в апреле 2001 г.) содержит более 30 миллионов физических SLOC. Он также экстраполировал, что, если бы он был разработан обычными собственными средствами, он потребовал бы около 8000 человеко-лет разработки и стоил бы более 1 миллиарда долларов (в долларах США 2000 года).

Позже аналогичное исследование было проведено для Debian GNU / Linux версии 2.2 (также известного как «Potato»); эта операционная система была первоначально выпущена в августе 2000 года. Это исследование показало, что Debian GNU / Linux 2.2 включает более 55 миллионов SLOC, и, если бы разработка производилась обычным частным способом, потребовалось бы 14 005 человеко-лет и 1,9 миллиарда долларов США на разработку. Более поздние прогоны использованных инструментов сообщают, что в следующем выпуске Debian было 104 миллиона SLOC, а по состоянию на 2005 год последний выпуск будет включать более 213 миллионов SLOC.

ГодОперационная системаSLOC (млн.)
2000 г.Debian 2.255–59 [7] [8]
2002 г.Debian 3.0104 [8]
2005 г.Debian 3.1215 [8]
2007 г.Debian 4.0283 [8]
2009 г.Debian 5.0324 [8]
2012 г.Debian 7.0419 [9]
2009 г.OpenSolaris9,7
FreeBSD8,8
2005 г.Mac OS X 10.486 [10] [n 1]
1991 г.Ядро Linux 0.010,010239
2001 г.Ядро Linux 2.4.22,4 [6]
2003 г.Ядро Linux 2.6.05.2
2009 г.Ядро Linux 2.6.2911.0
2009 г.Ядро Linux 2.6.3212,6 [11]
2010 г.Ядро Linux 2.6.3513,5 [12]
2012 г.Ядро Linux 3.615,9 [13]
2015-06-30Ядро Linux до 4.220,2 [14]

Утилита [ править ]

Преимущества [ править ]

  1. Возможности автоматизации подсчета: поскольку строка кода является физическим объектом, ручные подсчеты можно легко исключить, автоматизируя процесс подсчета. Для подсчета LOC в программе могут быть разработаны небольшие утилиты. Однако утилита подсчета логического кода, разработанная для определенного языка, не может использоваться для других языков из-за синтаксических и структурных различий между языками. Однако были произведены физические счетчики LOC, которые учитывают десятки языков.
  2. Интуитивная метрика: строка кода служит интуитивной метрикой для измерения размера программного обеспечения, потому что ее можно увидеть, а эффект от нее можно визуализировать. Функциональные точки считаются скорее объективной метрикой, которую нельзя представить как физическую сущность, она существует только в логическом пространстве. Таким образом, LOC пригодится, чтобы выразить размер программного обеспечения среди программистов с низким уровнем опыта.
  3. Повсеместная мера: меры LOC используются с самых первых дней создания программного обеспечения. [15] Таким образом, можно утверждать, что доступно больше данных LOC, чем любой другой показатель размера.

Недостатки [ править ]

  1. Отсутствие подотчетности: мера по строкам кода страдает некоторыми фундаментальными проблемами. Некоторые [ кто? ] считают, что бесполезно измерять продуктивность проекта, используя только результаты этапа кодирования, на который обычно приходится от 30% до 35% общих усилий. [ необходима цитата ]
  2. Отсутствие связи с функциональностью: хоть эксперименты [ кем? ] неоднократно подтверждали, что, хотя усилия сильно коррелируют с LOC, функциональность хуже коррелирует с LOC. То есть опытные разработчики могут разработать ту же функциональность с гораздо меньшим количеством кода, поэтому одна программа с меньшим LOC может демонстрировать больше функциональности, чем другая аналогичная программа. В частности, LOC является плохим показателем производительности отдельных людей, потому что разработчик, который разрабатывает только несколько строк, может быть более продуктивным, чем разработчик, создающий больше строк кода - даже больше: некоторый хороший рефакторинг, такой как «метод извлечения», чтобы избавиться от него. избыточный код и его чистота в основном уменьшают количество строк кода.
  3. Неблагоприятное влияние на оценку: из-за факта, представленного в пункте № 1, оценки, основанные на строках кода, во всех возможных случаях могут оказаться неверными.
  4. Опыт разработчика: реализация определенной логики зависит от уровня опыта разработчика. Следовательно, количество строк кода отличается от человека к человеку. Опытный разработчик может реализовать определенные функции в меньшем количестве строк кода, чем другой разработчик с относительно меньшим опытом, хотя они используют тот же язык.
  5. Разница в языках: рассмотрим два приложения, которые предоставляют одинаковые функции (экраны, отчеты, базы данных). Одно из приложений написано на C ++, а другое - на таком языке, как COBOL. Количество функциональных точек будет точно таким же, но аспекты приложения будут другими. Строки кода, необходимые для разработки приложения, определенно не будут такими же. Как следствие, количество усилий, необходимых для разработки приложения, будет другим (часов на функциональную точку). В отличие от строк кода, количество функциональных точек останется постоянным.
  6. Появление инструментов с графическим пользовательским интерфейсом : с появлением языков программирования на основе графического интерфейса пользователя и таких инструментов, как Visual Basic , программисты могут писать относительно небольшой код и достигать высоких уровней функциональности. Например, вместо того, чтобы писать программу для создания окна и рисования кнопки, пользователь с графическим интерфейсом пользователя может использовать перетаскивание и другие операции с мышью для размещения компонентов в рабочей области. Код, который автоматически генерируется инструментом GUI, обычно не принимается во внимание при использовании методов измерения LOC. Это приводит к различиям между языками; та же задача, которая может быть выполнена в одной строке кода (или вообще без кода) на одном языке, может потребовать нескольких строк кода на другом.
  7. Проблемы с несколькими языками: в сегодняшнем сценарии программного обеспечения программное обеспечение часто разрабатывается на нескольких языках. Очень часто используется несколько языков в зависимости от сложности и требований. Отслеживание и отчетность о производительности и дефектах представляет собой серьезную проблему в этом случае, поскольку дефекты не могут быть отнесены к конкретному языку после интеграции системы. Функциональная точка в этом случае является лучшим средством измерения размера.
  8. Отсутствие стандартов подсчета: нет стандартного определения того, что такое строка кода. Учитываются ли комментарии? Включены ли декларации данных? Что произойдет, если оператор растянется на несколько строк? - Это вопросы, которые часто возникают. Хотя такие организации, как SEI и IEEE, опубликовали некоторые рекомендации в попытке стандартизировать подсчет, их трудно применить на практике, особенно в связи с тем, что каждый год вводятся все новые и новые языки.
  9. Психология: программист, продуктивность которого измеряется строками кода, будет иметь стимул писать излишне подробный код. Чем больше менеджмент сосредотачивается на строках кода, тем больше у программиста стимула расширять свой код ненужной сложностью. Это нежелательно, поскольку повышенная сложность может привести к увеличению затрат на обслуживание и увеличению усилий, необходимых для исправления ошибок.

В документальном фильме PBS « Триумф ботаников» исполнительный директор Microsoft Стив Баллмер раскритиковал использование подсчета строк кода:

В IBM существует религия в программном обеспечении, которая гласит, что нужно считать K-LOC, а K-LOC - это тысяча строк кода. Насколько велик проект? О, это своего рода проект 10K-LOC. Это 20K-LOCer. А это 50K-LOC. И IBM хотела сделать религию в отношении того, как нам платят. Сколько денег мы заработали на OS / 2 , сколько они сделали. Сколько K-LOC вы сделали? И мы продолжали убеждать их - эй, если у нас есть - у разработчика есть хорошая идея, и он может что-то сделать в 4K-LOC вместо 20K-LOC, должны ли мы зарабатывать меньше денег? Потому что он сделал что-то меньшее и быстрое, без K-LOC. K-LOCs, K-LOCs, это методология. Фу! В любом случае, от этой мысли у меня всегда морщится спина.

Связанные термины [ править ]

  • KLOC / к eɪ л ɒ к / KAY -lok : 1000 строк кода
    • KDLOC: 1000 доставленных строк кода
    • KSLOC: 1000 строк исходного кода
  • MLOC: 1000000 строк кода
  • GLOC: 1000000000 строк кода

См. Также [ править ]

  • Оценка усилий по разработке программного обеспечения
  • Оценка (управление проектом)
  • Оценка затрат в программной инженерии

Заметки [ править ]

  1. ^ Возможно, включая весь пакет iLife, а не только операционную систему и обычно связанные приложения.

Ссылки [ править ]

  1. ^ Ву Нгуен; София Дидс-Рубин; Томас Тан; Барри Бем (2007), Стандарт подсчета SLOC (PDF) , Центр системной и программной инженерии, Университет Южной Калифорнии
  2. ^ IFPUG «Количественная оценка преимуществ использования функциональных точек»
  3. ^ a b c d e f "Сколько строк кода в Windows?" ( Научный поиск ) . Зная .NET. 6 декабря 2005 . Проверено 30 августа 2010 .
    Это, в свою очередь, цитирует The Build Master Винсента Марайи в качестве источника информации.
  4. ^ "Сколько строк кода в Windows XP?" . Microsoft. 11 января 2011 г.
  5. ^ «История Windows» . Microsoft.
  6. ^ a b Дэвид А. Уиллер (30 июня 2001 г.). «Больше, чем гигабак: оценка размера GNU / Linux» .
  7. ↑ Гонсалес-Бараона, Хесус М., Мигель А. Ортуньо Перес, Педро де лас Эрас Кирос, Хосе Сентено Гонсалес и Висенте Мателлан Оливера. «Подсчет картошки: размер Debian 2.2» . debian.org . Архивировано из оригинала на 2008-05-03 . Проверено 12 августа 2003 .CS1 maint: несколько имен: список авторов ( ссылка )
  8. ^ a b c d e Роблес, Грегорио. «Подсчет Debian» . Архивировано из оригинала на 2013-03-14 . Проверено 16 февраля 2007 .
  9. ^ Debian 7.0 был выпущен в мае 2013 года. Это приблизительное число, опубликованное 13 февраля 2012 года с использованием базы кода, которая впоследствии станет Debian 7.0, с использованием того же программного метода, что и для данных, опубликованных Дэвидом А. Уилером. Джеймс Бромбергер. «Debian Wheezy: 19 миллиардов долларов. Ваша цена… БЕСПЛАТНО!» . Архивировано из оригинала на 2014-02-23 . Проверено 7 февраля 2014 .
  10. ↑ Джобс, Стив (август 2006 г.). «Прямой эфир с WWDC 2006: основной доклад Стива Джобса» . Проверено 16 февраля 2007 . 86 миллионов строк исходного кода, который был перенесен для работы на совершенно новой архитектуре без сбоев.
  11. ^ «Что нового в Linux 2.6.32» . Архивировано 19 декабря 2013 года . Проверено 24 декабря 2009 .CS1 maint: bot: исходный статус URL неизвестен ( ссылка )
  12. ^ Greg Kroah-Хартман; Джонатан Корбет; Аманда Макферсон (апрель 2012 г.). «Разработка ядра Linux: как быстро она идет, кто это делает, что они делают и кто это спонсирует» . Фонд Linux . Проверено 10 апреля 2012 .
  13. ^ «Сводка, прогноз, статистика - The H Open: Новости и особенности» . Архивировано 19 декабря 2013 года . Проверено 8 октября 2012 .CS1 maint: bot: исходный статус URL неизвестен ( ссылка ). Проверено 13 мая 2014.
  14. ^ http://heise.de/-2730780
  15. ^ IFPUG "Краткая история метрик строк кода (loc)"

Дальнейшее чтение [ править ]

  • Ли, Ло; Хербслеб, Джим; Шоу, Мэри (май 2005). Прогнозирование количества дефектов в полевых условиях с использованием комбинированного подхода, основанного на времени и показателях, на примере OpenBSD (CMU-ISRI-05-125) . Университет Карнеги Меллон.
  • МакГроу, Гэри (март – апрель 2003 г.). «С нуля: семинар по безопасности программного обеспечения DIMACS» . Безопасность и конфиденциальность IEEE . 1 (2): 59–66. DOI : 10.1109 / MSECP.2003.1193213 .
  • Парк, Роберт Э .; и другие. «Измерение размера программного обеспечения: основа для подсчета исходных утверждений» . Технический отчет 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 .
  • Таненбаум, Эндрю С. Современные операционные системы (2-е изд.). Прентис Холл. ISBN 0-13-092641-8 . 
  • Ховард Дахда (24 января 2007 г.). «Таненбаум излагает свое видение ОС, защищенной от бабушек» . Архивировано из оригинала на 2007-01-27 . Проверено 29 января 2007 .
  • CM Lott: инструменты сбора метрик для исходного кода C и C ++
  • Folklore.org: Истории о Macintosh: 2000 строк кода