gifts2017

Подсчет строк кода

Опубликовал Антон Степанов (Stepa86) в раздел Программирование - Инструментарий

Количество строк кода (англ. Source Lines of Code — SLOC) — это метрика программного обеспечения, используемая для измерения его объёма с помощью подсчёта количества строк в тексте исходного кода. Как правило, этот показатель используется для прогноза трудозатрат на разработку конкретной программы, либо для оценки производительности труда уже после того, как она написана.

Подробнее о количестве строк кода

Простенькая обработка для подсчета строк в проекте. Специалист ее напишет за 10-30 минут максимум, но бывает что даже этого времени нет...

Для использования необходимо

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

2) Натравить на каталог эту обработку

Скачать файлы

Наименование Файл Версия Размер
Обработка 80
.epf 7,52Kb
20.09.16
80
.epf 7,52Kb Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Михаил Ражиков (tango) 19.01.10 10:37
автоматизация белой горячки, -
2. Андрей Вахрин (dolter) 19.01.10 10:42
старался человек, однако... оформил красиво... :-)
3. Антон Степанов (Stepa86) 19.01.10 10:42
(1) и где тут автоматизация? или ты считаешь, что совершенно не обязательно знать объем проекта???
5. Антон Степанов (Stepa86) 19.01.10 10:54
(4) вообще то не предполагалось привязывать количество строк кода к эффективности работы программистов, есть много примеров, когда один прогер одной строчкой сделал качественнее решение, чем второй 1000ей

и вообще: "Эксперименты многократно подтвердили тот факт, что данная метрика хорошо коррелирует с трудозатратами — программы с большим количеством строк кода требуют больше времени на разработку." из ссылки в топике
6. Михаил Ражиков (tango) 19.01.10 11:04
Разработчики очень сообразительны в этом отношении. Что бы вы ни пытались измерить, они найдут способ оптимизировать этот показатель, и вы никогда не получите именно то, чего пытаетесь добиться.

Роберт Остин (Robert Austin) в своей книге "Измерение и управление производительностью в организациях" (Measuring and Managing Performance in Organizations) пишет, что существует два этапа внедрения новой метрики для измерения производительности. Сначала вы получаете то, что хотели, потому что никто пока не понял, как обмануть систему. На втором этапе вы получаете нечто худшее, чем то, с чего начинали, потому что все будут обманывать систему, чтобы максимизировать измеряемый показатель, даже рискуя погубить компанию.

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

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

http://local.joelonsoftware.com/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4_%D1%8D%D0%BA%D0%BE%D­0%BD%D0%BE%D0%BC%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B9_%­D0%BC%D0%BE%D1%82%D0%B8%D0%B2%D0%B0%D1%86%D0%B8%D0%B8
7. Михаил Ражиков (tango) 19.01.10 11:16
(5)
"и вообще:"
http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BB%D0%B8%D1%87%D0%B5%D1%81%D1%82%D0­%B2%D0%BE_%D1%81%D1%82%D1%80%D0%BE%D0%BA_%D0%BA%D0%BE%D0%B4%­D0%B0
[источник не указан 243 дня]

"вообще то не предполагалось"
пачка перфокарт, составляющая программу, обладала вполне видимым объёмом, по которому менеджеры могли судить о производительности работы программистов
8. Антон Степанов (Stepa86) 19.01.10 11:25
(7) такое ощущение, что это Ваша больная тема... в общем спорить не буду, я создал простенький инструмент, мне он был полезен, решил поделится... пусть каждый сам решает как им пользоваться 8-)
9. Трактор Трактор (Трактор) 19.01.10 11:28
Слишком сложно. Меня как-то попросили посчитать количество строк кода в конфигурации. Я задал поиск во всех текстах точки с запятой. Через 15 минут дал ответ. Всё.

Кстати, в результате моей деятельности количество строк кода в конфигурации иногда уменьшается.
mtv:); Поручик; tango; +3 Ответить 2
10. Михаил Ражиков (tango) 19.01.10 11:45
(8) слив защитан. нелюбовь к тупому менеджменту - тяжелое наследие франчайзевой юности.
(9) +
11. Антон Степанов (Stepa86) 19.01.10 11:54
(9) еще раз говорю, это не оценка производительности программиста, а оценка проекта... Ничо, что точка с запятой далеко не в каждой строчке используется?
12. Трактор Трактор (Трактор) 19.01.10 12:12
(11) >> еще раз говорю, это не оценка производительности программиста, а оценка проекта.
Вот как раз и посчитали примерный размер проекта.

>> Ничо, что точка с запятой далеко не в каждой строчке используется?
В таком случае как ты отличаешь конструкцию
Если Петрович = Вор Тогда

СообщениеНачальству = "Петрович занимается приписьками и с этим ничего сделать не получится"

Иначе

СообщениеНачальству = "Петрович знатный работник"

КонецЕсли;
...Показать Скрыть

От кода
СообщениеНачальству = ?(Петрович = Вор, "Петрович занимается приписьками и с этим ничего сделать не получится", "Петрович знатный работник");

Подсчётом точек с запятой эти два фрагмента дадут один результат. Подсчётом количество строк ты в первом случае получишь 9 строк, а во втором одну строку. А функционально куски одинаковы.
Как мыслишь решать проблему? И надо ли её решать?

tango абсолютно прав говоря что подсчёт строк кода это очень условный показатель, который может сработать только раз.
Я подозреваю что 1Сники в типовых конфах специально вставляют пустые строки чтобы увеличить количество строк. Ибо читаемость кода от этого ухудшается.
13. Антон Степанов (Stepa86) 19.01.10 12:22
(12) в твоем примере в первом коде 0 точек с запятой, во втором 1, а, нет увидел... вот тока в первом фрагменте я б 3 точки с запятой поставил

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

если я буду планировать новый проект, то могу примерно оценить трудозатраты, оценив метрики предыдущих проектов. ни о каком показателе типа "ты написал в этом месяце меньше нормы на 100 строк, премию не получишь" речи тут не идет! Мне, например, просто нравится оценивать количество строк текущего проекта раз в месяц и сравнивать с другими моими проектами...
14. Трактор Трактор (Трактор) 19.01.10 12:31
(13) >> в твоем примере в первом коде 0 точек с запятой, во втором 1
В обоих по одной строке. В первом фрагменте точка с запятой стоит после КонецЕсли

>> Пустые строки очень хороший инструмент
Всё хорошее хорошо в меру, а не как в некоторых типовых конфах.

Однако любой метод даёт лишь приблизительное представление о сложности. Например алгоритм рисования круга в 10 строк в институте разбирается две пары. И это правильно.

Мы поняли друг друга и это хорошо.
Удачи ;-)
15. Михаил Ражиков (tango) 19.01.10 17:21
(13) "оценить трудозатраты"
ну дык...
Софтверные компании обычно премируют программистов которые (a) пишут много кода и (b) исправляют много багов. Лучший способ продвинуться в такой организации — это писать как можно больше неряшливого кода и потом исправлять все эти ошибки, вместо того, чтобы потратить время и в первую очередь подумать, как сделать грамотно. Если вы попробуете исправить эту проблему с помощью штрафа за баги, то вы создадите повод скрывать баги, или не говорить тестерам о только что написанном коде в надежде на то, что найденных багов будет меньше. Таким образом выиграть нельзя.

http://local.joelonsoftware.com/wiki/%D0%98%D0%B7%D0%BC%D0%B5%D1%80%D0%B5%D0%BD%D0%B8%D1­%8F_%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%B8%D0%B2%D­0%BD%D0%BE%D1%81%D1%82%D0%B8
16. Антон Степанов (Stepa86) 19.01.10 17:30
(15) опять про мотивацию и эффективность? Предлагаю Вам создать отдельную статью на тему противостояния менеджмента и простых программистов...
17. dushelov (Душелов) 19.01.10 20:59
А.... Тема про "индийский код"...
Ну-ну :)
18. Вячеслав Кадацкий (marsohod) 19.01.10 22:57
"Не бывает измерений никак не влияющих на измеряемую систему."
(с) Гейзенберг В.
:D это по поводу ссылки в (6)
19. Михаил Ражиков (tango) 20.01.10 09:24
нет, правда никак не въеду.
чел оценивает трудозатраты, но упорно отнекивается от оценки производительности...
Это как?
20. Виталий Евсеев (CrazyBear) 20.01.10 09:29
А можно добавить отбор по комментариям например "//+"?
21. Антон Степанов (Stepa86) 20.01.10 09:49
(19) глупо оценивать производительность по количеству кода, поэтому и отнекиваюсь, а в целом проект оценить можно...
22. Ivon (Ivon) 20.01.10 10:20
Я вообще считаю, что нельзя оценивать работу программиста по количеству строк кода. Это вредно для самой программы. Например, 1-й программист пишет код сразу после получения задания и выдает прогу в 1000 строк кода, который жутко не оптимизирован, при этом 2-й вначале хорошо подумает и осмыслит структуру программы и напишет 100 строк оптимизированного кода, при том, что программы будут выполнять одно и то же. Одна из моих программ в былое время претерпела 2 таких оптимизации, при этом стала быстрее работать, а количество строк кода уменьшилось раз в 15.
23. Алексей Ситников (SiAl) 20.01.10 10:34
Не вижу пользы. Но минус пока ставить не могу. Производительность мало связана с количеством кода. Например то, что например в семерке требовалось кодировать, то в восьмерке рализвано на уровне платформы, а в 8.2 и того более - "управляемое приложение". Кодирование идет на уровне глобальных процедур и функций, их можно "просчитать" и в Конфигураторе.
Если для групповой работы, то обычно за свою подсистему - отдельный спец отвечает. Как эта обработка отслеживает подсистемы?
24. Антон Степанов (Stepa86) 20.01.10 10:39
(23) на вторую картинку внимательно посмотри
25. Алексей Ситников (SiAl) 20.01.10 11:12
(24) Да ну. Может стоит тогда выгружать всё, а в таблице группировать количество строк по подсистемам. Но, повторюсь, что количество строк для писателей - оценка их труда, но никак не программистов. Внедренец вообще может не менять код, а результат - есть: довольный клиент.
26. Антон Степанов (Stepa86) 20.01.10 11:27
(25) не вижу смысла потратить кучу времени на бесполезные фишечки, которые и так легко обходятся.

Нужно было подсчитать колво строк в проекте, я написал инструмент за 15 минут, выложил его для тех, кому он может быть пригодится, а тут срач начался по поводу производительности и эффективности...
27. Андрей (Asis) 20.01.10 11:31
Хорошо бы еще задавать параметры типа "учитывать пустые строки" и т.п.
28. Алексей Ситников (SiAl) 20.01.10 11:51
(26) Конструктивней надо быть. В каждом сраче выкристализовывается много новых идей.
29. Владимир (vovan519) 20.01.10 12:28
Не понимаю, зачем нападать на автора. Он несколько раз сказал, что это подсчет строчек кода, а не расчет производительности.
Кстати, так же глупо измерять производительность в потраченном времени. По тем же причинам (возможность влиять на показатели). Но большинство ежедневно совершают эту глупость.
Оценивать трудозатраты можно по разному. Могу предложить десяток вариантов. Для кого может такой оценкой является количество выкуренных сигарет. Но это не важно.
Если программист запланировал получить за выполненную работу N рублей, он постарается ее получить. В свою очередь работодатель хочет заплатить не больше M рублей. Если N <> M люди торгуются, вот и вся хитрость.
Но есть несколько "но".
1) И тому и другому необходима начальная сумма от которой нужно начать торговаться.
2) Работодатель хочет знать порядок сумм (т.е количество ноликов) при расчете до начала работы.
Не хочу описывать все "но", только во всех случаях нужна, пусть косвенная, пусть не точная, но оценка. Большинство из вас имеет образование связанное с математикой. Есть куча мат. методов где результат получается рекурсивными методами, постоянно уменьшая погрешность. Так считайте "количество строк кода", "количество часов" или "количество выкуренных сигарет" первым приближением этой задачи. Это первое приближение может изменится в результате как в одну, так и в другую сторону. Но это уже отдельный разговор.
Anything; Stepa86; +2 Ответить
30. Александр Зубцов (iov) 20.01.10 12:50
Любопытно. ВОт интересный показатель. Подрабатываю фрилансом на Абоненской плате (определенное количество часов) так вот поставил условие что я не озвучиваю стоимость разработок но говору примерно сколько это часов (включая обучение нововведениям) А вот поддержка (исправления переписка и иное где мог ошибится - бесплатно) (изменение функционала по просьбе заказчика не в счет). Итак я теперь трачу больше времени но чем меньше я ошибаюсь и точнее и понятнее обучаю тем меньше трачу свое время. как результат могу просто приходить порой за оплатой. Мотивацией работы должно быть именно желание писать хороший код. В человеке заложено желание меньше работать и больше получать. А менеджеров учат добиваться обратного. НО формула КАЧЕСТВО = (ВРЕМЯ* УМЕНИЯ*МОТИВАЦИЯ)/затраты на исправление ошибок (*сильно упрощено) работает и мы можем лишь изменять некоторые показатели замещать другими но результат один.
Пример наш любимый apple (традиционное качество) НО ка только попадается партия хреново зделанного рейтинг (читай качество) резко падает потому как востановление репутации - ремонт- отзыв продукции
это огромные вложения.
С другой стороны АК (автомат калашникова ну извините очень яркий пример) выносливость и простота даже с учетом хреновой точности за счет потраченного на разработку времени и знаний и умений конструктора + мотивация (патриотизм тоже мотивация- это для новейшего поколения которое в мотивациях ограничено) = очень качественный массовый продукт.
Bublik2011; +1 Ответить 1
31. Антон Степанов (Stepa86) 20.01.10 13:01
(30) Макконел примерно то же самое сказал
32. Александр Зубцов (iov) 20.01.10 15:33
(31) Не читал чесно говоря. Но почитаем, мысли человека который придерживается той же точки зрения могут укрепить уверенность и раздуть самомнение :D .
А на самом деле вопрос программирования все таки в случаях с разработкой качественых программ должен относится к сфере творчества а не к сфере производства (ну покрайней мере для программиста).
33. sash-ml (sash-ml) 22.01.10 19:24
С 1С-ке может это и "показатель" крутости, но вот в однокристальных микропроцессорах всего 64Кб памяти под программу(если повезет), и нужно очень оптимальные алгоритмы писать дабы поместится в это ограничение.
34. Кирилл Шабалин (crs) 17.01.13 20:28
Подсчитайте кто-нибудь кол-во строк в типовых конфигах. Интересно)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа