The OpenNET Project / Index page

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

Анализ степени дублирования кода на GitHub

20.11.2017 21:47

Представлены результаты изучения дублирования кода в общем объёме исходных текстов, размещённых на GitHub. Проанализировано 4.5 млн различных проектов (без форков репозиториев), включающих более 428 млн файлов с кодом на языках Java, C++, Python и JavaScript. Из этих файлов лишь 85 млн оказались уникальными, т.е. 80% кода на GitHub являются копиями других файлов.

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

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

Наиболее часто повторяющимся стал пустой файл, размером 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 копирование распределено более равномерно по разнообразным библиотекам.

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

  1. Главная ссылка к новости (https://blog.acolyer.org/2017/...)
  2. OpenNews: GitHub опубликовал статистику за 2017 год
  3. OpenNews: Применение тайпсквоттинга для распространения вредоносных модулей NPM, PyPI и Gems
  4. OpenNews: Инцидент с захватом прав на NPM-модуль привёл к сбою в работе проектов, использующих NPM
  5. OpenNews: Незащищённость NPM к атакам по внедрению вредоносных модулей-червей
  6. OpenNews: NPM стал крупнейшим репозиторием пакетов
Лицензия: CC-BY
Тип: Тема для размышления
Ключевые слова: github, code
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (46) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 21:53, 20/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    leftpad надублировали, небось.
     
     
  • 2.27, Green (??), 08:14, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ага, послушали комментаторов на опеннете, которые осуждали подключение лефтпада как отдельного модуля, стали копипастить.
     
  • 2.29, Аноним (-), 08:39, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > В среднем в JavaScript-проект включается 63 зависимости

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

     

  • 1.3, Аноним (-), 22:18, 20/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +17 +/
    Да, npm это страшная вещь.

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

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

     
     
  • 2.4, Moomintroll (ok), 22:24, 20/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Как-то на досуге загрузил модуль ноды через npm, модуль 20-25 Кб.
    >
    > Вы не поверите, npm зависимостей всосал где-то на 100 метров. Честное слово, я не вру, сам о*уел когда увидел.

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

     
     
  • 3.6, Donald Trump aside of Yuri Bezmenov (?), 22:38, 20/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Как-то на досуге загрузил модуль ноды через npm, модуль 20-25 Кб.
    >>
    >> Вы не поверите, npm зависимостей всосал где-то на 100 метров. Честное слово, я не вру, сам о*уел когда увидел.
    > Что тут удивительного, когда "В среднем ... уровень вложенности зависимостей составляет
    > 5 ... максимальный уровень вложенности - 47"?

    derivative?

     
  • 2.8, Sw00p aka Jerom (?), 22:48, 20/11/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Эт я думаю вы с каким нить флагом nodev устанавливали?

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

     
     
  • 3.9, пох (?), 22:58, 20/11/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    тут не надо разгребать, тут другой случай, нокию вызывайте - чтоб закoпали поглубже. Особо опасный жабоскриптный мусор.

     
     
  • 4.12, Sw00p aka Jerom (?), 01:38, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а прикол весь в том, что ну придумают лопату, а куча то растёт, придумают экскаватор Отиса, чтоб з-а-к-о-п-а-т-ь потом по глубже

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

     
  • 3.10, Аноним (-), 23:10, 20/11/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > лопаточку выручалочку для разгребания этой кучи

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

     
     
  • 4.13, Sw00p aka Jerom (?), 01:39, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> но я бы её для другого употребил.

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


     
  • 3.20, 123 (??), 06:37, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Так уже создали, Yarn.
     
  • 2.11, Анимус (?), 01:03, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем зависимости (node_modules) в гит пихать?
     
     
  • 3.15, агент малдер (?), 01:56, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    В пакетах ноды творится адъ и израиль.

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

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

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

     
     
  • 4.16, Sw00p aka Jerom (?), 02:01, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>обновив пакет и его зависимости

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

     
     
  • 5.17, агент малдер (?), 02:13, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>>обновив пакет и его зависимости
    > версия то по идее должна смениться, а в пекедж.ждейсоне указывать конкретную (стабильную)
    > не так ?

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

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

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

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

     
     
  • 6.18, Sw00p aka Jerom (?), 03:01, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >>Тут может быть другая проблема.

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

     
  • 6.45, Аноним (-), 16:42, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Решается элементарно. Собрать проект, убедиться, что всё работает, и специальной утилитой зафиксировать версии для _всего_ дерева зависимостей. Так, например, позволяет делать zc.buildout в Питоне, если сказать ему pick-versions.
     
  • 6.56, Аноним (-), 10:37, 28/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас никто не умеет версии назначать. Херачат тупо в мастере. То ли индусы, то ли смузихлёбы. Иди разбери их. Это, конечно, не отменяет того, что можно зависимости объявлять в номерах коммитов. Но всё таки факт отсутствия культуры разработки и именования версий это не отменяет
     
  • 4.30, Аноним (-), 08:41, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Лично я сталкивался с такой ситуацией: если сегодня тесты проходят на ура,
    > то завтра, обновив пакет и его зависимости, тесты уже могут нормально
    > не отработать.

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

     
     
  • 5.34, пох (?), 09:32, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    хипстеры умеют репы - npm живее всех живых. Хипстеры не умеют backward compatibility и regression tests. Необязательно даже автоматические. И strict version checking тоже не умеют. Репа в этом не виновата, торчит себе из грядки, как у дидов.

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

     
  • 2.36, Аноним (-), 10:05, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • –5 +/
    порекомендую заклинание:
    The -g or --global argument will cause npm to install the package globally rather than locally.

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

     
     
  • 3.48, lolwat (?), 02:04, 22/11/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    долбаёб
     
     
  • 4.52, Ilya Indigo (ok), 01:16, 24/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    сказочный
     

  • 1.5, Вареник (?), 22:36, 20/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Т.е. рано стартовавший жавовский maven действитель сделал великое дело - зависимости в яве копипастят реже других.
     
  • 1.7, kamiram (?), 22:40, 20/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    интересно а всякие __init__.py и подобное тоже учитывали?
     
     
  • 2.19, Stop (?), 03:29, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Чукча не читатель, чукча писатель.
     
     
  • 3.47, m_and_ms (?), 22:45, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    __init__.py часто не пустой
     

  • 1.21, Аноним (-), 06:44, 21/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    php на гитхабе не в моде?
     
  • 1.22, бедный буратино (ok), 06:54, 21/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    лучше дайте анализ дублирования кода с github на других серверах
     
     
  • 2.38, Аноним (-), 10:51, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У меня дублирование стопроцентное. Гитхаб не даёт жадинам вроде меня создавать скрытые репы/ветки, но пользуется популярностью. А битбакет -- наоборот. Поэтому все открытые репы на гитхабе, а их продвинутые версии (с тестовыми ветками, экспериментами, гуанокодом, закрытыми данными и пр.) в скрытых репах на битбакете. Пока пилю, всё непрезентабельное пушится только на бикбакет. А допиленное до вменяемого вида мержится/ребейсится и пушится в оба репозитория сразу.
     
     
  • 3.40, бедный буратино (ok), 12:52, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Фишка в том, что распределённая система превращается в систему с одним-единственным сервером. И вопрос в том, что будет, если этот сервер перестанет быть доступен или вообще существовать - сколько кода будет вне этого зеркала?

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

     
     
  • 4.42, Аноним (-), 13:18, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, строго говоря, код останется практически весь. За исключением "одноразовых проектов, которые неинтересны даже их авторам", весь код есть в локальных репах разработчиков. Поэтому при исчезновении гитхаба код не исчезнет. А вот разработка очень замедлится, это да.
     
  • 4.46, пох (?), 20:43, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Фишка в том, что распределённая система превращается в систему с одним-единственным сервером

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

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

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

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

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

     

  • 1.28, Аноним (-), 08:21, 21/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Выводы из статьи:
    1) Python - лучший язык для изобретения велосипедов
    2) JavaScript - лучший язык для бездумного копирования чужих велосипедов
     
     
  • 2.35, пох (?), 09:36, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Выводы из статьи:
    > 1) Python - лучший язык для изобретения велосипедов
    > 2) JavaScript - лучший язык для бездумного копирования чужих велосипедов

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

     
     
  • 3.41, бедный буратино (ok), 12:54, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >  В пихоне те же самые велосипеды чаще подключают как зависимости,

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

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

     
     
  • 4.44, Аноним (-), 15:25, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > даже не пытаясь вдуматься в их смысл

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

     
     
  • 5.49, lolwat (?), 02:12, 22/11/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    думать сложно - пойду писать проекты на JavaScript
     

  • 1.31, Аноним (-), 08:47, 21/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Что то странное исследование. Обычное явление сделать форк какого-нибудь проекта, чтобы добавлять туда свой функционал, перед тем как передать патчи в основной проект, если эти патчи кому-либо нужны кроме узкого круга людей.
     
     
  • 2.32, Аноним (-), 09:18, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Вижу программиста на JavaScript в тебе я.

    Написано же:

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

     

  • 1.33, Аноним (-), 09:24, 21/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    > 94% файлов являются полными клонами 6% файлов

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

     
     
  • 2.37, letsmac (ok), 10:24, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну дык они зря что-ли кучу WebPack- ов наплодили, вся цель которых - ужимать копипастную деятельность?
     
  • 2.43, Аноним (-), 15:01, 21/11/2017 [^] [^^] [^^^] [ответить]  
  • +/
    И добавить даже нечего.
     

  • 1.54, pripolz (?), 12:25, 27/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    configure.ac и autogen.sh )))
     
  • 1.55, pripolz (?), 12:38, 27/11/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а где m4?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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