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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

Answer 7

1. LOCphy: физически линии
2. LOCbl: Пробелы в комментариях
3. LOCpro: строки программирования (объявления, определения, директивы и код)
4. LOCcom: строк комментариев

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

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

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

Answer 8

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

Answer 9

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

(1 строка)

Dim obj as Object

(5 строк)

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

Answer 10

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