Строки исходного кода (SLOC ), также известные как строки код (LOC ) - это метрика программного обеспечения, используемая для измерения размера компьютерной программы путем подсчета количества строк в тексте исходный код программы . SLOC обычно используется для прогнозирования объема усилий, которые потребуются для разработки программы, а также для оценки продуктивности программирования или ремонтопригодности после создания программного обеспечения.
Многие полезные сравнения включают только порядок величины строк кода в проекте. Использование строк кода для сравнения проекта из 10 000 строк и проекта из 100 000 строк намного полезнее, чем при сравнении проекта из 20 000 строк и проекта из 21 000 строк. Хотя вопрос о том, как именно измерять строки кода, является спорным, расхождения порядка величины могут быть четкими индикаторами сложности программного обеспечения или человеко-часов.
Существует два основных типа показателей SLOC: физический SLOC (LOC) и логический SLOC (LLOC). Конкретные определения этих двух показателей различаются, но наиболее распространенное определение физического SLOC - это количество строк в тексте исходного кода программы, исключая строки комментариев.
Логический SLOC пытается измерить количество исполняемых "операторов" ", но их конкретные определения привязаны к конкретным компьютерным языкам (одна простая логическая мера SLOC для C -подобных языков программирования - это количество точек с запятой в конце оператора). Намного проще создавать инструменты для измерения физического SLOC, а определения физических SLOC легче объяснить. Однако физические показатели SLOC чувствительны к логически несущественным соглашениям о форматировании и стилях, в то время как логический SLOC менее чувствителен к соглашениям о форматировании и стилях. Однако меры SLOC часто указываются без их определения, и логический SLOC часто может значительно отличаться от физического SLOC.
Рассмотрим этот фрагмент кода C как пример неоднозначности, возникающей при определении SLOC:
for (i = 0; i < 100; i++) printf("hello"); /* How many lines of code is this? */
В этом примере мы имеем:
В зависимости от программиста и стандартов кодирования, указанная выше «строка кода» может быть записана на многих отдельных строках:
/ * Теперь, сколько это строк кода? * / For (i = 0; i < 100; i++) { printf("hello"); }
В этом примере мы имеем:
Даже «логические» и «физические» значения SLOC могут иметь большое количество различных определений. Роберт Э. Парк (находясь в Институте программной инженерии ) и другие разработали фреймворк для определения значений SLOC, чтобы люди могли подробно объяснить и определить меру SLOC, используемую в проекте. Например, большинство программных систем повторно используют код, и определение того, какой (если есть) повторно используемый код включить, важно при составлении отчета о показателе.
В то время, когда люди начали использовать SLOC в качестве метрики, наиболее часто используемые языки, такие как FORTRAN и язык ассемблера, были строчно-ориентированными языками. Эти языки были разработаны в то время, когда перфокарты были основной формой ввода данных для программирования. Одна перфокарта обычно представляет собой одну строку кода. Это был один дискретный объект, который легко пересчитать. Это был видимый результат работы программиста, поэтому менеджерам было разумно считать строки кода мерой производительности программиста, даже имея в виду такие, как «изображения карточек ». Сегодня наиболее часто используемые компьютерные языки предоставляют гораздо больше возможностей для форматирования. Текстовые строки больше не ограничены 80 или 96 столбцами, и одна строка текста больше не обязательно соответствует одной строке кода.
Меры SLOC несколько спорны, особенно в том смысле, что они иногда используются не по назначению. Эксперименты неоднократно подтверждали, что усилия сильно коррелируют с SLOC, то есть программы с более высокими значениями SLOC требуют больше времени для разработки. Таким образом, SLOC может быть эффективным при оценке усилий. Однако функциональность хуже коррелирует с SLOC: опытные разработчики могут разработать ту же функциональность с гораздо меньшим количеством кода, поэтому одна программа с меньшим количеством SLOC может демонстрировать больше функциональности, чем другая аналогичная программа. Подсчет SLOC как показателя производительности имеет свои недостатки, поскольку разработчик может разработать только несколько строк и при этом быть гораздо более продуктивным с точки зрения функциональности, чем разработчик, который в конечном итоге создает больше строк (и обычно затрачивает больше усилий). Хорошие разработчики могут объединить несколько модулей кода в один модуль, улучшая систему, но при этом снижая производительность, поскольку они удаляют код. Кроме того, неопытные разработчики часто прибегают к дублированию кода, что крайне не рекомендуется, поскольку оно более подвержено ошибкам и требует больших затрат на обслуживание, но приводит к более высокому SLOC.
Подсчет SLOC вызывает дополнительные проблемы с точностью при сравнении программ, написанных на разных языках, если не применяются поправочные коэффициенты для нормализации языков. Различные компьютерные языки по-разному уравновешивают краткость и ясность; В качестве крайнего примера, большинству языков ассемблера потребовались бы сотни строк кода для выполнения той же задачи, что и несколько символов в APL. В следующем примере показано сравнение программы «hello world», написанной на C, и той же программы, написанной на COBOL - языке, который известен своей особенно многословностью..
C | COBOL |
---|---|
# include | идентификационный отдел. идентификатор программы. Здравствуйте. процедурное деление. отобразить "привет, мир" вернуться. конец программы привет. |
Строки кода: 4. (без пробелов) | Строки кода: 6. (без пробелов) |
Другой все более распространенной проблемой при сравнении показателей SLOC является разница между автоматическими сгенерированный и рукописный код. Современные программные инструменты часто имеют возможность автоматически генерировать огромные объемы кода с помощью нескольких щелчков мыши. Например, построители графического интерфейса пользователя автоматически генерируют весь исходный код для графических элементов управления, просто перетаскивая значок в рабочее пространство. Работа, связанная с созданием этого кода, не может разумно сравниваться с работой, необходимой, например, для написания драйвера устройства. Точно так же созданный вручную пользовательский класс GUI может быть более требовательным, чем простой драйвер устройства; отсюда и недостаток этой метрики.
Существует несколько моделей оценки затрат, расписания и трудозатрат, которые используют SLOC в качестве входного параметра, включая широко используемую серию моделей Конструктивной модели затрат (COCOMO ) от Барри Боэма. и др., PRICE Systems и SEER-SEM Галората. Несмотря на то, что эти модели продемонстрировали хорошую предсказательную силу, они хороши ровно настолько, насколько хороши оценки (в частности, оценки SLOC), предоставленные им. Многие выступали за использование функциональных точек вместо SLOC в качестве меры функциональности, но, поскольку функциональные точки сильно коррелированы с SLOC (и не могут быть измерены автоматически), это не универсальная точка зрения.
По словам Винсента Мараиа, значения SLOC для различных операционных систем в линейке продуктов Microsoft Windows NT следующие:
Год | Операционная система | SLOC (млн) |
---|---|---|
1993 | Windows NT 3.1 | 4–5 |
1994 | Windows NT 3.5 | 7–8 |
1996 | Windows NT 4.0 | 11–12 |
2000 | Windows 2000 | более 29 |
2001 | Windows XP | 45 |
2003 | Windows Server 2003 | 50 |
Дэвид А. Уилер изучил Red Hat дистрибутив операционной системы Linux и сообщил, что Red Hat Linux версии 7.1 (выпущенной в апреле 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.2 | 55–59 |
2002 | Debian 3.0 | 104 |
2005 | Debian 3.1 | 215 |
2007 | Debian 4.0 | 283 |
2009 | Debian 5.0 | 324 |
2012 | Debian 7.0 | 419 |
2009 | OpenSolaris | 9.7 |
FreeBSD | 8.8 | |
2005 | Mac OS X 10.4 | 86 |
1991 | ядро Linux 0,01 | 0,010239 |
2001 | Linux ядро 2.4.2 | 2.4 |
2003 | ядро Linux 2.6.0 | 5.2 |
2009 | ядро Linux 2.6. 29 | 11.0 |
2009 | ядро Linux 2.6.32 | 12.6 |
2010 | ядро Linux 2.6.35 | 13,5 |
2012 | Ядро Linux 3,6 | 15,9 |
2015-06-30 | Ядро Linux до 4.2 | 20,2 |
В документальном фильме PBS Triumph of the Nerds руководитель 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, это методология. Ух! В любом случае, от этой мысли у меня всегда морщится спина.