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

посмотреть Статья В Википедии, особенно "измерение SLOC" раздел:

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

логические меры SLOC пытаются измерить количество "заявлений", однако определения привязан к определенным компьютерным языкам (одна простая логическая мера SLOC для C-подобные языки программирования номер заявления-завершение запятые.) Это намного проще создание инструментов для измерения физического SLOC, и физическое Количество строк определений легче объяснить. Однако, физические меры SLOC чувствительны к логически нерелевантному форматированию и соглашения стилей, в то время как логический SLOC менее чувствителен к форматированию и условности стиля. К сожалению, SLOC меры часто без давая их определение, и логически SLOC часто может быть значительно отличается от физического SLOC.

рассмотрим этот фрагмент кода C как пример возникшей двусмысленности когда определить количество строк:

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

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

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

[...]

Я бы сказал

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

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

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

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

любой" wc-l " возвращает мой номер.

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

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

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

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

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

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

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

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

для неофициальных оценок я использую 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 для компенсации базового программиста.

вы должны думать о " строках кода потратил", не "строки кода произведено".

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

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

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

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

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

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

1. LOCphy: физически строк
2. LOCbl: пустые строки Kommentarblocks werden als Kommentarzeile gezählt
3. LOCpro: строки программирования (объявления, определения, директивы и код)
4. LOCcom: строки комментариев

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

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

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

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

(1 линия)

Dim obj as Object

(5 линий)

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

Я согласен с сообщениями, которые говорят, что это сообщается многими способами и не является важной метрикой. Смотрите это постоянно слышу от разработчиков-получение оплаты за строчек кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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