The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Анализ степени дублирования кода на GitHub"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Анализ степени дублирования кода на GitHub"  +/
Сообщение от opennews (??), 20-Ноя-17, 21:53 
Представлены (https://blog.acolyer.org/2017/11/20/dejavu-a-map-of-code-dup.../) результаты (https://dl.acm.org/ft_gateway.cfm?id=3133908&ftid=1914259&dw...) изучения дублирования кода в общем объёме исходных текстов, размещённых на GitHub. Проанализировано (http://mondego.ics.uci.edu/projects/dejavu/) 4.5 млн различных проектов (без форков репозиториев), включающих более 428 млн файлов с кодом на языках  Java, C++, Python и JavaScript. Из этих файлов лишь 85 млн оказались уникальными, т.е. 80% кода на GitHub являются копиями других файлов.


Определение дубликатов выполнялось несколькими методами: путём сравнения хэшей файлов (полные копии), хэшей сгруппированного набора токенов из файла (не учитывает форматирование и комментарии) и оценки частичного заимствования кода при помощи SourcererCC (https://github.com/Mondego/SourcererCC) (определён отредактированный код с 80% общих токенов).


Наиболее часто дубликаты встречаются в коде на языке JavaScript, для которого лишь 6% файлов не совпадают (т.е. 94% файлов являются полными клонами 6% файлов), 5% не совпадают по хэшу набора токенов и 2% отличаются с учётом редактирования кода. Наименьшее число дубликатов выявлено для кода на языке Java, для которого не повторяется 60% файлов, 56% наборов токенов и 26% отличаются с учётом редактирования кода. Для C++ эти показатели составляют 27%, 23% и 10%, а для Python - 29%, 27% и 9%.


Наиболее часто повторяющимся стал пустой файл, размером 0 байт, который повторяется 2.2 млн раз. Игнорирование при проверке мелких файлов, в которых встречаются менее 50 токенов, почти не сказывается на уровне совпадений:

Распределение языков по уровню дублирования кода также сохраняется, если провести сравнению не на уровне файлов, а на уровне проектов. Например, около 15% проектов на JavaScript являются полными клонами других проектов, 31% проектов копируют более 80% кода из других проектов, а 48% копируют более 50% кода. Для Java эти показатели составляют 6%, 9% и 14%.


Попытки разобраться почему степень дублирования кода столь велика показали, что наиболее частой причиной появление дубликатов, является включение в репозитории проектов кода из сторонних библиотек и фреймворков, вместо подключения их как внешних зависимостей. Например, для JavaScript очень велика доля копий библиотек, распространяемых через NPM. Несмотря на то, что только 6% проектов включают каталог node_modules, 70% из всех дубликатов на JavaScript связаны с копированием модулей NPM.


В среднем в JavaScript-проект включается 63 зависимости, а уровень вложенности зависимостей составляет 5 (максимальное зафиксированное число зависимостей - 1261, уровень вложенности - 47). Кроме NPM-модулей достаточно часто в проект включается библиотека jQuery. В Java чаще остальные дублируются компоненты ActionBarSherlock и Cordova, в C/C++ - boost и freetype, в Python копирование распределено более равномерно по разнообразным библиотекам.


Совпадения на уровне изменённого кода (частичное совпадение) также чаще всего оказались вызванными использованием "копипастинга" или ненамеренным копированием кода и автогенерацией кода в процессе применения типовых фреймворков. Например, для Java чаще всего совпадения выявлялись в коде, сгенерированном при помощи Apache Axis, Android SDK и JAXB, для Python при помощи Django, а для JavaScript -  Angular.

y.

URL: https://blog.acolyer.org/2017/11/20/dejavu-a-map-of-code-dup.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=47596

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Анализ степени дублирования кода на GitHub"  +6 +/
Сообщение от Аноним (-), 20-Ноя-17, 21:53 
leftpad надублировали, небось.
Ответить | Правка | Наверх | Cообщить модератору

27. "Анализ степени дублирования кода на GitHub"  +3 +/
Сообщение от Green (??), 21-Ноя-17, 08:14 
Ага, послушали комментаторов на опеннете, которые осуждали подключение лефтпада как отдельного модуля, стали копипастить.
Ответить | Правка | Наверх | Cообщить модератору

29. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от Аноним (-), 21-Ноя-17, 08:39 
> В среднем в JavaScript-проект включается 63 зависимости

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

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "Анализ степени дублирования кода на GitHub"  +17 +/
Сообщение от Аноним (-), 20-Ноя-17, 22:18 
Да, npm это страшная вещь.

Как-то на досуге загрузил модуль ноды через npm, модуль 20-25 Кб.

Вы не поверите, npm зависимостей всосал где-то на 100 метров. Честное слово, я не вру, сам о*уел когда увидел.

Ответить | Правка | Наверх | Cообщить модератору

4. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от Moomintroll (ok), 20-Ноя-17, 22:24 
> Как-то на досуге загрузил модуль ноды через npm, модуль 20-25 Кб.
>
> Вы не поверите, npm зависимостей всосал где-то на 100 метров. Честное слово, я не вру, сам о*уел когда увидел.

Что тут удивительного, когда "В среднем ... уровень вложенности зависимостей составляет 5 ... максимальный уровень вложенности - 47"?

Ответить | Правка | Наверх | Cообщить модератору

6. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от Donald Trump aside of Yuri Bezmenov (?), 20-Ноя-17, 22:38 
>> Как-то на досуге загрузил модуль ноды через npm, модуль 20-25 Кб.
>>
>> Вы не поверите, npm зависимостей всосал где-то на 100 метров. Честное слово, я не вру, сам о*уел когда увидел.
> Что тут удивительного, когда "В среднем ... уровень вложенности зависимостей составляет
> 5 ... максимальный уровень вложенности - 47"?

derivative?

Ответить | Правка | Наверх | Cообщить модератору

8. "Анализ степени дублирования кода на GitHub"  –1 +/
Сообщение от Sw00p aka Jerom (?), 20-Ноя-17, 22:48 
Эт я думаю вы с каким нить флагом nodev устанавливали?

Пс: зовите Гугл на помощь пусть создадут лопаточку выручалочку для разгребания этой кучи

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

9. "Анализ степени дублирования кода на GitHub"  +3 +/
Сообщение от пох (?), 20-Ноя-17, 22:58 
тут не надо разгребать, тут другой случай, нокию вызывайте - чтоб закoпали поглубже. Особо опасный жабоскриптный мусор.

Ответить | Правка | Наверх | Cообщить модератору

12. "Анализ степени дублирования кода на GitHub"  +1 +/
Сообщение от Sw00p aka Jerom (?), 21-Ноя-17, 01:38 
а прикол весь в том, что ну придумают лопату, а куча то растёт, придумают экскаватор Отиса, чтоб з-а-к-о-п-а-т-ь потом по глубже

пс: ПРЕДУПРЕЖДЕНИЕ: В сообщении используется ненормативная лексика.  Выражение, на которое сработало предупреждение: 'з"а"к"о"п"а'. ППЦ админы.

Ответить | Правка | Наверх | Cообщить модератору

10. "Анализ степени дублирования кода на GitHub"  +1 +/
Сообщение от Аноним (-), 20-Ноя-17, 23:10 
> лопаточку выручалочку для разгребания этой кучи

Без лопаты тут однозначно не обойтись, но я бы её для другого употребил.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

13. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от Sw00p aka Jerom (?), 21-Ноя-17, 01:39 
>> но я бы её для другого употребил.

аа понял выруБалочку )))


Ответить | Правка | Наверх | Cообщить модератору

20. "Анализ степени дублирования кода на GitHub"  –2 +/
Сообщение от 123 (??), 21-Ноя-17, 06:37 
Так уже создали, Yarn.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

11. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от Анимус (?), 21-Ноя-17, 01:03 
А зачем зависимости (node_modules) в гит пихать?
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

15. "Анализ степени дублирования кода на GitHub"  +5 +/
Сообщение от агент малдер (?), 21-Ноя-17, 01:56 
В пакетах ноды творится адъ и израиль.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

16. "Анализ степени дублирования кода на GitHub"  +1 +/
Сообщение от Sw00p aka Jerom (?), 21-Ноя-17, 02:01 
>>обновив пакет и его зависимости

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

Ответить | Правка | Наверх | Cообщить модератору

17. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от агент малдер (?), 21-Ноя-17, 02:13 
>>>обновив пакет и его зависимости
> версия то по идее должна смениться, а в пекедж.ждейсоне указывать конкретную (стабильную)
> не так ?

Тут может быть другая проблема.

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

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

9 из 10 раз выбирают первый вариант.

Ответить | Правка | Наверх | Cообщить модератору

18. "Анализ степени дублирования кода на GitHub"  –3 +/
Сообщение от Sw00p aka Jerom (?), 21-Ноя-17, 03:01 
>>Тут может быть другая проблема.

проблема таже просто следующий уровень зависимости, я понимаю даже если вы укажите в своём проекте строго конкретную версию зависимости, нет гарантий что у зависимости вашей зависимости так же строго указана версия. А всё почему ? Зачем создавать "строгий версионизм" (дада даже добавив лишний пробел в проект и можно оформить новую версию) и при этом использовать "вайлдкард" в нумерации ? противоречие на лицо. Зачем создавалась всякая минорная мажорная нумерация, что это за магические слова latest, stable и тд.

Ответить | Правка | Наверх | Cообщить модератору

45. "Анализ степени дублирования кода на GitHub"  –1 +/
Сообщение от Аноним (-), 21-Ноя-17, 16:42 
Решается элементарно. Собрать проект, убедиться, что всё работает, и специальной утилитой зафиксировать версии для _всего_ дерева зависимостей. Так, например, позволяет делать zc.buildout в Питоне, если сказать ему pick-versions.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

56. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от Аноним (-), 28-Ноя-17, 10:37 
Сейчас никто не умеет версии назначать. Херачат тупо в мастере. То ли индусы, то ли смузихлёбы. Иди разбери их. Это, конечно, не отменяет того, что можно зависимости объявлять в номерах коммитов. Но всё таки факт отсутствия культуры разработки и именования версий это не отменяет
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

30. "Анализ степени дублирования кода на GitHub"  +2 +/
Сообщение от Аноним (-), 21-Ноя-17, 08:41 
> Лично я сталкивался с такой ситуацией: если сегодня тесты проходят на ура,
> то завтра, обновив пакет и его зависимости, тесты уже могут нормально
> не отработать.

Вы хотели ЯП с встроенными пакетными менеджерами и хипстерами? А теперь получите обратную сторону медали: хипстеры не умеют содержать репы.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

34. "Анализ степени дублирования кода на GitHub"  +1 +/
Сообщение от пох (?), 21-Ноя-17, 09:32 
хипстеры умеют репы - npm живее всех живых. Хипстеры не умеют backward compatibility и regression tests. Необязательно даже автоматические. И strict version checking тоже не умеют. Репа в этом не виновата, торчит себе из грядки, как у дидов.

то, что всю жизнь удивляло меня в перле и php - что пакет, зависящий от еще десятка пакетов энной степени вложенности, всегда скачивающихся самой наираспоследней версии, при этом, как правило, еще и работал. В случае js работать перестало - как в силу чудовищной неуклюжести самого языка (вызывающего к жизни leftpad и 48 уровней вложенных зависимостей), так и в силу особенностей тех, кто на нем пишет.

Ответить | Правка | Наверх | Cообщить модератору

36. "Анализ степени дублирования кода на GitHub"  –5 +/
Сообщение от Аноним (-), 21-Ноя-17, 10:05 
порекомендую заклинание:
The -g or --global argument will cause npm to install the package globally rather than locally.

Все глобальные пакеты в одной копии на всю систему и проекты.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

48. "Анализ степени дублирования кода на GitHub"  +2 +/
Сообщение от lolwat (?), 22-Ноя-17, 02:04 
долбаёб
Ответить | Правка | Наверх | Cообщить модератору

52. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от Ilya Indigo (ok), 24-Ноя-17, 01:16 
сказочный
Ответить | Правка | Наверх | Cообщить модератору

5. "Анализ степени дублирования кода на GitHub"  –1 +/
Сообщение от Вареник (?), 20-Ноя-17, 22:36 
Т.е. рано стартовавший жавовский maven действитель сделал великое дело - зависимости в яве копипастят реже других.
Ответить | Правка | Наверх | Cообщить модератору

7. "Анализ степени дублирования кода на GitHub"  +1 +/
Сообщение от kamiram (?), 20-Ноя-17, 22:40 
интересно а всякие __init__.py и подобное тоже учитывали?
Ответить | Правка | Наверх | Cообщить модератору

19. "Анализ степени дублирования кода на GitHub"  +4 +/
Сообщение от Stop (?), 21-Ноя-17, 03:29 
Чукча не читатель, чукча писатель.
Ответить | Правка | Наверх | Cообщить модератору

47. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от m_and_ms (?), 21-Ноя-17, 22:45 
__init__.py часто не пустой
Ответить | Правка | Наверх | Cообщить модератору

21. "Анализ степени дублирования кода на GitHub"  –1 +/
Сообщение от Аноним (-), 21-Ноя-17, 06:44 
php на гитхабе не в моде?
Ответить | Правка | Наверх | Cообщить модератору

22. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от бедный буратино (ok), 21-Ноя-17, 06:54 
лучше дайте анализ дублирования кода с github на других серверах
Ответить | Правка | Наверх | Cообщить модератору

38. "Анализ степени дублирования кода на GitHub"  –1 +/
Сообщение от Аноним (-), 21-Ноя-17, 10:51 
У меня дублирование стопроцентное. Гитхаб не даёт жадинам вроде меня создавать скрытые репы/ветки, но пользуется популярностью. А битбакет -- наоборот. Поэтому все открытые репы на гитхабе, а их продвинутые версии (с тестовыми ветками, экспериментами, гуанокодом, закрытыми данными и пр.) в скрытых репах на битбакете. Пока пилю, всё непрезентабельное пушится только на бикбакет. А допиленное до вменяемого вида мержится/ребейсится и пушится в оба репозитория сразу.
Ответить | Правка | Наверх | Cообщить модератору

40. "Анализ степени дублирования кода на GitHub"  –1 +/
Сообщение от бедный буратино (ok), 21-Ноя-17, 12:52 
Фишка в том, что распределённая система превращается в систему с одним-единственным сервером. И вопрос в том, что будет, если этот сервер перестанет быть доступен или вообще существовать - сколько кода будет вне этого зеркала?

Хотя на github много одноразовых проектов, которые неинтересны даже их авторам, поэтому такое сравнение провести будет сложно :)

Ответить | Правка | Наверх | Cообщить модератору

42. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от Аноним (-), 21-Ноя-17, 13:18 
Ну, строго говоря, код останется практически весь. За исключением "одноразовых проектов, которые неинтересны даже их авторам", весь код есть в локальных репах разработчиков. Поэтому при исчезновении гитхаба код не исчезнет. А вот разработка очень замедлится, это да.
Ответить | Правка | Наверх | Cообщить модератору

46. "Анализ степени дублирования кода на GitHub"  –1 +/
Сообщение от пох (?), 21-Ноя-17, 20:43 
> Фишка в том, что распределённая система превращается в систему с одним-единственным сервером

как и весь этот ваш интернет-2.0(или уже 3.0?)

> И вопрос в том, что будет, если этот сервер перестанет быть доступен или вообще существовать -
> сколько кода будет вне этого зеркала?

весь будет, на локальной машине того самого единственного автора единственной версии 1.

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

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

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

28. "Анализ степени дублирования кода на GitHub"  +4 +/
Сообщение от Аноним (-), 21-Ноя-17, 08:21 
Выводы из статьи:
1) Python - лучший язык для изобретения велосипедов
2) JavaScript - лучший язык для бездумного копирования чужих велосипедов
Ответить | Правка | Наверх | Cообщить модератору

35. "Анализ степени дублирования кода на GitHub"  –1 +/
Сообщение от пох (?), 21-Ноя-17, 09:36 
> Выводы из статьи:
> 1) Python - лучший язык для изобретения велосипедов
> 2) JavaScript - лучший язык для бездумного копирования чужих велосипедов

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

Ответить | Правка | Наверх | Cообщить модератору

41. "Анализ степени дублирования кода на GitHub"  +3 +/
Сообщение от бедный буратино (ok), 21-Ноя-17, 12:54 
>  В пихоне те же самые велосипеды чаще подключают как зависимости,

10 баллов. даже 11.

Выражение *изобретать велосипед* означает, что кто-то изобретает то, что уже изобретено. Поэтому фраза *подключать велосипед* обретает шикарный, весёлый и игривый смысл. А также говорит, что автор просто копирует буквы, даже не пытаясь вдуматься в их смысл. :)

Ответить | Правка | Наверх | Cообщить модератору

44. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от Аноним (-), 21-Ноя-17, 15:25 
> даже не пытаясь вдуматься в их смысл

У вас тут ещё и думать надо?

Ответить | Правка | Наверх | Cообщить модератору

49. "Анализ степени дублирования кода на GitHub"  +4 +/
Сообщение от lolwat (?), 22-Ноя-17, 02:12 
думать сложно - пойду писать проекты на JavaScript
Ответить | Правка | Наверх | Cообщить модератору

31. "Анализ степени дублирования кода на GitHub"  –6 +/
Сообщение от Аноним (-), 21-Ноя-17, 08:47 
Что то странное исследование. Обычное явление сделать форк какого-нибудь проекта, чтобы добавлять туда свой функционал, перед тем как передать патчи в основной проект, если эти патчи кому-либо нужны кроме узкого круга людей.
Ответить | Правка | Наверх | Cообщить модератору

32. "Анализ степени дублирования кода на GitHub"  +12 +/
Сообщение от Аноним (-), 21-Ноя-17, 09:18 
Вижу программиста на JavaScript в тебе я.

Написано же:

> (без форков репозиториев)

Ответить | Правка | Наверх | Cообщить модератору

33. "Анализ степени дублирования кода на GitHub"  +7 +/
Сообщение от Аноним (-), 21-Ноя-17, 09:24 
> 94% файлов являются полными клонами 6% файлов

Лол, вся суть первого места яваскрипта на гитхабе.

Ответить | Правка | Наверх | Cообщить модератору

37. "Анализ степени дублирования кода на GitHub"  +1 +/
Сообщение от letsmac (ok), 21-Ноя-17, 10:24 
Ну дык они зря что-ли кучу WebPack- ов наплодили, вся цель которых - ужимать копипастную деятельность?
Ответить | Правка | Наверх | Cообщить модератору

43. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от Аноним (-), 21-Ноя-17, 15:01 
И добавить даже нечего.
Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

54. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от pripolz (?), 27-Ноя-17, 12:25 
configure.ac и autogen.sh )))
Ответить | Правка | Наверх | Cообщить модератору

55. "Анализ степени дублирования кода на GitHub"  +/
Сообщение от pripolz (?), 27-Ноя-17, 12:38 
а где m4?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру