forum.opennet.ru - "Анализ степени дублирования кода на GitHub" (46)

"Анализ степени дублирования кода на 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.../ Новость: http://www.opennet.me/opennews/art.shtml?num=47596
Ответить \| Правка \| Cообщить модератору

Оглавление

leftpad надублировали, небось , Аноним (-), 21:53 , 20-Ноя-17, (1) +6

Ага, послушали комментаторов на опеннете, которые осуждали подключение лефтпада , Green (??), 08:14 , 21-Ноя-17, (27) +3
Вот это и надублировали Каждая хомпага тащит свою копию зависимостей , Аноним (-), 08:39 , 21-Ноя-17, (29)

Да, npm это страшная вещь Как-то на досуге загрузил модуль ноды через npm, модул, Аноним (-), 22:18 , 20-Ноя-17, (3) +17

Что тут удивительного, когда В среднем уровень вложенности зависимостей сос, Moomintroll (ok), 22:24 , 20-Ноя-17, (4)

derivative , Donald Trump aside of Yuri Bezmenov (?), 22:38 , 20-Ноя-17, (6)

Эт я думаю вы с каким нить флагом nodev устанавливали Пс зовите Гугл на помощь , Sw00p aka Jerom (?), 22:48 , 20-Ноя-17, (8) –1

тут не надо разгребать, тут другой случай, нокию вызывайте - чтоб закoпали поглу, пох (?), 22:58 , 20-Ноя-17, (9) +3

а прикол весь в том, что ну придумают лопату, а куча то растёт, придумают экскав, Sw00p aka Jerom (?), 01:38 , 21-Ноя-17, (12) +1

Без лопаты тут однозначно не обойтись, но я бы её для другого употребил , Аноним (-), 23:10 , 20-Ноя-17, (10) +1

аа понял выруБалочку , Sw00p aka Jerom (?), 01:39 , 21-Ноя-17, (13)

Так уже создали, Yarn , 123 (??), 06:37 , 21-Ноя-17, (20) –2

А зачем зависимости node_modules в гит пихать , Анимус (?), 01:03 , 21-Ноя-17, (11)

В пакетах ноды творится адъ и израиль Лично я сталкивался с такой ситуацией есл, агент малдер (?), 01:56 , 21-Ноя-17, (15) +5

версия то по идее должна смениться, а в пекедж ждейсоне указывать конкретную ст, Sw00p aka Jerom (?), 02:01 , 21-Ноя-17, (16) +1

Тут может быть другая проблема Например, версия нужного тебе пакета _не_ поменял, агент малдер (?), 02:13 , 21-Ноя-17, (17)

проблема таже просто следующий уровень зависимости, я понимаю даже если вы укажи, Sw00p aka Jerom (?), 03:01 , 21-Ноя-17, (18) –3
Решается элементарно Собрать проект, убедиться, что всё работает, и специальной, Аноним (-), 16:42 , 21-Ноя-17, (45) –1
Сейчас никто не умеет версии назначать Херачат тупо в мастере То ли индусы, то, Аноним (-), 10:37 , 28-Ноя-17, (56)

Вы хотели ЯП с встроенными пакетными менеджерами и хипстерами А теперь получите, Аноним (-), 08:41 , 21-Ноя-17, (30) +2

хипстеры умеют репы - npm живее всех живых Хипстеры не умеют backward compatibi, пох (?), 09:32 , 21-Ноя-17, (34) +1

порекомендую заклинание The -g or --global argument will cause npm to install t, Аноним (-), 10:05 , 21-Ноя-17, (36) –5

долбаёб, lolwat (?), 02:04 , 22-Ноя-17, (48) +2

сказочный, Ilya Indigo (ok), 01:16 , 24-Ноя-17, (52)

Т е рано стартовавший жавовский maven действитель сделал великое дело - зависим, Вареник (?), 22:36 , 20-Ноя-17, (5) –1
интересно а всякие __init__ py и подобное тоже учитывали , kamiram (?), 22:40 , 20-Ноя-17, (7) +1

Чукча не читатель, чукча писатель , Stop (?), 03:29 , 21-Ноя-17, (19) +4

__init__ py часто не пустой, m_and_ms (?), 22:45 , 21-Ноя-17, (47)

php на гитхабе не в моде , Аноним (-), 06:44 , 21-Ноя-17, (21) –1
лучше дайте анализ дублирования кода с github на других серверах, бедный буратино (ok), 06:54 , 21-Ноя-17, (22)

У меня дублирование стопроцентное Гитхаб не даёт жадинам вроде меня создавать с, Аноним (-), 10:51 , 21-Ноя-17, (38) –1

Фишка в том, что распределённая система превращается в систему с одним-единствен, бедный буратино (ok), 12:52 , 21-Ноя-17, (40) –1

Ну, строго говоря, код останется практически весь За исключением одноразовых п, Аноним (-), 13:18 , 21-Ноя-17, (42)
как и весь этот ваш интернет-2 0 или уже 3 0 весь будет, на локальной машине то, пох (?), 20:43 , 21-Ноя-17, (46) –1

Выводы из статьи 1 Python - лучший язык для изобретения велосипедов2 JavaScri, Аноним (-), 08:21 , 21-Ноя-17, (28) +4

неправильные выводы В пихоне те же самые велосипеды чаще подключают как зависим, пох (?), 09:36 , 21-Ноя-17, (35) –1

10 баллов даже 11 Выражение изобретать велосипед означает, что кто-то изобрет, бедный буратино (ok), 12:54 , 21-Ноя-17, (41) +3

У вас тут ещё и думать надо , Аноним (-), 15:25 , 21-Ноя-17, (44)

думать сложно - пойду писать проекты на JavaScript, lolwat (?), 02:12 , 22-Ноя-17, (49) +4

Что то странное исследование Обычное явление сделать форк какого-нибудь проекта, Аноним (-), 08:47 , 21-Ноя-17, (31) –6

Вижу программиста на JavaScript в тебе я Написано же , Аноним (-), 09:18 , 21-Ноя-17, (32) +12

Лол, вся суть первого места яваскрипта на гитхабе , Аноним (-), 09:24 , 21-Ноя-17, (33) +7

Ну дык они зря что-ли кучу WebPack- ов наплодили, вся цель которых - ужимать коп, letsmac (ok), 10:24 , 21-Ноя-17, (37) +1
И добавить даже нечего , Аноним (-), 15:01 , 21-Ноя-17, (43)

configure ac и autogen sh , pripolz (?), 12:25 , 27-Ноя-17, (54)
а где m4 , pripolz (?), 12:38 , 27-Ноя-17, (55)

Сообщения [Сортировка по времени | 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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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ообщить модератору