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

голоса
12

Я понимаю, что там нет определенно «правильный» ответ на этот вопрос, но когда люди говорят о строк кода, что они означают? В C ++, например, вы подсчитывать пустые строки? Комментарии? линии с только открытой или закрывающей фигурной скобкой?

Я знаю, что некоторые люди используют LoC в качестве меры производительности, и мне интересно, если есть стандартная конвенция здесь. Кроме того, я думаю, что есть способ, чтобы получить различные компилятор подсчета строк коды - есть стандартная условность там?

Задан 09/12/2008 в 17:33
источник пользователем
На других языках...                            


20 ответов

голоса
22

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

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

Ответил 09/12/2008 в 17:38
источник пользователем

голоса
11

Посмотрите на статьи Википедии , особенно « Измерение 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 (для постановки и PRINTF заявления)
  • 1 комментарий Линия

[...]

Ответил 09/12/2008 в 17:40
источник пользователем

голоса
8

я бы сказал

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

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

Ответил 09/12/2008 в 17:37
источник пользователем

голоса
4

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

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

Ответил 09/12/2008 в 21:54
источник пользователем

голоса
3

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

Ответил 09/12/2008 в 17:50
источник пользователем

голоса
3

Безотносительно «туалет -l» возвращает мой номер.

Ответил 09/12/2008 в 17:36
источник пользователем

голоса
2

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

Ответил 09/12/2008 в 20:19
источник пользователем

голоса
2

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

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

Ответил 09/12/2008 в 17:42
источник пользователем

голоса
1

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

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

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

Ответил 09/12/2008 в 21:12
источник пользователем

голоса
1

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

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

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

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

Ответил 09/12/2008 в 18:25
источник пользователем

голоса
1

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

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

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

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

Ответил 09/12/2008 в 18:17
источник пользователем

голоса
1

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

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

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

Ответил 09/12/2008 в 17:52
источник пользователем

голоса
0

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

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

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

Ответил 02/09/2016 в 00:40
источник пользователем

голоса
0

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

Способ 8 КХ (начало и окончание точек последовательности скобки не учтены):

альтернативный текст

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

Ответил 12/12/2010 в 19:12
источник пользователем

голоса
0

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

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

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

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

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

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

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

Ответил 19/03/2009 в 23:15
источник пользователем

голоса
0

Я использую wc -lдля быстрой оценки сложности рабочей области. Тем не менее, в качестве метрики производительности ЛОК являются ХУДШЕЙ . Я вообще считаю , что очень продуктивный день , если мой если количество LOC идет вниз.

Ответил 22/12/2008 в 00:44
источник пользователем

голоса
0

Я согласен ж / принятый ответ Крейг H, однако я хотел бы добавить, что в школе меня учили, что пробельные, комментарии и заявления, не должны учитываться в качестве «строк кода» с точки зрения измерения строк кода производится программистом в целях повышения производительности - т.е. Ol»„15 линий за день“правила.

Ответил 09/12/2008 в 20:59
источник пользователем

голоса
0

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

Ответил 09/12/2008 в 20:09
источник пользователем

голоса
0

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

(1 линия)

Dim obj as Object

(5 линий)

If _amount > 0 Then
  _amount += 5
Else
  _amount -= 5
End If
Ответил 09/12/2008 в 17:39
источник пользователем

голоса
0
  1. LOCphy: физически линии
  2. LOCbl: Blanklines Kommentarblocks Werden ALS Kommentarzeile gezählt
  3. LOCpro: программирование линий (заявления, определение, директива и код)
  4. LOCcom: линии комментариев

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

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

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

Ответил 09/12/2008 в 17:38
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more