Представлены (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.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=47596
leftpad надублировали, небось.
Ага, послушали комментаторов на опеннете, которые осуждали подключение лефтпада как отдельного модуля, стали копипастить.
> В среднем в JavaScript-проект включается 63 зависимостиВот это и надублировали. Каждая хомпага тащит свою копию зависимостей.
Да, npm это страшная вещь.Как-то на досуге загрузил модуль ноды через npm, модуль 20-25 Кб.
Вы не поверите, npm зависимостей всосал где-то на 100 метров. Честное слово, я не вру, сам о*уел когда увидел.
> Как-то на досуге загрузил модуль ноды через npm, модуль 20-25 Кб.
>
> Вы не поверите, npm зависимостей всосал где-то на 100 метров. Честное слово, я не вру, сам о*уел когда увидел.Что тут удивительного, когда "В среднем ... уровень вложенности зависимостей составляет 5 ... максимальный уровень вложенности - 47"?
>> Как-то на досуге загрузил модуль ноды через npm, модуль 20-25 Кб.
>>
>> Вы не поверите, npm зависимостей всосал где-то на 100 метров. Честное слово, я не вру, сам о*уел когда увидел.
> Что тут удивительного, когда "В среднем ... уровень вложенности зависимостей составляет
> 5 ... максимальный уровень вложенности - 47"?derivative?
Эт я думаю вы с каким нить флагом nodev устанавливали?Пс: зовите Гугл на помощь пусть создадут лопаточку выручалочку для разгребания этой кучи
тут не надо разгребать, тут другой случай, нокию вызывайте - чтоб закoпали поглубже. Особо опасный жабоскриптный мусор.
а прикол весь в том, что ну придумают лопату, а куча то растёт, придумают экскаватор Отиса, чтоб з-а-к-о-п-а-т-ь потом по глубжепс: ПРЕДУПРЕЖДЕНИЕ: В сообщении используется ненормативная лексика. Выражение, на которое сработало предупреждение: 'з"а"к"о"п"а'. ППЦ админы.
> лопаточку выручалочку для разгребания этой кучиБез лопаты тут однозначно не обойтись, но я бы её для другого употребил.
>> но я бы её для другого употребил.аа понял выруБалочку )))
Так уже создали, Yarn.
А зачем зависимости (node_modules) в гит пихать?
В пакетах ноды творится адъ и израиль.Лично я сталкивался с такой ситуацией: если сегодня тесты проходят на ура, то завтра, обновив пакет и его зависимости, тесты уже могут нормально не отработать.
Поэтому сливают некий нужный пакет и все его зависимости в каталог проекта и используют определенную версию (и зависимости) с которой все тесты проходят. Убедить, что это плохо и так не надо делать почти не реально, т.к. никто не хочет пилить заново то, что вчера работало без проблем.
В результате вся куча этого мусора оказывается, в данном случае, на гитхабе.
>>обновив пакет и его зависимостиверсия то по идее должна смениться, а в пекедж.ждейсоне указывать конкретную (стабильную) не так ?
>>>обновив пакет и его зависимости
> версия то по идее должна смениться, а в пекедж.ждейсоне указывать конкретную (стабильную)
> не так ?Тут может быть другая проблема.
Например, версия нужного тебе пакета _не_ поменялась, а версия одной из его зависимостей поменялась, поломав совместимость с нужным тебе пакетом. Такая ситуация абсолютно нормальное явление в ноде.
У тебя два варианта: ничего не обновлять, либо обновлять зависимость и нужный тебе пакет.
9 из 10 раз выбирают первый вариант.
>>Тут может быть другая проблема.проблема таже просто следующий уровень зависимости, я понимаю даже если вы укажите в своём проекте строго конкретную версию зависимости, нет гарантий что у зависимости вашей зависимости так же строго указана версия. А всё почему ? Зачем создавать "строгий версионизм" (дада даже добавив лишний пробел в проект и можно оформить новую версию) и при этом использовать "вайлдкард" в нумерации ? противоречие на лицо. Зачем создавалась всякая минорная мажорная нумерация, что это за магические слова latest, stable и тд.
Решается элементарно. Собрать проект, убедиться, что всё работает, и специальной утилитой зафиксировать версии для _всего_ дерева зависимостей. Так, например, позволяет делать zc.buildout в Питоне, если сказать ему pick-versions.
Сейчас никто не умеет версии назначать. Херачат тупо в мастере. То ли индусы, то ли смузихлёбы. Иди разбери их. Это, конечно, не отменяет того, что можно зависимости объявлять в номерах коммитов. Но всё таки факт отсутствия культуры разработки и именования версий это не отменяет
> Лично я сталкивался с такой ситуацией: если сегодня тесты проходят на ура,
> то завтра, обновив пакет и его зависимости, тесты уже могут нормально
> не отработать.Вы хотели ЯП с встроенными пакетными менеджерами и хипстерами? А теперь получите обратную сторону медали: хипстеры не умеют содержать репы.
хипстеры умеют репы - npm живее всех живых. Хипстеры не умеют backward compatibility и regression tests. Необязательно даже автоматические. И strict version checking тоже не умеют. Репа в этом не виновата, торчит себе из грядки, как у дидов.то, что всю жизнь удивляло меня в перле и php - что пакет, зависящий от еще десятка пакетов энной степени вложенности, всегда скачивающихся самой наираспоследней версии, при этом, как правило, еще и работал. В случае js работать перестало - как в силу чудовищной неуклюжести самого языка (вызывающего к жизни leftpad и 48 уровней вложенных зависимостей), так и в силу особенностей тех, кто на нем пишет.
порекомендую заклинание:
The -g or --global argument will cause npm to install the package globally rather than locally.Все глобальные пакеты в одной копии на всю систему и проекты.
долбаёб
сказочный
Т.е. рано стартовавший жавовский maven действитель сделал великое дело - зависимости в яве копипастят реже других.
интересно а всякие __init__.py и подобное тоже учитывали?
Чукча не читатель, чукча писатель.
__init__.py часто не пустой
php на гитхабе не в моде?
лучше дайте анализ дублирования кода с github на других серверах
У меня дублирование стопроцентное. Гитхаб не даёт жадинам вроде меня создавать скрытые репы/ветки, но пользуется популярностью. А битбакет -- наоборот. Поэтому все открытые репы на гитхабе, а их продвинутые версии (с тестовыми ветками, экспериментами, гуанокодом, закрытыми данными и пр.) в скрытых репах на битбакете. Пока пилю, всё непрезентабельное пушится только на бикбакет. А допиленное до вменяемого вида мержится/ребейсится и пушится в оба репозитория сразу.
Фишка в том, что распределённая система превращается в систему с одним-единственным сервером. И вопрос в том, что будет, если этот сервер перестанет быть доступен или вообще существовать - сколько кода будет вне этого зеркала?Хотя на github много одноразовых проектов, которые неинтересны даже их авторам, поэтому такое сравнение провести будет сложно :)
Ну, строго говоря, код останется практически весь. За исключением "одноразовых проектов, которые неинтересны даже их авторам", весь код есть в локальных репах разработчиков. Поэтому при исчезновении гитхаба код не исчезнет. А вот разработка очень замедлится, это да.
> Фишка в том, что распределённая система превращается в систему с одним-единственным серверомкак и весь этот ваш интернет-2.0(или уже 3.0?)
> И вопрос в том, что будет, если этот сервер перестанет быть доступен или вообще существовать -
> сколько кода будет вне этого зеркала?весь будет, на локальной машине того самого единственного автора единственной версии 1.
но вот найти его тебе будет очень и очень трудно, потому что ты об этом авторе ничего не знаешь, и общался с ним ты тоже через гитхаб.
большие проекты, у которых в силу исторических причин, старости разработчиков или принадлежности компаниям, есть другие средства коммуникации - хорошо известный сайт, smtp-рассылка, вебфорум - выкарабкаются, а остальные найдут друг друга может через несколько лет, когда уже никому никто будет не нужен.
Выводы из статьи:
1) Python - лучший язык для изобретения велосипедов
2) JavaScript - лучший язык для бездумного копирования чужих велосипедов
> Выводы из статьи:
> 1) Python - лучший язык для изобретения велосипедов
> 2) JavaScript - лучший язык для бездумного копирования чужих велосипедовнеправильные выводы. В пихоне те же самые велосипеды чаще подключают как зависимости, а не копируют себе в дерево проекта.
> В пихоне те же самые велосипеды чаще подключают как зависимости,10 баллов. даже 11.
Выражение *изобретать велосипед* означает, что кто-то изобретает то, что уже изобретено. Поэтому фраза *подключать велосипед* обретает шикарный, весёлый и игривый смысл. А также говорит, что автор просто копирует буквы, даже не пытаясь вдуматься в их смысл. :)
> даже не пытаясь вдуматься в их смыслУ вас тут ещё и думать надо?
думать сложно - пойду писать проекты на JavaScript
Что то странное исследование. Обычное явление сделать форк какого-нибудь проекта, чтобы добавлять туда свой функционал, перед тем как передать патчи в основной проект, если эти патчи кому-либо нужны кроме узкого круга людей.
Вижу программиста на JavaScript в тебе я.Написано же:
> (без форков репозиториев)
> 94% файлов являются полными клонами 6% файловЛол, вся суть первого места яваскрипта на гитхабе.
Ну дык они зря что-ли кучу WebPack- ов наплодили, вся цель которых - ужимать копипастную деятельность?
И добавить даже нечего.
configure.ac и autogen.sh )))
а где m4?