Что такое строка кода?

Ответ 1

Нет, стандартного соглашения нет, и каждый инструмент, который их учитывает, будет немного отличаться.

Это может заставить вас спросить: "Почему же я буду использовать LOC как показатель производительности?" и ответ заключается в том, что на самом деле не имеет значения, как вы считаете строку кода, пока вы рассчитываете их последовательно, вы можете получить представление об общем размере проекта по отношению к другим.

Ответ 2

Посмотрите статью Википедии, особенно " Измерение SLOC ":

Существует два основных типа SLOC меры: физический SLOC и логический SLOC. Конкретные определения этих две меры различаются, но наиболее распространенные определение физического SLOC - это счетчик строк в тексте программы исходный код, включая строки комментариев. Пустые строки также включены, если только строки кода в разделе состоит из более чем 25% пустых строк. В этом случае пустые строки, превышающие 25% не учитываются в код.

Логические меры 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 (для оператора statement и printf)
• 1 строка комментариев

[...]

Ответ 3

Я бы сказал

• количество комментариев
• количество пустых строк, потому что они важны для удобочитаемости, но не более одного смежных
• строки с подсчетом скобок тоже, но применяйте то же правило, что и для пустых строк - т.е. 5 вложенных фигурных скобок без кода между ними считаются одной строкой.

Я также смиренно предположил бы, что любая мера производительности, которая фактически полагается на значение LoC, является койкой:)

Ответ 4

В любой день, когда я могу закончить с меньшим количеством строк кода, но столько или больше функциональных возможностей... это хороший день. Возможность удалять сотни строк кода и заканчивать тем, что так же функционально и удобнее, это замечательная вещь.

Если у вас есть очень строгие правила кодирования в вашей команде, физические строки кода являются бесполезной статистикой. Логические строки кода по-прежнему бесполезны, но, как минимум, это не опасно вводить в заблуждение.

Ответ 5

Какой бы "wc -l" не возвращался, это мой номер.

Ответ 6

Если вы используете LOC в качестве показателя производительности, вы внезапно обнаружите, что ваши программисты пишут гораздо более подробно для "игры в систему". Это глупая мера, и только глупые люди используют ее для чего-то большего, чем хвастовство.

Ответ 7

"Строки кода" должны включать все, что вам нужно поддерживать. Это включает комментарии, но исключает пробелы.

Если вы используете это как показатель производительности, убедитесь, что вы делаете разумные сравнения. Строка С++ не совпадает с строкой Ruby.

Ответ 8

1 строка = 4 секунды чтения. Если потребуется больше, чтобы понять, что я говорю по этой строке, линия слишком длинная.

Ответ 9

LOC - это, как известно, неоднозначная метрика. Для подробного сравнения это применимо только при сравнении кода, написанного на том же языке, с тем же стилем, с той же командой.

Тем не менее, он дает понятие определенной сложности, когда рассматривается в порядке величины. Программа на 10000 строк намного сложнее, чем 100-строчная программа.

Преимущество LOC заключается в том, что wc -l возвращает его, и нет реальной фантазии, связанной с пониманием или вычислением, в отличие от многих других показателей программного обеспечения.

Ответ 10

Нет правильного ответа.

Для неофициальных оценок я использую wc -l.

Если мне нужно было что-то измерить строго, я бы измерил исполняемые утверждения. В основном, все с терминатором утверждения (обычно точкой с запятой) или заканчивается блоком. Для составных операторов я бы подсчитал каждое содержимое.

Итак:

int i = 7;                  # one statement terminator; one (1) statement
if (r == 9)                # count the if as one (1) statement
  output("Yes");      # one statement terminator; one (1) statement; total (2) for the if
while (n <= 14) {    # count the while as one (1) statement
  output("n = ", n);  # one statement terminator; one (1) statement
  do_something();   # one statement terminator; one (1) statement
  n++                       # count this one, one statement (1), even though it doesn't need a statement terminator in some languages
}                              # brace doesn't count; total (4) for the while

Если бы я делал это в Scheme или Lisp, я бы подсчитал выражения.

Как говорили другие, самое главное, чтобы ваш счет был последовательным. Это также важно, для чего вы это используете. Если вы просто хотите, чтобы потенциальный новый прокат знал, насколько велик ваш проект, используйте wc -l. Если вы хотите заниматься планированием и оценкой, то вы можете захотеть получить более формальный характер. Вы ни в коем случае не должны использовать LOC для компенсации базового программиста.

Ответ 11

Вы должны думать о "строках кода", а не о "строках кода".

Все должно быть как можно проще, поэтому создание положительного теста, основанного на количестве строк, - это поощрение плохого кода.

Кроме того, некоторые вещи, которые очень сложно в конечном итоге решаются с очень маленьким кодом, и некоторые вещи, которые очень легки (например, шаблонный код, например, геттеры и сеттеры), могут добавить много строк за очень короткое время.

Что касается исходного вопроса, если бы я собирался подсчитывать строки, я бы включил каждую строку, отличную от последовательных пустых строк. Я бы также добавил комментарии, так как они (надеюсь) полезная документация.

Ответ 12

Понятие LOC - попытка количественно определить объем кода. Как указано в других ответах, не имеет значения, что вы конкретно называете строкой кода, если вы согласны. Интуитивно кажется, что 10-строчная программа меньше 100-строчной программы, которая меньше, чем 1000-строчная программа и так далее. Вы ожидаете, что для создания, дебюта и поддержки 100-строчной программы потребуется меньше времени, чем 1000-строчная программа. Неформально, по крайней мере, вы можете использовать LOC, чтобы дать грубое ощущение объема работы, необходимой для создания, отладки и поддержки программы определенного размера.

Конечно, есть места, где это не задерживается. Например, сложный алгоритм, созданный в 1000 строк, может быть гораздо сложнее, чем, скажем, простая программа базы данных, которая потребляет 2500 строк.

Таким образом, LOC представляет собой крупномасштабную меру объема кода, которая позволяет менеджерам получить разумное представление о размере проблемы.

Ответ 13

• LOCphy: физически линии
• LOCbl: Бланклинк Комментирование событий, связанных с репутацией
• LOCpro: строки программирования (декларации, определения, директивы и код)
• LOCcom: строки комментариев

Многие доступные инструменты предоставляют информацию о процентах заполненных строк и т.д.

Вам просто нужно посмотреть на него, но не только рассчитывайте на него.

LOC растет в массовом порядке при запуске проекта и часто уменьшается после обзоров;)

Ответ 14

Я думаю об этом как о единственном обрабатываемом утверждении. Например

(1 строка)

Dim obj as Object

(5 строк)

If _amount > 0 Then
  _amount += 5
Else
  _amount -= 5
End If

Ответ 15

Я согласен с сообщениями, в которых говорится, что он известен многими способами и не является важной метрикой. Смотрите ever-hear-of-developers-getting-paid-per-line-of-code.

Ответ 16

Я согласен с принятым ответом Крейга Х, однако я хотел бы добавить, что в школе мне учили, что пробелы, комментарии и декларации не следует считать "строками кода" с точки зрения измерения строки кода, создаваемые программистом для повышения производительности, т.е. правило "15 строк в день".

Ответ 17

Я использую wc -l для быстрой оценки сложности рабочего пространства. Однако, как показатель производительности LOC THE WORST. Обычно я считаю это очень продуктивным днем, если мой счетчик LOC идет вниз.

Ответ 18

Я знаю, что некоторые люди используют LoC как показатель производительности

Не могли бы вы рассказать мне, кто они, поэтому я случайно не работаю с ними (или даже хуже)?

Если я могу реализовать в 1400 строк с помощью Haskell, что я мог бы реализовать в 2800 строк с использованием C, я более продуктивен в C или Haskell? Что займет больше времени? Что будет иметь больше ошибок (подсказка: она линейна в подсчете LOC)?

Стоимость программного обеспечения зависит от того, насколько изменяется его код (в том числе от или до пустой строки), увеличивая число в нижней строке. Я не знаю, как правильно измерить или приблизиться. Но я знаю, что любая разумно измеримая метрика может быть решена и не отражает то, что вы действительно хотите. Поэтому не используйте его.

Как вы считаете, как вы считаете LOC? Простой, используйте wc -l. Почему это правильный инструмент? Ну, вы, вероятно, не заботитесь о каком-то конкретном номере, но об общих общих тенденциях (вверх или вниз и о том, сколько), об отдельных тенденциях (движение вверх или вниз, изменение направления, как быстро,...) и о почти ничего, кроме числа 82 763.

Различия между мерами инструмента, вероятно, не интересны. Если у вас нет доказательств того, что число, выплеснутое вашим инструментом (и только этим инструментом), коррелирует с чем-то интересным, используйте его как приблизительную цифру шара; ничего, кроме монотонности, следует принимать не только с зерном, но и с ведром соли.

Укажите количество раз '\n'. Другими интересными персонажами могут быть ';', '{' и '/'.

Ответ 19

В мире .NET существует глобальное соглашение о том, что строка кода (LoC) является точкой последовательности отладки. Точка последовательности - это единица отладки, это часть кода, выделенная темно-красным цветом при помещении точки останова. С точкой последовательности мы можем поговорить о логической LoC, и эту метрику можно сравнить на разных языках .NET. Логическая метрика LoC-кода поддерживается большинством инструментов .NET, включая метрику кода VisualStudio, NDepend или NCover.

A 8 Метод LoC (начальная и конечная точки последовательности скобок не учитываются):

В отличие от физического LoC (что означает просто подсчет количества строк в исходном файле), логический LoC имеет огромное преимущество не зависящее от стиля кодирования. Стиль кодирования, мы все согласны с этим, может сделать физический подсчет LoC, изменяющийся от порядка одного разработчика к другому. Я написал более подробное сообщение в блоге по теме: Как вы рассчитываете количество строк кода (LOC)?

Ответ 20

Использование LOC для измерения производительности программистов похоже на оценку качества изображения по его размеру. LOC только "ценность", насколько мне известно, заключается в том, чтобы произвести впечатление на ваших клиентов и напугать конкурентов.

Тем не менее, я думаю, что количество скомпилированных инструкций будет наименее двусмысленным. Тем не менее, у плохих программистов есть преимущество в том, что они склонны писать излишне подробный код. Я помню, как однажды заменил 800 строк действительно плохого кода на 28 строк. Это делает меня бездельником?

Любой руководитель проекта, который использует LOC в качестве основного показателя производительности, является идиотом, который заслуживает плохих программистов.