Исходные строки кода

Исходные строки кода ( 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? */

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

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

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

/* Now how many lines of code is this? */
for (i = 0; i < 100; i++)
{
    printf("hello");
}

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

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

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

Происхождение

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

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

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

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

БАЗОВЫЙ	С	КОБОЛ
PRINT "hello, world"	#include <stdio.h> int main() { printf("hello, world\n"); }	identification division. program-id. hello . procedure division. display "hello, world" goback . end program hello .
Строки кода: 1 (без пробелов)	Строки кода: 4 (исключая пробелы)	Строки кода: 6 (исключая пробелы)

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

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

Пример

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

Год	Операционная система	СЛОК (млн)
1993	Windows НТ 3.1	4–5
1994	Windows НТ 3.5	7–8
1996	Windows НТ 4.0	11–12
2000	Windows 2000	более 29
2001	Windows ХР	45
2003	Windows Сервер 2003	50

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

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

Год	Операционная система	СЛОК (млн)
2000	Дебиан 2.2	55–59
2002	Дебиан 3.0	104
2005	Дебиан 3.1	215
2007	Дебиан 4.0	283
2009	Дебиан 5.0	324
2012	Дебиан 7.0	419
2009	OpenSolaris	9.7
	FreeBSD	8.8
2005	Мак ОС Х 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

Утилита

Преимущества

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

Недостатки

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

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

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

По данным Музея компьютерной истории, разработчик Apple Билл Аткинсон в 1982 году обнаружил проблемы с этой практикой:

Когда в 1982 году команда Lisa приступила к завершению разработки своего программного обеспечения, менеджеры проектов начали требовать от программистов еженедельной отправки форм с отчетами о количестве строк кода, которые они написали. Билл Аткинсон посчитал это глупостью. В течение недели, когда он переписал процедуры расчета регионов QuickDraw, чтобы они стали в шесть раз быстрее и на 2000 строк короче, он поставил в форме «-2000». Еще через несколько недель менеджеры перестали просить его заполнить форму, и он с радостью подчинился.

См. также

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

Дальнейшее чтение

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