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

В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения ) Вводный раздел этой статьи может оказаться слишком коротким, чтобы адекватно изложить основные положения .Пожалуйста, рассмотрите возможность расширения лида, чтобы предоставить доступный обзор всех важных аспектов статьи. ( Апрель 2012 ) This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Source lines of code" – news · newspapers · books · scholar · JSTOR (February 2010) (Learn how and when to remove this message) This article may contain excessive or irrelevant examples. Please help improve the article by adding descriptive text and removing less pertinent examples. (May 2012) (Learn how and when to remove this message)

Исходные строки кода ( 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 ( i = 0 ; i < 100 ; i ++ ) printf ( "hello" ); /* Сколько здесь строк кода? */         

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

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

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

/* Сколько же здесь строк кода? */ for ( i = 0 ; i < 100 ; i ++ ) { printf ( "hello" ); }        

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

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

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

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

This article contains weasel words: vague phrasing that often accompanies biased or unverifiable information. Such statements should be clarified or removed. (September 2013)

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

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

ПЕЧАТЬ "привет, мир" 

#include <stdio.h> int main () { printf ( "привет, мир \n " ); }   

 идентификация разделение . идентификатор-программы . привет . процедура разделение . отображение "привет, мир" вернуться . конец программы привет .            

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

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

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

Дэвид А. Уилер изучил дистрибутив операционной системы Linux Red Hat и сообщил, что версия 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 год ^[update]новейший выпуск будет включать более 213 миллионов SLOC.

This section possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed. (April 2011) (Learn how and when to remove this message)

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

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

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

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

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

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

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

• Ли, Луо; Хербслеб, Джим; Шоу, Мэри (май 2005 г.). Прогнозирование частоты дефектов на местах с использованием комбинированного подхода на основе времени и метрик: пример OpenBSD (CMU-ISRI-05-125). Университет Карнеги-Меллона.
• Макгроу, Гэри (март–апрель 2003 г.). «From the Ground Up: The DIMACS Software Security Workshop». IEEE Security & Privacy . 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 г.
• Таненбаум, Эндрю С. Современные операционные системы (2-е изд.). Prentice Hall. ISBN 0-13-092641-8 . 
• Howard Dahdah (2007-01-24). "Tanenbaum излагает свое видение ОС, защищенной от бабушек". Архивировано из оригинала 2007-01-27 . Получено 2007-01-29 .
• CM Lott. "Инструменты сбора метрик для исходного кода C и C++". Архивировано из оригинала 19 июня 2020 г.
• Folklore.org: Истории Macintosh: -2000 строк кода