Насколько плох SLOC (исходные строки кода) как метрика?

Ответ 1

Кто-то сказал:

"Использование SLOC для измерения прогресса программного обеспечения похоже на использование кг для измерения прогресса в производстве самолетов"

Это совершенно неуместно, поскольку оно поощряет плохие практики, такие как:

• Copy-Paste-синдром

• препятствовать рефакторингу, чтобы облегчить ситуацию

• Наполнение бессмысленными комментариями

• ...

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

Ответ 2

Проблема с SLOC заключается в том, что это простая метрика для игры. Быть продуктивным не означает получение большего количества кода. Так, как я объяснил это людям, запрещающим то, что сказал Skilldrick, это:

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

Меньший код → легче понять → дешевле добавить новые функции

Bean счетчики могут понять это.

Ответ 3

Покажите им разницу между:

for(int i = 0; i < 10; i++) {
    print i;
}

и

print 0;
print 1;
print 2;
...
print 9

И спросите их, лучше ли 10 SLOC или 3 SLOC.

В ответ на комментарии:

• Не требуется много времени, чтобы объяснить, как работает цикл for.

• После того, как вы их покажете, скажите: "Теперь нам нужно печатать цифры до 100 - здесь, как вы делаете это изменение". и покажите, сколько времени потребуется, чтобы изменить код, не содержащий DRY.

Ответ 4

Ответ 5

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

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

Длина кода является жизнеспособной мерой балласта.

Количество строк кода без комментариев коррелирует с:

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

и многие другие подобные виды затрат, такие как стоимость оптимизации.

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

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

Ответ 6

Довольно плохо (-:

Гораздо лучшая идея будет охватывать тестовые примеры, а не код.

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

Как бонус собирает статистику охвата (охват веток лучше, чем покрытие линии здесь).

Ответ 7

Объясните, что SLOC - отличное измерение строк кода в приложении, ничего больше.

Количество строк в книге или длина фильма "Определите, насколько это хорошо. Вы можете улучшить фильм и сократить его, вы можете улучшить приложение и сократить количество строк кода.

Ответ 8

Вы не судите о том, насколько хороши (сколько функций, как это работает). Самолет основан на его весе (sloc).

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

Ответ 9

Почему SLOC плохой как индивидуальный показатель производительности

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

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

Как SLOC может использоваться в ваших интересах

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

Ответ 10

даже современные инструменты метрики кода критикуют SLOC conting, мне нравится точка, заданная в FAQ ProjectCodeMeter:

Что не так с подсчетом строк кода (SLOC/LLOC)?

Ответ 11

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

Но количество SLOC должно анализироваться только ПОСЛЕ других подходящих показателей качества кода. Так что...

• НЕ записывайте 2 строки кода, когда 1 будет делать, если 2-строчная версия делает код в 2 раза проще в обслуживании.
• НЕ пушите код с ненужными комментариями только для распутывания SLOC.
• НЕ платите людям по количеству SLOC.

Я управляю программными проектами уже 30 лет. Я использую подсчет SLOC все время, чтобы помочь понять зрелые системы. Я никогда не считал полезным даже взглянуть на подсчет SLOC, пока проект не будет близок к выпуску версии 1.0.

В принципе, в процессе разработки я беспокоюсь о качестве, производительности, удобстве использования и соответствии спецификациям. Получите это правильно, и проект, вероятно, будет успешным. Когда пыль оседает, посмотрите на количество SLOC. Вы можете быть удивлены тем, что вы получили SO из 5000 строк кода. И вы можете быть удивлены, что у вас так мало! (Но количество SLOC не влияет на качество, производительность, удобство использования и соответствие спецификации.)

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

Cheers, Дядя Чип

Ответ 12

SLOC можно резко изменить, добавив лишние пустые строки ( "для удобочитаемости" ) или путем помещения или удаления комментариев. Поэтому использование SLOC может привести к путанице.

Ответ 13

Почему они не понимают, что SLOC не изменился, но программное обеспечение делает больше, чем вчера, потому что вы добавили новые функции или исправили ошибки?

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

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

Go прочитайте это:

https://stackoverflow.com/info/3800707/what-is-negative-code